From youngs@xemacs.org Tue May 1 03:46:52 2001 Received: from mail002.syd.optusnet.com.au (mail002.syd.optusnet.com.au [203.2.75.245]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA11279 for ; Tue, 1 May 2001 03:46:48 -0400 Received: from slackware.mynet.pc (wdcax13-087.dialup.optusnet.com.au [198.142.220.87]) by mail002.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f417kiE26969 for ; Tue, 1 May 2001 17:46:44 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.11.1/8.11.1) id f417iSC06734; Tue, 1 May 2001 17:44:28 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: New/Updated Packages in Pre-Releases - April 30 References: <14uDBK-0lLi8OC@fwd05.sul.t-online.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 01 May 2001 17:44:28 +1000 In-Reply-To: <14uDBK-0lLi8OC@fwd05.sul.t-online.com> (Adrian.Aichner@t-online.de's message of "30 Apr 2001 12:53 GMT") Message-ID: Lines: 14 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "AA" == Adrian Aichner writes: AA> All these experimental packages downloaded and installed fine on my AA> Windows 2000 system. Woohoo! Thanks for letting me know, Adrian. I appreciate it. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Tue May 1 03:46:55 2001 Received: from mail002.syd.optusnet.com.au (mail002.syd.optusnet.com.au [203.2.75.245]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA11280 for ; Tue, 1 May 2001 03:46:52 -0400 Received: from slackware.mynet.pc (wdcax13-087.dialup.optusnet.com.au [198.142.220.87]) by mail002.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f417kfE26935 for ; Tue, 1 May 2001 17:46:42 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.11.1/8.11.1) id f417o9b06776; Tue, 1 May 2001 17:50:09 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Updated Package in 'Pre-Releases' - xslt-process From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 01 May 2001 17:50:08 +1000 Message-ID: Lines: 18 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii This package has been updated in 'Pre-Releases' xslt-process-1.03-pkg.tar.gz ============================ 2001-04-30 Ovidiu Predescu * Makefile: Define the proper paths where the files should go. * lisp/xslt-process.el (xslt-process-find-xslt-directory): Modified to take into account the XEmacs packaging scheme. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From ovidiu@cup.hp.com Tue May 1 04:13:10 2001 Received: from hercules.linux.bogus (adsl-63-200-49-97.dsl.snfc21.pacbell.net [63.200.49.97]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA12511; Tue, 1 May 2001 04:13:08 -0400 Received: (from ovidiu@localhost) by hercules.linux.bogus (8.9.3/8.9.3) id BAA11849; Tue, 1 May 2001 01:13:04 -0700 Message-Id: <200105010813.BAA11849@hercules.linux.bogus> X-Mailer: exmh 2.3.1 01/18/2001 with XEmacs 21.1.14 on Linux 2.2.18 From: Ovidiu Predescu To: Steve Youngs Cc: XEmacs Beta Subject: Re: Updated Package in 'Pre-Releases' - xslt-process In-Reply-To: Your message of "01 May 2001 17:50:08 +1000." X-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ X-Image-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ovidiu.tiff X-Face: ?(@Y~qjBA}~8ZMh5gM4{Q{bE_*:sCJ3@Z?{B*Co=J!#8bb~-z?-0._vJjt~MM59!MjxG%>U 5>MW^2-\7~z04buszR^=m^U|m66>FdR@cFwhb;.A(8*D.QmLkK]z,md0'HiOE\pyeiv_PACR+P:Cm. wq_%l':E:q]g-UCc>r&s@BVo'kFN;(\9PF22Myg5w%nUBWQ6MJJ#qL#w>2oxckP'H:\$9F"mxsz]Dg k{1`fTcP'Y$CgGnc^paTV$dzhVX+;(U$;Eb)P<>G)g) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 01:13:04 -0700 Sender: ovidiu@cup.hp.com On 01 May 2001 17:50:08 +1000, Steve Youngs wrote: > This package has been updated in 'Pre-Releases' > > xslt-process-1.03-pkg.tar.gz > ============================ > 2001-04-30 Ovidiu Predescu > > * Makefile: Define the proper paths where the files should go. > > * lisp/xslt-process.el (xslt-process-find-xslt-directory): > Modified to take into account the XEmacs packaging scheme. I just tested it and works fine, thanks for the quick response! Best regards, -- Ovidiu Predescu http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) From martin@m17n.org Tue May 1 04:49:49 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA14270 for ; Tue, 1 May 2001 04:49:48 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id RAA23187; Tue, 1 May 2001 17:49:45 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id RAA26002; Tue, 1 May 2001 17:49:44 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f418nh202706; Tue, 1 May 2001 17:49:43 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15086.30887.203671.877512@gargle.gargle.HOWL> Date: Tue, 1 May 2001 17:49:43 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Eric Knauel , XEmacs Beta Test Subject: Re: gnus crashes XEmacs (on MacOS X 10.0.1) in summary buffer In-Reply-To: References: X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Eric" == Eric Knauel writes: Eric> Gunnar Evermann writes: >> > > what is the default stack size on your OS? >> > Hmmm... I don't know... How can I find out? >> >> 'ulimit -a' works on most systems if you use bash. Eric> Found it: Eric> [eric@gryffindor ~] limit Eric> cputime unlimited Eric> filesize unlimited Eric> datasize 6144 kbytes Eric> stacksize 512 kbytes Eric> coredumpsize unlimited Eric> memoryuse unlimited Eric> descriptors 256 Eric> memorylocked unlimited Eric> maxproc 100 Eric> With "limit stacksize 8192k" in my .cshrc it works, no crash. Does Eric> this mean, that this is an OS X/Darwin issue? I mean, OS X is raising Eric> strange signals that UNIX won't understand, that is not what it is Eric> supposed to do? XEmacs needs more than .5 MB stacksize. That's the smallest I've seen. Even 2MB is not enough. I recommend 8MB. Here are the defaults for a bunch of Unix systems. (martin@mule) ~/Mail $ do-mulelab 'uname -s; limit | g stacksize' -------------- hpux ---------------- HP-UX stacksize 8MB -------------- turbolinux ---------------- Linux stacksize 8MB -------------- aix ---------------- AIX stacksize 32MB -------------- freebsd ---------------- FreeBSD stacksize 64MB -------------- polgar ---------------- SunOS stacksize 8MB -------------- bsdi ---------------- BSD/OS stacksize 2MB -------------- sunos ---------------- SunOS stacksize 8MB -------------- mule ---------------- SunOS stacksize 8MB -------------- lasker ---------------- Linux stacksize 8MB -------------- netbsd ---------------- NetBSD stacksize 2MB -------------- solaris8i ---------------- SunOS stacksize 8MB -------------- tru64 ---------------- OSF1 stacksize 2MB .5MB is so small I consider this a MacOS X BUG. (See the freebsd entry above). Sample dotfile code: case "$SHOST" in debian | hpux) limit stacksize 8m;; *) limit stacksize 16m;; esac From aj@suse.de Tue May 1 06:09:37 2001 Received: from mail.kdt.de (mail.kdt.de [195.8.224.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA21017 for ; Tue, 1 May 2001 06:09:36 -0400 Received: from arthur.inka.de (arthur.kdt.de [195.8.250.5]) by mail.kdt.de (8.11.1/8.11.0) with ESMTP id f41A9VA06447; Tue, 1 May 2001 12:09:31 +0200 Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.14 #1) id 14uX2p-0006kt-00; Tue, 01 May 2001 12:06:11 +0200 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 418E91EA2E; Tue, 1 May 2001 12:06:10 +0200 (CEST) Sender: aj@suse.de To: Andy Piper Cc: XEmacs Beta Testers Subject: Re: Warning: XtRemoveGrab asked to remove a widget not on the list References: <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> From: Andreas Jaeger Date: 01 May 2001 12:06:10 +0200 In-Reply-To: <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> (Andy Piper's message of "Sat, 28 Apr 2001 08:33:43 -0700") Message-ID: Lines: 15 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Andy Piper writes: > I've seen this at frame deletion and never been able to track it > down. I believe its widget related becuase it came and went while I > was hacking on them. Do you have any idea how to track it down? I can easily reproduce it but don't know anything about the widget stuff. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From rendhalver@users.sourceforge.net Tue May 1 06:27:55 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA21673 for ; Tue, 1 May 2001 06:27:54 -0400 Received: from ulthwe.dyndns.org (p230-tnt1.brs.ihug.com.au [203.173.188.230]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id UAA23184 for ; Tue, 1 May 2001 20:27:46 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p230-tnt1.brs.ihug.com.au [203.173.188.230] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15086.36614.420634.495114@ulthwe.dyndns.org> Date: Tue, 1 May 2001 20:25:10 +1000 To: xemacs-beta@xemacs.org Subject: [repost] problem with custom.el file options not being noticed X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII hi all i sent this a couple of days ago dont mean to harrass anyone but im kinda stuck on what to do about this anyone have any ideas what would be causing this thanks again got an interesting problem i have been playing arround with my custom.el file i decided to start from scratch with 21.4.1 so i moved my old .xemacs directory then i thought i would use the sample init.el file (thanks for wrighting this one ben) i then coppied a whole bunch of options from my old custom.el file to the new one now some of my options are not being recognised build package ones so far are all i have noticed so far havent checked all of them any idea what is causing this ?? did i do the wrong thing in copying from my old file ?? thanks in advance -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From Adrian.Aichner@t-online.de Tue May 1 06:35:39 2001 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA22011 for ; Tue, 1 May 2001 06:35:38 -0400 Received: from fwd06.sul.t-online.com by mailout01.sul.t-online.com with smtp id 14uXVJ-0003Rp-03; Tue, 01 May 2001 12:35:37 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.219]) by fwd06.sul.t-online.com with esmtp id 14uXVW-0r2mvoC; Tue, 1 May 2001 12:35:50 +0200 To: rendhalver@users.sourceforge.net Cc: xemacs-beta@xemacs.org Subject: Re: [repost] problem with custom.el file options not being noticed References: <15086.36614.420634.495114@ulthwe.dyndns.org> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: <3dapcq6n.fsf@rapier.ecf.teradyne.com> Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Peter" == Peter Brown writes: Peter> now some of my options are not being recognised Peter> build package ones so far are all i have noticed so far I don't understand above statement. Please send me your custom.el and init.el if you don't mind. Best regards, Adrian Peter> havent checked all of them Peter> any idea what is causing this ?? Peter> did i do the wrong thing in copying from my old file ?? Peter> thanks in advance Peter> -- Peter> ------------------------------------------------------------------------- Peter> Peter Brown Peter> Web Programmer/Sys Admin/Apache Admin Education Development Web Peter> peter@edw.com.au www.edw.com.au Peter> rendhalver@users.sourceforge.net Peter> ------------------------------------------------------------------------- -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From rendhalver@users.sourceforge.net Tue May 1 07:43:43 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA24808 for ; Tue, 1 May 2001 07:43:36 -0400 Received: from ulthwe.dyndns.org (p230-tnt1.brs.ihug.com.au [203.173.188.230]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id VAA29743; Tue, 1 May 2001 21:43:17 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p230-tnt1.brs.ihug.com.au [203.173.188.230] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15086.41161.760202.319812@ulthwe.dyndns.org> Date: Tue, 1 May 2001 21:40:57 +1000 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: [repost] problem with custom.el file options not being noticed In-Reply-To: <3dapcq6n.fsf@rapier.ecf.teradyne.com> References: <15086.36614.420634.495114@ulthwe.dyndns.org> <3dapcq6n.fsf@rapier.ecf.teradyne.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: multipart/mixed; boundary="Multipart_Tue_May__1_21:40:57_2001-1" Content-Transfer-Encoding: 7bit --Multipart_Tue_May__1_21:40:57_2001-1 Content-Type: text/plain; charset=US-ASCII Adrian Aichner writes: > >>>>> "Peter" == Peter Brown writes: > > Peter> now some of my options are not being recognised > > Peter> build package ones so far are all i have noticed so far > > I don't understand above statement. some of the options i copied from my previous custom.el file are not being recognised, the build package ones were the only ones i noticed at that time, a few others i have noticed are not being recognised now too > Please send me your custom.el and init.el if you don't mind. ok here they are --Multipart_Tue_May__1_21:40:57_2001-1 Content-Type: text/plain; type=emacs-lisp; charset=US-ASCII Content-Disposition: attachment; filename="custom.el" Content-Transfer-Encoding: quoted-printable (custom-set-variables '(recent-files-permanent-first t) '(ssh-remote-user "rendhalver") '(cperl-indent-parens-as-block t) '(backup-by-copying-when-linked t) '(paren-mode (quote sexp) nil (paren)) '(smtpmail-smtp-server "smtp.ihug.com.au") '(version-control t) '(smtpmail-smtp-service "smtp") '(fill-column 80) '(backup-by-copying t) '(backup-by-copying-when-mismatch t) '(delete-old-versions t) '(ssh-host "edw.com.au") '(html-helper-use-expert-menu t) '(buffers-menu-submenus-for-groups-p t) '(auto-save-directory "/home/rendhalver/.xemacs/.autosave/") '(save-place t) '(buffers-menu-max-size nil) '(recent-files-actions-on-top t) '(wwi-auto-install-on-startup-flag t nil (where-was-i-db)) '(recent-files-permanent-submenu t) '(shadow-todo-file "/home/rendhalver/.xemacs/.shadow_todo") '(recent-files-save-file "/home/rendhalver/.xemacs/.recent-files.el") '(recent-files-commands-submenu t) '(smtpmail-queue-mail nil) '(dired-gnutar-program "tar") '(save-place-file "~/.xemacs/.emacs-places") '(signal-error-on-buffer-boundary nil) '(shell-multiple-shells t) '(eshell-directory-name "~/.xemacs/.eshell/") '(dired-ls-F-marks-symlinks nil) '(toolbar-mail-reader (quote vm)) '(cperl-font-lock t) '(user-full-name "Peter Brown" t) '(recent-files-add-menu-before nil) '(shadow-info-file "/home/rendhalver/.xemacs/.shadows") '(permanent-buffers-mode t nil (permanent-buffers)) '(cperl-hairy t) '(complex-buffers-menu-p t) '(user-mail-address "rendhalver@users.sourceforge.net") '(query-user-mail-address nil) '(smtpmail-queue-dir "~/.xemacs/Mail/queued-mail/") '(font-lock-mode t nil (font-lock)) '(smtpmail-default-smtp-server "smtp.ihug.com.au") '(recent-files-include-save-now t)) '(cperl-autoindent-on-semi t) '(cperl-electric-keywords t) '(cperl-electric-parens t) '(cperl-electric-parens-mark t) '(cperl-hairy t) '(cperl-here-face (quote font-lock-string-face)) '(cperl-indent-level 4) '(cperl-label-offset -4) '(build-configure--prefix "/usr/local/xemacs-beta") '(build-configure--srcdir "/usr/local/src/xemacs/xemacs-21.5") '(build-configure--with-gnome "no") '(build-cvs-checkout-dir "xemacs-21.5") '(build-cvs-checkout-parent-dir "/usr/local/src/xemacs") '(build-cvs-xemacs-release "release-21-5") '(message-auto-save-directory "~/.xemacs/Mail/drafts/") '(message-directory "~/.xemacs/Mail/") '(message-kill-buffer-on-exit t) '(message-send-mail-function (quote smtpmail-send-it)) '(html-helper-use-expert-menu t) (custom-set-faces '(info-node ((t (:bold t)))) '(font-lock-string-face ((((class color) (background light)) (:foregroun= d "green4")))) '(cperl-hash-face ((((class color) (background light)) (:foreground "Red= ")))) '(hyper-apropos-section-heading ((t (:bold t)))) '(vm-highlight-url-face ((((class color) (background light)) (:foregroun= d "Red")))) '(bold-italic ((t (:bold t :italic t))) t) '(message-header-newsgroups-face ((((class color) (background light)) (:= foreground "blue4" :bold t))))) --Multipart_Tue_May__1_21:40:57_2001-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Tue_May__1_21:40:57_2001-1 Content-Type: text/plain; type=emacs-lisp; charset=US-ASCII Content-Disposition: attachment; filename="init.el" Content-Transfer-Encoding: quoted-printable ;; -*- Mode: Emacs-Lisp -*- ;; Copyright (C) 2000, 2001 Ben Wing. ;; Author: Mostly Ben Wing ;; Maintainer: XEmacs Development Team ;; Keywords: sample, initialization ;; This file is part of XEmacs. ;; XEmacs is free software; you can redistribute it and/or modify it ;; under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; XEmacs is distributed in the hope that it will be useful, but ;; WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ;; General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with XEmacs; see the file COPYING. If not, write to the = ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;; #### to do: ;; -- #### figure out how init.el and custom.el interact and put ;; documentation about it here. (perhaps it already exists ;; elsewhere?) ;;; This is a sample init.el file. It can be used without ;;; modification as your init.el or .emacs. In older versions of ;;; XEmacs, this file was called .emacs and placed in your home ;;; directory. (Under MS Windows, that directory is controlled by the ;;; HOME environment variable and defaults to C:\. You can find out ;;; where XEmacs thinks your home directory is using ;;; ;;; ESC : (expand-file-name "~") ;;; ;;; . This means type ESC, then colon, then the following text, then hit= ;;; return.) In more recent versions of XEmacs, this file has migrated to= ;;; the .xemacs/ subdirectory and is called init.el. Other files are ;;; also located here, such as custom.el (the auto-generated file ;;; containing Customization options that you saved when using ;;; Options->Save Options). ;;; Changes to your init.el file will not take effect until the next ;;; time you start up XEmacs, unless you load it explicitly with ;;; ;;; M-x load-file RET ~/.xemacs/init.el RET ;;; The language that this file (and most other XEmacs init files) is ;;; written in is called "XEmacs Lisp" or more commonly "Elisp". ;;; There are many sources of further information: ;;; -- the XEmacs User's Manual (Access using the online Info browser: ;;; Use `Help->Info (Online Docs)->XEmacs User's Manual' (if ;;; there is such an entry); or get to the Info contents page ;;; using `Help->Info Contents' or `C-h i', and then ;;; *middle-click* the XEmacs link or move the cursor into the ;;; link and hit ENTER. This manual contains a great deal of ;;; documentation on customization: Scroll down to the ;;; Customization link and select it in the same fashion as for ;;; the XEmacs link just mentioned.) ;;; -- the XEmacs FAQ (`C-h F' for the local version; get either the ;;; local version or the very latest version off the net using ;;; the Help menu) ;;; -- the XEmacs Lisp Reference Manual, containing detailed ;;; documentation on Elisp. (Access using Info, just like for the ;;; XEmacs User's Manual.) ;;; -- the documentation strings for specific commands, functions, ;;; key sequences, and variables. NOTE: This is *not* the same ;;; information as in the XEmacs User's Manual or XEmacs Lisp ;;; Reference Manual! In general, the doc strings are more ;;; terse and more up-to-date than what is found in the manuals. ;;; Once you understand the general concepts, these doc strings ;;; should be your first point of reference for further ;;; info. (Access using menu entries under `Help->Commands, ;;; Variables, Keys' or using the keyboard: `C-h k' for a key ;;; sequence, `C-h f' for a named command or Elisp function, ;;; `C-h v' for a variable. There is various other useful ;;; information accessible similarly, such as `C-h a' ;;; ["Apropos", i.e. search for a command, function, or variable ;;; by name]; `C-h C-a' ["Apropos Docs", i.e. search through the ;;; text of the doc strings]; `C-h b' to list all key bindings; ;;; `C-h m' to describe the current major and minor modes; etc. ;;; Type `C-h ? ?' for a complete list.) ;;; -- Getting Started with XEmacs [aka the "New User's Guide"], a ;;; more introductory manual than the XEmacs User's Manual. ;;; (Access using Info, just like for the XEmacs User's Manual. ;;; There are some sections on customization here.) ;;; -- the XEmacs tutorial, a very simple introduction to XEmacs for ;;; total beginners. (`C-h t' for English; get the version in ;;; various languages from the Help menu) ;;; -- the XEmacs web site, www.xemacs.org. ;;; -- the XEmacs mailing lists (xemacs-FOO@xemacs.org; ;;; see http://www.xemacs.org/Lists/ for more info. Before ;;; posting, consider looking through the archives -- they go back ;;; years and there is a powerful searching interface. Currently ;;; the archives are at http://list-archive.xemacs.org/, but if ;;; this doesn't work, you can always access them through ;;; www.xemacs.org.) ;;; -- the XEmacs newsgroup, comp.emacs.xemacs. This is ;;; bi-directionally gatewayed with xemacs@xemacs.org. WARNING: ;;; The developers do not normally hang out on this newsgroup. If ;;; you need to contact them, use xemacs-beta@xemacs.org. ;;; -- the XEmacs internals manual, for those interested in working on ;;; the XEmacs C code. (Available through Info.) ;;; -- `Help->About XEmacs' to find out who the maintainers are. =0C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Basic Customization ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; TIP: Control-L characters are ignored in Lisp files and are the ;; standard way of indicating major section divisions. You can enter ;; such a character using C-q C-l. ;; Define a variable to indicate whether we're running XEmacs/Lucid ;; Emacs. (You do not have to defvar a global variable before using ;; it -- you can just call `setq' directly. It's clearer this way, ;; though. Note also how we check if this variable already exists ;; using `boundp', because it's defined in recent versions of ;; XEmacs.) (or (boundp 'running-xemacs) (defvar running-xemacs (string-match "XEmacs\\|Lucid" emacs-version))= ) ;; Define a function to make it easier to check which version we're ;; running. This function already exists in recent XEmacs versions, ;; and in fact all we've done is copied the definition. Note again ;; how we check to avoid clobbering an existing definition. (It's good ;; style to do this, in case some improvement was made to the ;; already-existing function -- otherwise we might subsitute an older ;; definition and possibly break some code elsewhere.) ;; ;; NOTE ALSO: It is in general *NOT* a good idea to do what we're ;; doing -- i.e. provide a definition of a function that is present in ;; newer versions of XEmacs but not older ones. The reason is that it ;; may confuse code that notices the presence of the function and ;; proceeds to use it and other functionality that goes along with it ;; -- but which we may not have defined. What's better is to create ;; the function with a different name -- typically, prefix it with the ;; name of your module, which in this case might be `Init-'. For ;; `emacs-version>=3D' we make an exception because (a) the function has ;; been around a long time, (b) there isn't really any other ;; functionality that is paired with it, (c) it's definition hasn't ;; changed and isn't likely to, and (d) the calls to `emacs-version>=3D' ;; or its renamed replacement would be scattered throughout the code ;; below, and with a replacement name the code would become ;; significantly less portable into someone else's init.el file. (BUT ;; NOTE BELOW: We do follow the procedure outlined above with renaming ;; in a different case where the specifics are much different.) ;; ;; TIP: At this point you may be wondering how I wrote all these nice, ;; long, nicely-justified textual stretches -- didn't I go crazy ;; sticking in the semicolons everywhere and having to delete them and ;; rearrange everything whenever I wanted to make any corrections to ;; the text? The answer is -- of course not! Use M-q. This does all ;; the magic for you, justifying and breaking lines appropriately and ;; putting any necessary semicolons or whatever at the left (it ;; figures out what this ought to be by looking in a very clever ;; fashion at what's already at the beginning of each line in the ;; paragraph). You may need `filladapt' set up (it's done below in ;; this file) in order for this to work properly. Finally, if you ;; want to turn on automatic filling (like in a word processor, but ;; not quite as automatic), use M-x auto-fill-mode or the binding set ;; up below in this file (Meta-F9). (or (fboundp 'emacs-version>=3D) (defun emacs-version>=3D (major &optional minor patch) "Return true if the Emacs version is >=3D to the given MAJOR, MINOR= , and PATCH numbers. The MAJOR version number argument is required, but the other arguments argument are optional. Only the Non-nil arguments are used in the test." (let ((emacs-patch (or emacs-patch-level emacs-beta-version -1))) (cond ((> emacs-major-version major)) ((< emacs-major-version major) nil) ((null minor)) ((> emacs-minor-version minor)) ((< emacs-minor-version minor) nil) ((null patch)) ((>=3D emacs-patch patch)))))) ;; 19.13 was released ages ago (Sep. 1995), and lots of graphic and ;; window-system stuff doesn't work before then. (or (not running-xemacs) (emacs-version>=3D 19 13) (error "This init file does not support XEmacs before 19.13")) ;; Here are some example code snippets that you can use if you need to ;; conditionalize on a particular version of Emacs (in general, though, ;; it is much better to use `fboundp', `featurep', or other such ;; feature-specific checks rather than version-specific checks): ; (cond ((and running-xemacs ; (emacs-version>=3D 21 2)) ; ;; ; ;; Code requiring XEmacs version 21.2 or newer goes here ; ;; ; )) ; (cond ((emacs-version >=3D 19 0) ; ;; ; ;; Code for any vintage-19 Emacs goes here ; ;; ; )) ; (cond ((and (not running-xemacs) ; (emacs-version>=3D 20 0)) ; ;; ; ;; Code specific to GNU Emacs 20 or newer (not XEmacs) goes here= ; ;; ; )) =0C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Key Definitions ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Set up the function keys to do common tasks to reduce Emacs pinky ;;; and such. ;; You can set a key sequence either to a command or to another key ;; sequence. (Use `C-h k' to map a key sequence to its command. Use ;; `C-h w' to go the other way.) In general, however, it works better ;; to specify the command name. For example, it does not currently ;; work to say ;; (global-set-key 'f5 "\C-x\C-f") ;; The reason is that macros (which is what the string on the right ;; really is) can't currently use the minibuffer. This is an ;; extremely longstanding bug in Emacs. Eventually, it will be ;; fixed. (Hopefully ..) ;; Note also that you may sometimes see the idiom ;; (define-key global-map ...) ;; in place of (global-set-key ...). These are exactly the same. ;; Here I've tried to put all the most common commands on simple ;; non-modifier function keys to take the pressure off your modifier ;; fingers. Furthermore, on my keyboard at least, the function keys ;; are grouped into three groups of four with spaces between them, and ;; so it's easier to hit the keys at the edge of the groups -- ;; i.e. f1, f4, f5, f8, f9, and f12. Finally, you may note that f9, ;; f11, and f12 are purposely left blank. [F6 is defined below.] ;; That's because I use them for _, {, and } -- see below. (global-set-key 'f1 'advertised-undo) ;; Undo (global-set-key 'f2 'kill-primary-selection) ;; Cut (global-set-key 'f3 'copy-primary-selection) ;; Copy (global-set-key 'f4 'yank-clipboard-selection) ;; Paste (global-set-key 'f5 'find-file) ;; C-x C-f (global-set-key 'f7 'save-buffer) ;; C-x C-s ;; I considered having this retain the current column after killing ;; the line, but that messes up the common idiom `f8 move-cursor f4'. (defun Init-kill-entire-line (&optional arg) "Kill the entire line. With prefix argument, kill that many lines from point. Negative arguments kill lines backward. When calling from a program, nil means \"no arg\", a number counts as a prefix arg." (interactive "*P") (let ((kill-whole-line t)) (beginning-of-line) (call-interactively 'kill-line))) (global-set-key 'f8 (if (fboundp 'kill-entire-line) 'kill-entire-line 'Init-kill-entire-lin= e)) ;; A keystroke repeated incredible amounts of times. We need to patch ;; into the isearch keymap so that repeat searches while in isearch ;; mode still work. Here we show how to make a key in a keymap have the ;; same binding as another key in the keymap, without knowing what the ;; binding is in advance; instead, we find it with `lookup-key'. This ;; way, if the binding of C-s changes (e.g. to a different function) but ;; the meaning is basically the same, we automatically do the right thing= =2E ;; If we put in the actual binding, which is 'isearch-repeat-forward, ;; this automatic tracking wouldn't happen. ;; ;; TIP: To find out what the (lookup-key ...) expression evaluates to, ;; move just to the right of the closing paren and type C-x C-e. (global-set-key 'f10 'isearch-forward) (define-key isearch-mode-map 'f10 (lookup-key isearch-mode-map "\C-s")) (define-key minibuffer-local-isearch-map 'f10 (lookup-key minibuffer-local-isearch-map "\C-s")) (global-set-key '(shift f10) 'isearch-backward) (define-key isearch-mode-map '(shift f10) (lookup-key isearch-mode-map "\= C-r")) (define-key minibuffer-local-isearch-map '(shift f10) (lookup-key minibuffer-local-isearch-map "\C-r")) ;; Here we define our own function and then bind a key to it. (defun start-or-end-kbd-macro () ;; A doc string. This is optional. "Start defining a keyboard macro, or stop if we're already defining." ;; IMPORTANT: Any function bound to a key MUST have an interactive spec= , ;; usually just the following line: (interactive) (if defining-kbd-macro (end-kbd-macro) (start-kbd-macro nil))) ;; The macros used to have their place in the function keys, but I ;; find that I use them significantly less than the really basic ;; things on the function keys. When using a macro, you call the ;; macro much more than define it, so the setup below makes some ;; sense. (global-set-key '(shift kp-multiply) 'start-or-end-kbd-macro) (global-set-key 'kp-multiply 'call-last-kbd-macro) ;; C-x e ;; Note that you can refer to a key sequence either using an ASCII ;; string or the "long way", with vectors and conses. You saw above ;; (in a comment) the string form for specifying the key sequence `C-x ;; C-f', which is "\C-x\C-f". (For those curious, \C-x is just an ;; escape sequence that puts a ^X character into the string. Thus, ;; the string just mentioned really just contains two characters, a ^X ;; and a ^F.) The long way to specify the sequence `C-x C-f' would be ;; ;; [(control x) (control f)] ;; ;; The long format lets you specify all possible key sequences, while the= ;; string form only lets you specify sequences involving ASCII characters= ;; and/or modifiers and in fact only a subset of them. ;; ;; Other examples are: ;; ;; [(control x) n] ;; ;; (You can leave out the parens when there is no modifier specified in= ;; the keystroke, and that's normally done.) ;; ;; [(shift control meta left)] ;; ;; (You can put more than one modifier in a keystroke.) ;; ;; (shift control meta left) ;; ;; (This is the same as the previous. when there's only one keystroke = in ;; the sequence, you can leave out the brackets, and that's normally ;; done.) ;; ;; [(control x) (shift button3)] ;; ;; (You can refer to mouse buttons just like keys -- apply modifiers, ;; intermingle them in key sequences, etc. But there's only problem ;; here, which is that with the mouse you don't just have one possible= ;; gesture, like with keys. You'd really like to control button-down,= ;; button-up, button-click (down and up without selecting anything), ;; button drag, button double-click, etc. This is normally done by ;; binding your key sequence to `mouse-track', and then putting hooks ;; onto `mouse-track-click-hook', `mouse-track-drag-up-hook', etc. to ;; customize the specific behavior.) ;; ;; 'left ;; ;; (Ultimate reductionism -- no brackets, no parens. This is the form,= in ;; that, that the 'f1, 'f2, etc. took, which where in fact "long" ;; forms.) ;; = ;; '(control C) ;; ;; (You cannot use '(control shift c) here. This applies whenever Shif= t + ;; key translates to a single character. Note also that you can't use= ;; "\C-C" either; this refers to the non-shifted C-c, just like "\C-c"= ;; would.) ;; ;; '(control \() ;; (Put a backslash in front of characters used in Lisp syntax.) ;; ;; Also, you can find out the name of a key using C-h c. WARNING: ;; This does not report the correct name of the keys named `delete', ;; `backspace', `return', `tab', `space', `escape', and `linefeed'! ;; (More correct results can be achieved using ;; ;; ESC : (read-key-sequence "foo: ") ;; ;; .) ;;;;;;;;;;;;;;;;;;;;;;;; ;; Keystrokes to conveniently switch buffers. ;; F6 is invaluable for flipping back and forth between two buffers ;; you're working with. (global-set-key 'f6 'switch-to-other-buffer) ;; M-C-l (global-set-key '(meta n) 'switch-to-next-buffer-in-group) (global-set-key '(meta p) 'switch-to-previous-buffer-in-group) (global-set-key '(meta N) 'switch-to-next-buffer) (global-set-key '(meta P) 'switch-to-previous-buffer) ;; Define our own function to deal with the possibility that the newer ;; stuff in the gutter code may not be present -- i.e. we're running ;; an older XEmacs. Note that we avoid trying to "helpfully" define a ;; function that is present in new versions of XEmacs, but not in ;; older ones. That can very easily screw up code trying to determine ;; what functionality is present using `fboundp' checks. See above, ;; near `emacs-version>=3D', for a full discussion of this. (defun Init-buffers-tab-omit (buf) ;; a function specifying the buffers to omit from the buffers tab. ;; This is passed a buffer and should return non-nil if the buffer ;; should be omitted. If the standard buffers-tab functionality is ;; there, we just call it to do things "right". Otherwise we just ;; omit invisible buffers, snarfing the code from ;; `buffers-menu-omit-invisible-buffers'. (if (boundp 'buffers-tab-omit-function) (funcall buffers-tab-omit-function buf) (not (null (string-match "\\` " (buffer-name buf)))))) (defun switch-to-next-buffer (&optional n) "Switch to the next-most-recent buffer. This essentially rotates the buffer list forward. N (interactively, the prefix arg) specifies how many times to rotate forward, and defaults to 1. Buffers whose name begins with a space \(i.e. \"invisible\" buffers) are ignored." ;; Here is a different interactive spec. Look up the function ;; `interactive' (i.e. `C-h f interactive') to understand how this ;; all works. (interactive "p") (dotimes (n (or n 1)) (loop do (bury-buffer (car (buffer-list))) while (Init-buffers-tab-omit (car (buffer-list)))) (switch-to-buffer (car (buffer-list))))) (defun buffers-menu-omit-invisible-buffers (buf) "For use as a value of `buffers-menu-omit-function'. Omits normally invisible buffers (those whose name begins with a space)."= (not (null (string-match "\\` " (buffer-name buf))))) (defvar Init-buffers-tab-grouping-regexp = '("^\\(gnus-\\|message-mode\\|mime/viewer-mode\\)" "^\\(emacs-lisp-\\|lisp-\\)") ;; If non-nil, a list of regular expressions for buffer grouping. ;; Each regular expression is applied to the current major-mode symbol ;; name and mode-name, if it matches then any other buffers that match ;; the same regular expression be added to the current group. This is ;; a copy of `buffers-tab-grouping-regexp'. ) (defun Init-select-buffers-tab-buffers (buffer-to-select buf1) ;; Specifies the buffers to select from the buffers tab. This is ;; passed two buffers and should return non-nil if the second buffer ;; should be selected. If the standard buffers-tab functionality is ;; there, we just call it to do things "right". Otherwise, we group ;; buffers by major mode and by `Init-buffers-tab-grouping-regexp'. ;; [We've copied `select-buffers-tab-buffers-by-mode' and ;; `buffers-tab-grouping-regexp'.] (if (boundp 'buffers-tab-selection-function) (funcall buffers-tab-selection-function buffer-to-select buf1) (let ((mode1 (symbol-name (symbol-value-in-buffer 'major-mode buf1)))= (mode2 (symbol-name (symbol-value-in-buffer 'major-mode = buffer-to-select))) (modenm1 (symbol-value-in-buffer 'mode-name buf1)) (modenm2 (symbol-value-in-buffer 'mode-name buffer-to-select))) (cond ((or (eq mode1 mode2) (eq modenm1 modenm2) (and (string-match "^[^-]+-" mode1) (string-match (concat "^" (regexp-quote = (substring mode1 0 (match-end 0)))) mode2)) (and Init-buffers-tab-grouping-regexp (find-if #'(lambda (x) (or (and (string-match x mode1) (string-match x mode2)) (and (string-match x modenm1) (string-match x modenm2)))) Init-buffers-tab-grouping-regexp))) t) (t nil))))) (defun switch-to-previous-buffer (&optional n) "Switch to the previously most-recent buffer. This essentially rotates the buffer list backward. N (interactively, the prefix arg) specifies how many times to rotate backward, and defaults to 1. Buffers whose name begins with a space \(i.e. \"invisible\" buffers) are ignored." (interactive "p") (dotimes (n (or n 1)) (loop do (switch-to-buffer (car (last (buffer-list)))) while (Init-buffers-tab-omit (car (buffer-list)))))) (defun switch-to-next-buffer-in-group (&optional n) "Switch to the next-most-recent buffer in the current group. This essentially rotates the buffer list forward. N (interactively, the prefix arg) specifies how many times to rotate forward, and defaults to 1. Buffers whose name begins with a space \(i.e. \"invisible\" buffers) are ignored." (interactive "p") (dotimes (n (or n 1)) (let ((curbuf (car (buffer-list)))) (loop do (bury-buffer (car (buffer-list))) while (or (Init-buffers-tab-omit (car (buffer-list))) (not (Init-select-buffers-tab-buffers curbuf (car (buffer-list))))))) (switch-to-buffer (car (buffer-list))))) (defun switch-to-previous-buffer-in-group (&optional n) "Switch to the previously most-recent buffer in the current group. This essentially rotates the buffer list backward. N (interactively, the prefix arg) specifies how many times to rotate backward, and defaults to 1. Buffers whose name begins with a space \(i.e. \"invisible\" buffers) are ignored." (interactive "p") (dotimes (n (or n 1)) (let ((curbuf (car (buffer-list)))) (loop do (switch-to-buffer (car (last (buffer-list)))) while (or (Init-buffers-tab-omit (car (buffer-list))) (not (Init-select-buffers-tab-buffers curbuf (car (buffer-list))))))))) ;;;;;;;;;;;;;;;;;;;;;;;; ;; Other text keystrokes. ;; Make a keystroke to insert a literal TAB character. (`C-q TAB' is ;; annoying because difficult to repeat.) Note that this does not work ;; in TTY frames, where TAB and Shift-TAB are indistinguishable. (define-key global-map '(shift tab) 'tab-to-tab-stop) ;; Toggle auto-filling. Useful with text but annoying with code. You ;; can manually fill with M-q. (global-set-key '(meta f9) 'auto-fill-mode) ;; You cannot say '(meta shift t) here -- see above. (if (fboundp 'transpose-line-down) (global-set-key '(meta T) 'transpose-line-down)) (if (fboundp 'transpose-line-up) (global-set-key '(control T) 'transpose-line-up)) ;;;;;;;;;;;;;;;;;;;;;;;; ;; Rearrange some inconvenient bindings. ;; ESC ESC ESC is a useful command, but too long. ESC ESC would be ;; much more logical, but interferes with Meta + keypad/arrow keys on ;; TTY's. But most people only use window systems and no such problem ;; exists there, so set up the more logical binding there. ;; ;; Note also the use of if vs. cond/when/unless/or/and to express ;; conditional statements. The difference is purely stylistic. (when (console-on-window-system-p) (global-set-key '(meta escape) 'keyboard-escape-quit) (define-key isearch-mode-map '(meta escape) 'isearch-cancel)) ;; The standard definition of C-z causes iconification on window ;; systems, which is both useless and annoying. Instead, bind it to a ;; useful command that's not on any keys. (This also makes a neat ;; parallelism with M-z, which does zap-to-char.) Don't override the ;; TTY binding, which does "Suspend". If you want this new binding on ;; TTY's, and can train yourself to use C-x C-z to suspend, then ;; remove or comment out the `when' statement. (Here's the proper way ;; to comment out such a statement: ;; ;; ;(when (console-on-window-system-p) ;; (global-set-key "\C-z" 'zap-up-to-char) ;; ; ) ;; ;; To do this, I first moved the closing paren to a new line, ;; reindented with TAB, then added the semicolons.) = (when (console-on-window-system-p) (global-set-key "\C-z" 'zap-up-to-char)) ;; When not on a TTY, remove the binding of C-x C-c, which normally ;; exits XEmacs. It's easy to hit this by mistake, and that can be ;; annoying. You can always quit with the "Exit XEmacs" option on the ;; File menu. (when (console-on-window-system-p) (global-set-key "\C-x\C-c" nil)) ;; Make C-k always delete the whole line, which is what most people want,= ;; anyway. (setq kill-whole-line 'always) ;; M-k does the old behavior (kill to end of line). (global-set-key '(meta k) #'(lambda () (interactive) (if (fboundp 'historical-kill-line) (call-interactively #'historical-kill-line) (let ((kill-whole-line nil)) (call-interactively #'kill-line))))) ;; and Meta-Shift-K does what used to be on M-k, and should ;; (hopefully) even work under TTY's. (global-set-key '(meta K) 'kill-sentence) ;; Make sure we get Windows-like shifted-motion key selection behavior ;; on recent XEmacs versions. (if (boundp 'shifted-motion-keys-select-region) (setq shifted-motion-keys-select-region t) ;; otherwise, try the pc-select package -- = (condition-case nil (progn (require 'pc-select) (pc-select-mode 1)) (error nil))) ;; The following commented-out code rearranges the keymap in an ;; unconventional but extremely useful way for programmers. Parens ;; and braces are both available without using the shift key (using ;; the bracket keys and f11/f12, respectively). Brackets (much less ;; used) are the shifted versions of the new paren keys (i.e. where ;; the braces normally are). ;; ;; The idea for this comes from Jamie Zawinski. ;; ;; Also make a convenient keystroke for _, used constantly in C code. ;; ;; NOTE: you can (semi-) conveniently uncomment a region using ;; C-u M-x comment-region, or the "Uncomment Region" menu item on the ;; Lisp menu in new enough versions of XEmacs. ;(keyboard-translate ?[ ?() ;(keyboard-translate ?] ?)) ;(keyboard-translate ?{ ?[) ;(keyboard-translate ?} ?]) ;;; We don't use `keyboard-translate' for these because it messes up ;;; bindings for M-F9 and the like. ;(define-key key-translation-map 'f11 "{") ;(define-key key-translation-map 'f12 "}") ;(define-key key-translation-map 'f9 "_") ;;;;;;;;;;;;;;;;;;;;;;;; ;; Useful programming-related keystrokes. (defun describe-foo-at-point () "Show the documentation of the Elisp function and variable near point. This checks in turn: -- for a function name where point is -- for a variable name where point is -- for a surrounding function call " (interactive) (let (sym) ;; sigh, function-at-point is too clever. we want only the first hal= f. (cond ((setq sym (ignore-errors (with-syntax-table emacs-lisp-mode-syntax-table (save-excursion (or (not (zerop (skip-syntax-backward "_w"))) (eq (char-syntax (char-after (point))) ?w) (eq (char-syntax (char-after (point))) ?_) (forward-sexp -1)) (skip-chars-forward "`'") (let ((obj (read (current-buffer)))) (and (symbolp obj) (fboundp obj) obj)))))) (describe-function sym)) ((setq sym (variable-at-point)) (describe-variable sym)) ;; now let it operate fully -- i.e. also check the ;; surrounding sexp for a function call. ((setq sym (function-at-point)) (describe-function sym))))) (global-set-key '(shift f4) 'next-error) ;; C-x ` (global-set-key '(control f4) 'previous-error) (global-set-key '(shift f5) 'find-library) (global-set-key '(control f5) 'find-function) (global-set-key '(meta f5) 'find-variable) (global-set-key '(shift f11) 'describe-foo-at-point) (global-set-key '(control f11) 'eval-last-sexp) ;; Edebug is a source-level debugger for Emacs Lisp programs. Put ;; the cursor at the end of a function definition and "instrument" it ;; with this command; then, you can single step through it the next ;; time it's run. (global-set-key '(meta f11) 'edebug-defun) (global-set-key '(meta f12) 'add-change-log-entry) ;; This nicely parallels M-*, which pops the tag stack. See below for ;; how to set up tags. (global-set-key '(control *) 'find-tag-at-point) ;; Define a function to conveniently determine where time is being ;; spent when executing commands or Lisp code. (defun toggle-profiling () "Start profiling, or stop it and print results. This lets you figure out where time is being spent when executing Lisp co= de." (interactive) = (if (profiling-active-p) = (progn = (stop-profiling) = (message "...Finished profiling") (profile-results)) (message "Profiling...") = (clear-profiling-info) = (start-profiling))) ;; Note that sequences of C-c plus a letter are specifically ;; reserved for users and should never be bound by any packages. (global-set-key "\C-cp" 'toggle-profiling) ;; LISPM bindings of Control-Shift-C and Control-Shift-E. ;; See comment above about bindings like this. (define-key emacs-lisp-mode-map '(control C) 'compile-defun) (define-key emacs-lisp-mode-map '(control E) 'eval-defun) ;;;;;;;;;;;;;;;;;;;;;;;; ;; Numeric keypad. ;; The numeric keypad as a whole is underused, and it's a good source ;; of keys to bind to commands. Here we add some useful bindings. ;; Because this is a sample file and I want to avoid unpleasant ;; surprises for novices, I don't actually bind the shared ;; numeric/cursor-motion keys because ;; ;; (a) someone keypads don't have separate motion keys (e.g. laptops?), a= nd ;; (b) TTY's and some X servers might not distinguish the regular and ;; numeric-keypad motion keys. ;; `kill-current-buffer' (defined below) deletes the current ;; buffer. (Don't worry, you will be prompted to save if it's ;; modified.) By repeatedly pressing keypad-minus, you can ;; conveniently reduce the number of open buffers to a manageable size ;; after you've opened a whole bunch of files and finished working on ;; them. Shift plus keypad-minus kills both the current buffer and ;; its window, and Control plus keypad-minus kills just the current ;; window. (global-set-key 'kp-subtract 'kill-current-buffer) (global-set-key '(shift kp-subtract) 'kill-current-buffer-and-window) (global-set-key '(control kp-subtract) 'delete-window) ;; Ugh, modes that use `suppress-keymap' and are dumped with XEmacs will ;; need their own definition. There is no easy way to fix this. (define-key help-mode-map 'kp-subtract 'kill-current-buffer) (define-key help-mode-map '(shift kp-subtract) 'kill-current-buffer-and-window) (define-key list-mode-map 'kp-subtract 'kill-current-buffer) (define-key list-mode-map '(shift kp-subtract) 'kill-current-buffer-and-window) (defun kill-current-buffer () "Kill the current buffer (prompting if it is modified)." (interactive) (kill-buffer (current-buffer))) (defun kill-current-buffer-and-window () "Kill the current buffer (prompting if it is modified) and its window."= (interactive) (kill-buffer (current-buffer)) (delete-window)) (defvar grep-all-files-history nil) (defvar grep-all-files-omitted-expressions '("*~" "#*" ".#*" ",*" "*.elc" "*.obj" "*.o" "*.exe" "*.dll" "*.lib" "*= =2Ea" "*.dvi" "*.class" "*.bin") "List of expressions matching files to be omitted in `grep-all-files-..= =2E'. Each entry should be a simple name or a shell wildcard expression.") (defvar grep-all-files-omitted-directories '("CVS" "RCS" "SCCS") "List of directories not to recurse into in `grep-all-files-...'. Each entry should be a simple name or a shell wildcard expression.") (defun construct-grep-all-files-command (find-segment grep-segment) (let ((omit-annoying (mapconcat #'(lambda (wildcard) (concat "-name '" wildcard "' -or ")) grep-all-files-omitted-expressions ""))) (cond ((eq grep-find-use-xargs 'gnu) (format "find . %s %s -type f -print0 | xargs -0 -e %s" find-segment omit-annoying grep-segment)) (grep-find-use-xargs (format "find . %s %s -type f -print | xargs %s" find-segment omit-annoying grep-segment)) (t (format "find . %s %s -type f -exec %s {} /dev/null \\;" find-segment omit-annoying grep-segment))))) (defun grep-all-files-in-current-directory (command) "Run `grep' in all non-annoying files in the current directory. `Non-annoying' excludes backup files, autosave files, CVS merge files, et= c. More specifically, this is controlled by `grep-all-files-omitted-expressi= ons'. This function does not recurse into subdirectories. If you want this, use \\[grep-all-files-in-current-directory-and-below]." (interactive (progn (require 'compile) (list (read-shell-command "Run grep (like this): " grep-command 'grep-all-files-history)))) (require 'compile) (grep (construct-grep-all-files-command "-name . -or -type d -prune -or" command))) (defun grep-all-files-in-current-directory-and-below (command) "Run `grep' in all non-annoying files in the current directory and belo= w. `Non-annoying' excludes backup files, autosave files, CVS merge files, et= c. More specifically, this is controlled by `grep-all-files-omitted-expressi= ons'. This function recurses into subdirectories. If you do not want this, use \\[grep-all-files-in-current-directory]." (interactive (progn (require 'compile) (list (read-shell-command "Run grep (like this): " grep-command 'grep-all-files-history)))) (require 'compile) (grep (construct-grep-all-files-command ;; prune all specified directories. (mapconcat #'(lambda (wildcard) (concat "-name '" wildcard "' -prune -or ")) grep-all-files-omitted-directories "") command))) (defun clear-select () "Repeatedly select ever larger balanced expressions around the cursor. Once you have such an expression marked, you can expand to the end of the following expression with \\[mark-sexp] and to the beginning of the previous with \\[backward-sexp]." (interactive "_") ;this means "preserve the active region after this co= mmand" (backward-up-list 1) (let ((end (save-excursion (forward-sexp) (point)))) (push-mark end nil t))) ;; #### no kp-divide because it doesn't (currently) work on MS Windows ;; -- always reports as /. #### this should be fixable. (global-set-key 'kp-add 'query-replace) (global-set-key '(shift kp-add) 'query-replace-regexp) (global-set-key '(control kp-add) 'grep-all-files-in-current-directory) (global-set-key '(meta kp-add) 'grep-all-files-in-current-directory-and-b= elow) (global-set-key 'clear 'clear-select) ;; Note that you can use a "lambda" expression (an anonymous function) ;; in place of a function name. This function would be called ;; `pop-local-mark' and lets you repeatedly cycle back through recent ;; marks (marks are set whenever you begin a selection, begin a ;; successful search, are about to jump to the beginning or end of the ;; buffer, etc.). (global-set-key 'kp-enter (lambda () (interactive) (set-mark-command t)))= (global-set-key '(shift kp-enter) 'repeat-complex-command) (global-set-key 'pause 'repeat-complex-command) ;; useful on Windows-styl= e kbds (global-set-key '(control kp-enter) 'eval-expression) ;;;;;;;;;;;;;;;;;;;;;;;; ;; Misc. ;; If you want button2 to insert the selected text ;; at point (where the text cursor is), instead of at the ;; position clicked, uncomment the following: ;(setq mouse-yank-at-point t) ;; If you like the FSF Emacs binding of button3 (single-click ;; extends the selection, double-click kills the selection), ;; uncomment the following: ;(define-key global-map 'button3 'mouse-track-adjust) ;(add-hook 'mouse-track-click-hook ; (lambda (event count) ; (if (or (/=3D (event-button event) 3) ; (/=3D count 2)) ; nil ;; do the normal operation ; (kill-region (point) (mark)) ; t ;; don't do the normal operations. ; ))) ;; Uncomment this to enable "sticky modifier keys". With sticky ;; modifier keys enabled, you can press and release a modifier key ;; before pressing the key to be modified, like how the ESC key works ;; always. If you hold the modifier key down, however, you still get ;; the standard behavior. I personally think this is the best thing ;; since sliced bread (and a *major* win when it comes to reducing ;; Emacs pinky), but it's disorienting at first so I'm not enabling it ;; here by default. ;(setq modifier-keys-are-sticky t) ;; Enable the command `narrow-to-region' ("C-x n n"). It's a useful ;; command, but possibly confusing to a new user, so it's disabled by ;; default. (put 'narrow-to-region 'disabled nil) ;; Enable obvious hyperlink following with button1. (setq Info-button1-follows-hyperlink t) =0C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Change Some Basic Behaviors ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Change the values of some variables. ;; (t means true; nil means false.) ;; ;; Use C-h v or `Help->Commands, Variables, Keys->Describe Variable...' ;; to find out what these variables mean. (setq find-file-compare-truenames t minibuffer-max-depth nil ) ;; When running ispell, consider all 1-3 character words as correct. (setq ispell-extra-args '("-W" "3")) ;;; pending-delete-mode causes typed text to replace a selection, ;;; rather than append -- standard behavior under all window systems ;;; nowadays. ;;(pending-delete-mode 1) ;;; enable region selection with shift+arrows (on by default in 21.5 ;;; and up) (setq shifted-motion-keys-select-region t) ;;; NOTE: In this context, `windows-nt' actually refers to all MS ;;; Windows operating systems! (when (eq system-type 'windows-nt) ;; Get mail working under Windows. (setq send-mail-function 'smtpmail-send-it) (setq smtpmail-debug-info t) ;; Substitute your info here. ;(setq user-mail-address "ben@xemacs.org") ;(setq user-full-name "Ben Wing") ;(setq smtpmail-smtp-server "pop.tcsn.uswest.net") ;; Make Meta+accelerator traverse to the menu in new enough XEmacs ;; versions. Note that this only overrides Meta bindings that would ;; actually invoke a menu, and the most common commands that are ;; overridden have preferred alternative bindings using the arrow ;; keys. You can always access the overridden ones using ;; Shift+Meta+Key. (Note that "Alt" and "Meta" normally refer to the ;; same key, except on some Sun keyboards [where "Meta" is actually ;; labelled with a diamond] or if you have explicitly made them ;; different under X Windows using `xmodmap'.) ;; ;; More specifically, the following bindings are overridden: ;; ;; M-f (use C-right or Sh-M-f instead) ;; M-e (use M-C-right or Sh-M-e instead) ;; M-v (use Prior aka PgUp or Sh-M-v instead) ;; M-m (use Sh-M-m instead) ;; M-t (use Sh-M-t instead) ;; M-o (normally undefined) ;; M-b (use C-left or Sh-M-b instead) ;; M-h (use M-e h or Sh-M-h instead) ;; in Lisp mode, M-l (use Sh-M-l instead) ;; in C mode, M-c (use Sh-M-c instead) (setq menu-accelerator-enabled 'menu-force) ;; Make Cygwin `make' work inside a shell buffer. (setenv "MAKE_MODE" "UNIX")) ;; This shows how to set up the XEmacs side of tags. (To create the ;; TAGS table, use the `etags' program found in the XEmacs bin ;; directory. Run it in the root directory of your source tree and ;; specify all source and include files on the command line.) ;(setq tag-table-alist ; '( ; ;; Everywhere in the /src/xemacs/gui/ source tree will use the TAGS ; ;; file in /src/xemacs/gui/. ; ("/src/xemacs/gui/" . "/src/xemacs/gui/") ; ;; Everywhere in the /src/xemacs/mule/ source tree will use the TAGS ; ;; file in /src/xemacs/mule/. ; ("/src/xemacs/mule/" . "/src/xemacs/mule/") ; ;; etc. ; ("/src/xemacs/fixup/" . "/src/xemacs/fixup/") ; ("/src/emacs/emacs-20.6/" . "/src/emacs/emacs-20.6/") ; ("/src/xemacs/latest/" . "/src/xemacs/latest/") ; ;; Everywhere else will use the TAGS file in ; ;; /src/xemacs/fixup/. ; ("" . "/src/xemacs/fixup/") ; )) =0C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Change Some Aspects of GUI Appearance ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Changes the text in the window title bar, to switch to MS Windows ;; format (filename goes first, for best identification in icons) and ;; add the version and full executable path. (However, it is not ;; changed unless it currently has the default value, to avoid ;; interfering with a -wn command line argument I may have started ;; XEmacs with.) (if (or (equal frame-title-format "%S: %b") (equal frame-title-format "%b - XEmacs")) (setq frame-title-format (concat "%b - XEmacs " (progn (string-match "\\(.*?\\)\\( XEmacs Lucid\\)?$" emacs-version) (match-string 1 emacs-version)) " [" invocation-directory invocation-name "]"))) ;; Load some nifty sounds that will replace the default beep. ;; ;; (Note that sampled sounds only work if XEmacs was compiled with ;; sound support and we're running on MS Windows, on a machine which ;; has a NetAudio or ESD server, or on the console of a Linux, Sparc, ;; HP, or SGI machine. Otherwise, you just get the standard beep.) ;(cond ((or (and (getenv "DISPLAY") = ; (string-match ":0" (getenv "DISPLAY"))) ; (and (eq (console-type) 'mswindows) ; (device-sound-enabled-p))) ; (load-default-sounds) ; ;; On Windows, at least, the sound "quiet-beep", which is normall= y ; ;; given the symbolic name `quiet' and is used for Quit and such,= ; ;; is just totally disgusting. So make this name correspond to a= ; ;; more innocuous sound. ; (load-sound-file "drum-beep" 'quiet 80)) ; (t ; (setq bell-volume 40) ; (setq sound-alist ; (append sound-alist '((no-completion :pitch 500)))) ; )) ;; Change the continuation glyph face so it stands out more (make-face-bold (glyph-face continuation-glyph)) ;; Change the pointer used during garbage collection. ;; ;; Note that this pointer image is rather large as pointers go, ;; and so it won't work on some X servers (such as the MIT ;; R5 Sun server) because servers may have lamentably small ;; upper limits on pointer size. ;;(if (featurep 'xpm) ;; (set-glyph-image gc-pointer-glyph ;; (expand-file-name "trash.xpm" data-directory))) ;; Here's another way to do that: it first tries to load the ;; pointer once and traps the error, just to see if it's ;; possible to load that pointer on this system; if it is, ;; then it sets gc-pointer-glyph, because we know that ;; will work. Otherwise, it doesn't change that variable ;; because we know it will just cause some error messages. (if (featurep 'xpm) (let ((file (expand-file-name "recycle.xpm" data-directory))) (if (condition-case nil ;; check to make sure we can use the pointer. (make-image-instance file nil '(pointer)) (error nil)) ; returns nil if an error occurred. (set-glyph-image gc-pointer-glyph file)))) (when (featurep 'menubar) ;; Add `dired' to the File menu (add-menu-button '("File") ["Edit Directory" dired]) = ;; Here's a way to add scrollbar-like buttons to the menubar (add-menu-button nil ["Top" beginning-of-buffer]) (add-menu-button nil ["<<<" scroll-down]) (add-menu-button nil [" . " recenter]) (add-menu-button nil [">>>" scroll-up]) (add-menu-button nil ["Bot" end-of-buffer])) ;; Here's a cute hack that shows how to programmatically change some ;; text colors. It changes the background color of the window if it's ;; not on the local machine, or if it's running as root: ;; local emacs background: whitesmoke [i.e. the default color] ;; remote emacs background: palegreen1 ;; root emacs background: coral2 ;; Uncomment to enable. ;(cond ; ((and running-xemacs ; (console-on-window-system-p) ; ;; this does not make much sense on Windows. ; (not (eq system-type 'windows-nt))) ; (let* ((root-p (eq 0 (user-uid))) ; (dpy (or (getenv "DISPLAY") "")) ; (remote-p (not ; (or (string-match "^\\(\\|unix\\|localhost\\):" dpy) ; (let ((s (system-name))) ; (if (string-match "\\.\\(netscape\\|mcom\\)\\.com" s) ; (setq s (substring s 0 (match-beginning 0)))) ; (string-match (concat "^" (regexp-quote s)) dpy))))) ; (bg (cond (root-p "coral2") ; (remote-p "palegreen1") ; (t nil)))) ; (cond (bg ; (let ((def (color-name (face-background 'default))) ; (faces (face-list))) ; (while faces ; (let ((obg (face-background (car faces)))) ; (if (and obg (equal def (color-name obg))) ; (set-face-background (car faces) bg))) ; (setq faces (cdr faces))))))))) =0C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Changing the Modeline ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Enable line numbers and column numbers. This is done in C code now ;; and is very fast. (line-number-mode 1) (column-number-mode 1) ;; Rearrange the modeline so that everything is to the left of the ;; long list of minor modes, which is relatively unimportant but takes ;; up so much room that anything to the right is obliterated. (setq-default modeline-format (list "" (if (boundp 'modeline-multibyte-status) 'modeline-multibyte-status "") (cons modeline-modified-extent 'modeline-modified) (cons modeline-buffer-id-extent (list (cons modeline-buffer-id-left-extent (cons 15 (list (list 'line-number-mode "L%l ") (list 'column-number-mode "C%c ") (cons -3 "%p")))) (cons modeline-buffer-id-right-extent "%17b"))) " " 'global-mode-string " %[(" (cons modeline-minor-mode-extent (list "" 'mode-name 'minor-mode-alist)) (cons modeline-narrowed-extent "%n") 'modeline-process ")%]----" "%-" )) ;; Get rid of modeline information taking up too much space -- in ;; particular, minor modes that are always enabled. (setq pending-delete-modeline-string "") (setq filladapt-mode-line-string "") ;; lazy-lock doesn't have a variable for its modeline name, so we have ;; to do a bit of surgery. (and (assoc 'lazy-lock-mode minor-mode-alist) (setcdr (cdr (cadr (assoc 'lazy-lock-mode minor-mode-alist))) "")) =0C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Customization of Specific Packages ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ******************** ;;; Load gnuserv, which will allow you to connect to XEmacs sessions ;;; using `gnuclient'. ;; If you never run more than one XEmacs at a time, you might want to ;; always start gnuserv. Otherwise it is preferable to specify ;; `-f gnuserv-start' on the command line to one of the XEmacsen. ; (gnuserv-start) ;;; ******************** ;;; Load efs, which uses the FTP protocol as a pseudo-filesystem. ;;; When this is loaded, the pathname syntax /user@host:/remote/path ;;; refers to files accessible through ftp. ;;; (require 'dired) ;; compatible ange-ftp/efs initialization derived from code ;; from John Turner ;; ;; The environment variable EMAIL_ADDRESS is used as the password ;; for access to anonymous ftp sites, if it is set. If not, one is ;; constructed using the environment variables USER and DOMAINNAME ;; (e.g. turner@lanl.gov), if set. (condition-case nil (progn (require 'efs-auto) (if (getenv "USER") (setq efs-default-user (getenv "USER"))) (if (getenv "EMAIL_ADDRESS") (setq efs-generate-anonymous-password (getenv "EMAIL_ADDRESS")) (if (and (getenv "USER") (getenv "DOMAINNAME")) (setq efs-generate-anonymous-password (concat (getenv "USER")"@"(getenv "DOMAINNAME"))))) (setq efs-auto-save 1)) (error (require 'ange-ftp) (if (getenv "USER") (setq ange-ftp-default-user (getenv "USER"))) (if (getenv "EMAIL_ADDRESS") (setq ange-ftp-generate-anonymous-password (getenv "EMAIL_ADDRESS"= )) (if (and (getenv "USER") (getenv "DOMAINNAME")) (setq ange-ftp-generate-anonymous-password (concat (getenv "USER")"@"(getenv "DOMAINNAME"))))) (setq ange-ftp-auto-save 1) )) ;;; ******************** ;;; Load the default-dir.el package which installs fancy handling of ;;; the initial contents in the minibuffer when reading file names. ;(condition-case nil ; (require 'default-dir) ; (error nil)) ;;; ******************** ;;; Put all of your autosave files in one place, instead of scattering ;;; them around the file system. This has many advantages -- e.g. it ;;; will eliminate slowdowns caused by editing files on a slow NFS ;;; server. (*Provided* that your home directory is local or on a ;;; fast server! If not, pick a value for `auto-save-directory' that ;;; is fast fast fast!) ;;; ;;; Unfortunately, the code that implements this (auto-save.el) is ;;; broken on Windows in 21.4 and earlier. (unless (and (eq system-type 'windows-nt) (not (emacs-version>=3D 21 5))) (setq auto-save-directory (expand-file-name "~/.autosave/") auto-save-directory-fallback auto-save-directory auto-save-hash-p nil efs-auto-save t efs-auto-save-remotely nil ;; now that we have auto-save-timeout, let's crank this up ;; for better interactive response. auto-save-interval 2000 ) ;; We load this afterwards because it checks to make sure the ;; auto-save-directory exists (creating it if not) when it's loaded. (require 'auto-save) ) ;;; ******************** ;;; cc-mode (the mode you're in when editing C, C++, and Objective C file= s) ;; Tell cc-mode not to check for old-style (K&R) function declarations. ;; This speeds up indenting a lot. (setq c-recognize-knr-p nil) ;; Change the indentation amount to 4 spaces instead of 2. ;; You have to do it in this complicated way because of the ;; strange way the cc-mode initializes the value of `c-basic-offset'. ;; (add-hook 'c-mode-hook (lambda () (setq c-basic-offset 4))) ;;; ******************** ;;; Load a partial-completion mechanism, which makes minibuffer completio= n ;;; search multiple words instead of just prefixes; for example, the comm= and ;;; `M-x byte-compile-and-load-file RET' can be abbreviated as `M-x b-c-a= RET' ;;; because there are no other commands whose first three words begin wit= h ;;; the letters `b', `c', and `a' respectively. ;;; (load-library "completer") ;;; ******************** ;;; Load crypt, which is a package for automatically decoding and reencod= ing ;;; files by various methods - for example, you can visit a .Z or .gz fil= e, ;;; edit it, and have it automatically re-compressed when you save it aga= in. ;;; = (setq crypt-encryption-type 'pgp ; default encryption mechanism crypt-confirm-password t ; make sure new passwords are correct ;crypt-never-ever-decrypt t ; if you don't encrypt anything, set t= his to ; tell it not to assume that "binary" files ; are encrypted and require a password. ) (require 'crypt) ;;; ******************** ;;; Filladapt is a syntax-highlighting package. When it is enabled it ;;; makes filling (e.g. using M-q) much much smarter about paragraphs ;;; that are indented and/or are set off with semicolons, dashes, etc. (require 'filladapt) (setq-default filladapt-mode t) (add-hook 'c-mode-hook 'turn-off-filladapt-mode) ;;; ******************** ;;; Font-Lock is a syntax-highlighting package. When it is enabled and y= ou ;;; are editing a program, different parts of your program will appear in= ;;; different fonts or colors. For example, with the code below, comment= s ;;; appear in red italics, function names in function definitions appear = in ;;; blue bold, etc. The code below will cause font-lock to automatically= be ;;; enabled when you edit C, C++, Emacs-Lisp, and many other kinds of ;;; programs. ;;; ;;; The "Options" menu has some commands for controlling this as well. ;;; (cond (running-xemacs ;; The commented-out code below is an example of setting up custom ;; font-lock colors. ; ;; If you want the default colors, you could do this: ; ;; (setq font-lock-use-default-fonts nil) ; ;; (setq font-lock-use-default-colors t) ; ;; but I want to specify my own colors, so I turn off all ; ;; default values. ; (setq font-lock-use-default-fonts nil) ; (setq font-lock-use-default-colors nil) (require 'font-lock) ; ;; Mess around with the faces a bit. Note that you have ; ;; to change the font-lock-use-default-* variables *before* ; ;; loading font-lock, and wait till *after* loading font-lock ; ;; to customize the faces. ; ;; string face is green ; (set-face-foreground 'font-lock-string-face "forest green") ; ;; comments are italic and red; doc strings are italic ; (set-face-font 'font-lock-comment-face [italic]) ; ;; Underlining comments looks terrible on tty's ; (set-face-underline-p 'font-lock-comment-face nil 'global 'tty) ; (set-face-highlight-p 'font-lock-comment-face t 'global 'tty) ; (copy-face 'font-lock-comment-face 'font-lock-doc-string-face) ; (set-face-foreground 'font-lock-comment-face "red") ; ;; function names are bold and blue ; (set-face-font 'font-lock-function-name-face [bold]) ; (set-face-foreground 'font-lock-function-name-face "blue") ; ;; misc. faces ; (set-face-font 'font-lock-preprocessor-face [bold]) ; (set-face-font 'font-lock-type-face [italic]) ; (set-face-font 'font-lock-keyword-face [bold]) )) ;;; ******************** ;;; lazy-lock is a package which speeds up the highlighting of files ;;; by doing it "on-the-fly" -- only the visible portion of the ;;; buffer is fontified. The results may not always be quite as ;;; accurate as using full font-lock or fast-lock, but it's *much* ;;; faster. No more annoying pauses when you load files. ;;(add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) ;; I personally don't like "stealth mode" (where lazy-lock starts ;; fontifying in the background if you're idle for 30 seconds) ;; because it takes too long to wake up again on my piddly Sparc 1+. ;;(setq lazy-lock-stealth-time nil) ;;; ******************** ;;; func-menu is a package that scans your source file for function ;;; definitions and makes a menubar entry that lets you jump to any ;;; particular function definition by selecting it from the menu. The ;;; following code turns this on for all of the recognized languages. ;;; Scanning the buffer takes some time, but not much. ;;; ;;; Send bug reports, enhancements etc to: ;;; David Hughes ;;; (cond (running-xemacs (require 'func-menu) (global-set-key '(shift f12) 'function-menu) (add-hook 'find-file-hooks 'fume-add-menubar-entry) (global-set-key "\C-cl" 'fume-list-functions) (global-set-key "\C-cg" 'fume-prompt-function-goto) ;; The Hyperbole information manager package uses (shift button2) = and ;; (shift button3) to provide context-sensitive mouse keys. If yo= u ;; use this next binding, it will conflict with Hyperbole's setup.= ;; Choose another mouse key if you use Hyperbole. (global-set-key '(shift button3) 'mouse-function-menu) ;; For descriptions of the following user-customizable variables, ;; type C-h v (setq fume-max-items 25 fume-fn-window-position 3 fume-auto-position-popup t fume-display-in-modeline-p t fume-menubar-menu-name (if (fboundp 'submenu-generate-accelerator-spec) "Function%_s" "Functions") fume-buffer-name "*Function List*" fume-no-prompt-on-valid-default nil) )) ;;; ******************** ;;; MH is a mail-reading system from the Rand Corporation that relies on = a ;;; number of external filter programs (which do not come with emacs.) ;;; Emacs provides a nice front-end onto MH, called "mh-e". ;;; ;; Bindings that let you send or read mail using MH ;(global-set-key "\C-xm" 'mh-smail) ;(global-set-key "\C-x4m" 'mh-smail-other-window) ;(global-set-key "\C-cr" 'mh-rmail) ;; Customization of MH behavior. (setq mh-delete-yanked-msg-window t) (setq mh-yank-from-start-of-msg 'body) (setq mh-summary-height 11) ;; Use lines like the following if your version of MH ;; is in a special place. ;(setq mh-progs "/usr/dist/pkgs/mh/bin.svr4/") ;(setq mh-lib "/usr/dist/pkgs/mh/lib.svr4/") ;;; ******************** ;;; resize-minibuffer-mode makes the minibuffer automatically ;;; resize as necessary when it's too big to hold its contents. (autoload 'resize-minibuffer-mode "rsz-minibuf" nil t) (resize-minibuffer-mode) (setq resize-minibuffer-window-exactly nil) ;;; ******************** ;;; scroll-in-place is a package that keeps the cursor on the same line (= and in the same column) when scrolling by a page using PgUp/PgDn. (require 'scroll-in-place) (turn-on-scroll-in-place) ;;; ******************** ;;; W3 is a browser for the World Wide Web, and takes advantage of the ve= ry ;;; latest redisplay features in XEmacs. You can access it simply by typ= ing = ;;; 'M-x w3'; however, if you're unlucky enough to be on a machine that i= s = ;;; behind a firewall, you will have to do something like this first: ;(setq w3-use-telnet t ; ;; ; ;; If the Telnet program you use to access the outside world is ; ;; not called "telnet", specify its name like this. ; w3-telnet-prog "itelnet" ; ;; ; ;; If your Telnet program adds lines of junk at the beginning ; ;; of the session, specify the number of lines here. ; w3-telnet-header-length 4 ; ) (load "recent-files") (recent-files-initialize) ; extra config files to load = (setq load-path (cons (expand-file-name "~/.xemacs/elisp/") load-path)) ;(setq load-path (cons (expand-file-name "~/.xemacs/perl/") load-path)) (load-library "xemacs-vm") (load-library "xemacs-mail-aliases") (load-library "xemacs-general") (message "Startup files loaded succesfully.") --Multipart_Tue_May__1_21:40:57_2001-1 Content-Type: text/plain; charset=US-ASCII thanks adrian :) -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- --Multipart_Tue_May__1_21:40:57_2001-1-- From Adrian.Aichner@t-online.de Tue May 1 08:01:06 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA25534 for ; Tue, 1 May 2001 08:01:05 -0400 Received: from fwd05.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14uYq1-0002dc-01; Tue, 01 May 2001 14:01:05 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.231]) by fwd05.sul.t-online.com with esmtp id 14uYq5-2DHnsWC; Tue, 1 May 2001 14:01:09 +0200 To: rendhalver@users.sourceforge.net Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-beta@xemacs.org Subject: Re: [repost] problem with custom.el file options not being noticed References: <15086.36614.420634.495114@ulthwe.dyndns.org> <3dapcq6n.fsf@rapier.ecf.teradyne.com> <15086.41161.760202.319812@ulthwe.dyndns.org> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 67 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Peter" == Peter Brown writes: Peter> Adrian Aichner writes: >> >>>>> "Peter" == Peter Brown writes: >> Peter> now some of my options are not being recognised >> Peter> build package ones so far are all i have noticed so far >> >> I don't understand above statement. Peter> some of the options i copied from my previous custom.el Peter> file are not being recognised, the build package ones were Peter> the only ones i noticed at that time, a few others i have Peter> noticed are not being recognised now too >> Please send me your custom.el and init.el if you don't mind. Peter> ok here they are Peter> (custom-set-variables Peter> '(recent-files-permanent-first t) Peter> '(cperl-here-face (quote font-lock-string-face)) Hah, you appear to have hand-editted the (custom-set* ...) section incorrectly? Move one close-paren from above to the end of the line before (custom-set-faces and you should be a happy camper again. If you think XEmacs/Custom corrupted this section, please try to come up with a test-case. Best regards, Adrian Peter> '(cperl-indent-level 4) Peter> '(cperl-label-offset -4) Peter> '(build-configure--prefix "/usr/local/xemacs-beta") Peter> '(build-configure--srcdir "/usr/local/src/xemacs/xemacs-21.5") Peter> '(build-configure--with-gnome "no") Peter> '(build-cvs-checkout-dir "xemacs-21.5") Peter> '(build-cvs-checkout-parent-dir "/usr/local/src/xemacs") Peter> '(build-cvs-xemacs-release "release-21-5") Peter> '(message-auto-save-directory "~/.xemacs/Mail/drafts/") Peter> '(message-directory "~/.xemacs/Mail/") Peter> '(message-kill-buffer-on-exit t) Peter> '(message-send-mail-function (quote smtpmail-send-it)) Peter> '(html-helper-use-expert-menu t) Peter> (custom-set-faces Peter> '(info-node ((t (:bold t)))) Peter> '(font-lock-string-face ((((class color) (background light)) (:foreground "green4")))) Peter> '(cperl-hash-face ((((class color) (background light)) (:foreground "Red")))) Peter> '(hyper-apropos-section-heading ((t (:bold t)))) Peter> '(vm-highlight-url-face ((((class color) (background light)) (:foreground "Red")))) Peter> '(bold-italic ((t (:bold t :italic t))) t) Peter> '(message-header-newsgroups-face ((((class color) (background light)) (:foreground "blue4" :bold t))))) -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From rendhalver@users.sourceforge.net Tue May 1 08:08:16 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA25853 for ; Tue, 1 May 2001 08:08:14 -0400 Received: from ulthwe.dyndns.org (p230-tnt1.brs.ihug.com.au [203.173.188.230]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id WAA31731; Tue, 1 May 2001 22:08:07 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p230-tnt1.brs.ihug.com.au [203.173.188.230] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15086.42651.901392.121082@ulthwe.dyndns.org> Date: Tue, 1 May 2001 22:05:47 +1000 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: [repost] problem with custom.el file options not being noticed In-Reply-To: References: <15086.36614.420634.495114@ulthwe.dyndns.org> <3dapcq6n.fsf@rapier.ecf.teradyne.com> <15086.41161.760202.319812@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Adrian Aichner writes: > >>>>> "Peter" == Peter Brown writes: > Peter> (custom-set-variables > Peter> '(recent-files-permanent-first t) > > Peter> '(cperl-here-face (quote font-lock-string-face)) > > Hah, you appear to have hand-editted the (custom-set* ...) section > incorrectly? > > Move one close-paren from above to the end of the line before > (custom-set-faces > and you should be a happy camper again. thanks adrian :) i knew it would be something silly i did i thought the order had something to do with it getting read incoreectly > If you think XEmacs/Custom corrupted this section, please try to come > up with a test-case. nah it was just me i think i coppied the custom-faces section and obviously missed the bracket -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From jmadams@stsci.edu Tue May 1 09:20:44 2001 Received: from stsci.edu (tnm.stsci.edu [130.167.1.235]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id JAA30090; Tue, 1 May 2001 09:20:44 -0400 Received: by stsci.edu (SMI-8.6/SMI-SVR4-DNI-8.0) id JAA21823; Tue, 1 May 2001 09:20:22 -0400 Received: from cerberus.sogs.stsci.edu(130.167.174.45) by tnm.stsci.edu via smtp-stsci (V2.1) id xma021815; Tue, 1 May 01 09:20:02 -0400 Received: from anarky by cerberus (8.9.3+Sun/SMI-SVR4) id JAA13896; Tue, 1 May 2001 09:19:56 -0400 (EDT) Received: by anarky (8.9.3+Sun/SMI-SVR4) id JAA03933; Tue, 1 May 2001 09:19:56 -0400 (EDT) Sender: jmadams@stsci.edu To: Ben Wing Cc: Gunnar Evermann , Andy Piper , gunnar@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Agony, persistent solaris8 hang of doom: Can I help debug this? References: <4.3.2.7.2.20010426120851.00da2f00@san-francisco.beasys.com> <4.3.2.7.2.20010426132425.00e9eee0@san-francisco.beasys.com> <3AE8CCDD.E704A3C7@666.com> From: jmadams@stsci.edu (John M. Adams) Date: 01 May 2001 09:19:55 -0400 In-Reply-To: Ben Wing's message of "Thu, 26 Apr 2001 18:35:25 -0700" Message-ID: Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > John -- if you're interested in doing a bit of coding to fix your problem, > here's what i wrote to Gunnar about rewriting the quit handling. this should > probably fix your problem along with it. > > > -- drain_X_queue[] has a bug in it. it should read: > > > while (XEventsQueued (display, QueuedAfterReading)) > XtAppProcessEvent (Xt_app_con, XtIMXEvent); > > NOT: > > while (XtAppPending (Xt_app_con) & XtIMXEvent) > XtAppProcessEvent (Xt_app_con, XtIMXEvent); Where would the value of display come from? Should this be derived and passed down from emacs_Xt_event_pending_p or should drain_X_queue operate on all displays? -- John M. Adams From jmincy@muniversal.com Tue May 1 10:25:54 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA00604 for ; Tue, 1 May 2001 10:25:54 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=DELL) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14ub6A-0004mQ-00 for xemacs-beta@xemacs.org; Tue, 01 May 2001 10:25:54 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15086.50487.690000.951139@muniversal.com> Date: Tue, 1 May 2001 10:16:23 -0400 To: xemacs-beta@xemacs.org Subject: tar-mode on auto-mode-alist X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid I just noticed that tar-mode is a little overrepresented on auto-mode-alist, containing the following: ("\\.tar$" . tar-mode) ("\\.tar$" . tar-mode) ("\\.tar\\'" . tar-mode) ("\\.tgz\\'" . tar-mode) These definitions come from: lisp/files.el (defvar auto-mode-alist '(... ("\\.tar\\'" . tar-mode) xemacs-packages: lisp/os-utils/auto-autoloads.el:(setq auto-mode-alist (cons (cons tar-regexp 'tar-mode) auto-mode-alist)) lisp/os-utils/jka-compr.el: (list (cons "\\.tgz\\'" 'tar-mode)) lisp/os-utils/tar-mode.el(setq auto-mode-alist (cons (cons tar-regexp 'tar-mode) auto-mode-alist)) Perhaps this should be replaced with one pattern that matches .tar, .taz, and .tgz? ("\\.t\\(ar\\|gz\\|az\\)\\'" . tar-mode) -jeff From darrylo@soco.agilent.com Tue May 1 10:52:18 2001 Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA02260 for ; Tue, 1 May 2001 10:52:17 -0400 Received: from msgrel1.and.agilent.com (msgrel1.and.agilent.com [130.30.33.104]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id C042F7C6; Tue, 1 May 2001 08:52:16 -0600 (MDT) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.and.agilent.com (Postfix) with ESMTP id E2ADE124; Tue, 1 May 2001 10:52:11 -0400 (EDT) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id HAA28300; Tue, 1 May 2001 07:52:07 -0700 (PDT) Message-Id: <200105011452.HAA28300@mina.soco.agilent.com> To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Cygwin and subprocess problems in 21.4.1? Reply-To: Darryl Okahata In-Reply-To: Your message of "Mon, 30 Apr 2001 11:04:59 PDT." <4.3.2.7.2.20010430110419.00eaf110@san-francisco.beasys.com> Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: text/plain; charset=US-ASCII Date: Tue, 01 May 2001 07:52:05 -0700 From: Darryl Okahata Andy Piper wrote: > This seems to be improved in cygwin 1.3.1 but not totally fixed. Does point > to a cygwin rather than XEmacs bug though.... Given the various possible permutations of cygwin installs, isn't there a way to determine the cygwin variant (e.g., overall cygwin version, version of cygwin DLL, etc.)? There's got to be a correlation between "cygwin works" and "cygwin doesn't work", and the cygwin variant that users are using. -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From Adrian.Aichner@t-online.de Tue May 1 10:52:59 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA02372 for ; Tue, 1 May 2001 10:52:58 -0400 Received: from fwd03.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14ubWH-0001B1-04; Tue, 01 May 2001 16:52:53 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.221]) by fwd03.sul.t-online.com with esmtp id 14ubWS-1IWZxgC; Tue, 1 May 2001 16:53:04 +0200 To: XEmacs Beta List Subject: mouse-track-insert bug (windows native) now also in 21.4.1, 21.5-b0 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net See the thread starting at http://list-archive.xemacs.org/xemacs-beta/200006/msg00136.html I was looking forward to 21.4 for a long time because this problem was fixed there. Now, alas, the problem is also in 21.4.1 and 21.5-b0. Can we try to fix this now? I will need some help with this. Ben, one suspect is this: > From: Ben Wing > Subject: [PATCH] misc changes, some for 21.4 > To: xemacs-patches@xemacs.org > Date: Sat, 28 Apr 2001 03:50:28 -0400 > Message-Id: <200104280750.DAA29568@gwyn.tux.org> I'm running out of time for today. Perhaps you can have a look at this. I sure miss C-double-click between buffers! C-button1 at that spot runs the command mouse-track-insert Best regards, Adrian -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From andyp@bea.com Tue May 1 12:24:27 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA08364 for ; Tue, 1 May 2001 12:24:22 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA20744; Tue, 1 May 2001 09:24:25 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA03268; Tue, 1 May 2001 09:24:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20010501092408.02e929f0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 May 2001 09:24:52 -0700 To: Andreas Jaeger From: Andy Piper Subject: Re: Warning: XtRemoveGrab asked to remove a widget not on the list Cc: XEmacs Beta Testers In-Reply-To: References: <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:06 PM 5/1/01 +0200, Andreas Jaeger wrote: >Andy Piper writes: > > > I've seen this at frame deletion and never been able to track it > > down. I believe its widget related becuase it came and went while I > > was hacking on them. > >Do you have any idea how to track it down? I can easily reproduce it >but don't know anything about the widget stuff. Absolutely no idea - it seems to be in the guts of the X code. I read all the manuals and put breakpoints everywhere, but I just don't know what the error is indicating. andy From jpmail@limolink.com Tue May 1 17:21:03 2001 Received: from spider.crnet.com (spider.crnet.com [208.242.241.92]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA25710; Tue, 1 May 2001 17:21:03 -0400 Received: from mondas (dante.limolink.com [207.191.205.200]) by spider.crnet.com (8.9.3/8.9.3) with SMTP id RAA29320; Tue, 1 May 2001 17:19:10 -0500 Message-ID: <028d01c0d284$c9c43910$6501a8c0@mondas> From: "James N. Potts" To: "XEmacs NT List" Cc: Subject: 21.4 hang during custom menu activation Date: Tue, 1 May 2001 16:22:11 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_028A_01C0D25A.E0448390" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. ------=_NextPart_000_028A_01C0D25A.E0448390 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit When I attempt to traverse through the customize menu hierarchy, my xemacs process hangs completely. This seems to be triggered by certain menu entries, like "Programming" (see the attached snapshot). I have no idea if this is win32-specific or not. I haven't had a chance to run it under a debugger yet to see if I can figure out where it's hanging. Does anyone else see this, or better yet know how to fix it? -Jim Potts describe-installation: OS: Windows_NT XEmacs 21.4 \"Copyleft\" configured for `i586-pc-win32'. Building XEmacs in \"G:\\src\\xemacs\\nt\". Using compiler \"cl -nologo -W3 -O2 -G5 -MD\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Using portable dumper. Using system malloc. Using DLL version of C runtime library ------=_NextPart_000_028A_01C0D25A.E0448390 Content-Type: image/png; name="custom-menu-hang.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="custom-menu-hang.png" iVBORw0KGgoAAAANSUhEUgAAAuEAAAG5CAIAAACvF33CAAAACXBIWXMAAkVTAAJFUwAOoIj/AAAg AElEQVR4nO3dTbLstnXAcTClSSbegBageaoyviyPsg4P9HZg58P27bblD2UHTwNtIzMV79hVmWsB 2kA2wAygC+HiACBAAiBA/n+leurLJkGQzSZPH4DgtCyLAgAA6MM8z/rFF0qpl5eXM+sCAADwbl3X 5/P5eDy+0H+/vb2dWyEAAADbP51dAQAAAI8v7D/meam2ool5mOfsebqqDPPcc56uKsM895wnpZAz Lcs/m9fkUQAAQI++2JxjWWb7z3lezJSaeRcAAFDFuv5b+szTNK3rmjW/Uv+zYy16KdtGjPJ4KPvm 5MfjlymPR/qqAQBARxLvlTExQO78R5Yy4jHKww5ElmVRan6f8pBzn2Vdf6+UmqZvjhXyn0qpafqr NeU/lFLT9Df9wjZNfzuyLgAARmRGLpFqDLe2EaOYWOTxeFirf3jnXtdX83qangdrZhX7B6XUNP05 c6n/sirzl+PVIC4BAGAfHdzYcYycIm32mX0kTPmZiUsKBii7mbgkMUDRGRSdTVG/pFWISwAA+MXi k7KUstIwKQGKSukzq+lWn2VZXl5eQiGIyaOs66uex0yZpj+9v/VHM7+eaKboTInOmthT3hf8w/sM v7dm+Maa4ffvE/+irDzKuv5Xepiyrv9pwpTNAEW2ASmlpunv7+/+uzXx2/eJv4tMnKb/TqknAADD WZZlnmcTpqRENin3Hj9+/t/jsSxLpP/LND3Nf+o9QHl//Ufz7zT9yYlOlBXETNOf9X/KF6+Yric6 OrHjFfUesujoZJr+Yv5L2EZTwl+dF8a6/of+Tyzyd/uFCU2m6e/6P/Ueheh/p+lbHZ18nPjfSql1 /W16VQEAGIuJSxI7r6TmUWwmTRI3Tc91fX2f2R00xgQlovA/eKf7yv8m8meESbH4ApFf2nqcPEpu u4+dR5FMEmWavl3X363rb0miAACuzW7rKZ9HUZkdd50Wn02me2xuD9ks0/SXafprKEAxb3mbchLp AMXkUbbqo9MqJFEAAJdl+qA4fVMidvSZVW9vbylhh5VE+dCs8/7uH+XELOv6e6et51hpH+49Ph6m bK3ud6atZ11/R1sPAOAUs1BpLUq09Wyua7utR6dP7JFSlmVJGWHWtPWo95adafqTHZrI5p5p+vO6 /sFp7jETp+nP0/SNHZocHBMlix2vbLb7TNPf1/Xfneae92Yd00P2W2vibxV9ZgEA3dsXxMhGmJRm mc3xUZSyhpR9/Cy1Tla3lel9ioxL/vTxT08rjz1RxiX2lGn6Zt8Dk2TTjwlEQhHJNP1Nr8vpNite T9bEb33lfNv/Q54AAJeU1YWjxkBtEZEY5fHz/x7KbvFhCHwAAEaXG23si04OxjTbMYp4DQAABjZN ecn73PmPLGXbc+8xAAAYmfuE4T7XknLvMQAAQGsf8ijLMp9UDQAAgA9o64FSzbtqx72+vkYeuQAA uAliFPys0rg9AADsQ38UAADQI2IUAADQo+0YRQ7jb/+7z+ajAfatQs5/vKrx1e14usHuyux+nsJl GnHSN99+tGaNamxOAYCbcE6AkfPhjlNlUn8Up0Nlkf6VKYWYZw4dXGONDqFOrY5XclOpvZHLPqpS Vl21hqbkyFrMW832VVc9jgHgMi7V1rMsi31BbXk5v+pVSu9DIyVAvuquAAA0tue+HplC0C+OX5xk yqjID2K7HD3FKbbgikz588fnUIcaCAruNLkup/BSa+yK/ZFFPlD50XtfH6yDLNZeKQDcivdilHVu TIpRIlGI9wqxr0ynKHvmIqf43VXN4r1Gyk0rHn6F1hW5fh/hPcicCngjQm/oduSw8TLvyk02r8uG p96iGhxvAHA6+SNcRa+56efGPf1RUip3sMzdzDXSu+WR/dj4KmLW2GylxdcYuuo7E5Xv4u3s8yXa ihRfaaJQ+QV3S/vPFAB64Jz8va/3KTCG20Bn5K6qemJg1GyNsgLOn3ZypeWqvdUoshZSJgCgHT8Z luwz2+BKkyLlOmGaGJyf8rt3aO622xXYt8Zc7deYomB9EstxZiu4W/rcwwBwut1nxaN5FPuMvDv3 Hk/4l/pturuqm6VtFig3bRE9M45XQ+5Gu/BSayzItIykX9flptnbFW/QcRaUi2fV3C4hVFTB4w0A xhI58aafG6dlWV5eXniE281FLvDe63Fooh1QOkfhHOihosRheo0DkkYfAJASz43Lsjwej408irxu HT/thpIlB4utWvLutZeqwImbFlqLnG4SOd4ZnKROvHDp3A83Ug0CEQC3VfXCpzbbemqcf+ud08+9 WlRd+ymbVvvgy9JJKJBejU4qDAD17DjRZS1S4L4eXFXkSOICDACojRgFSin1+vp6dhUAAPiAGAVK KXWBPqoAaqD3N070IUbhQLyteZ5fXl7OrgX2e3t7u/knyB6o4fl8Ki4NaOj19dX+zezmUR6PR9Pq oA/6HEQ2ZXR8guyBGrguoA0ZDXvaetZ1bVEXpZRS0zSxuh5WZ87s87wUqxAaWpZZv7jtJ2j2AIpr dh6bpomcDWz+/ihtfouYY5HVDbc6APfR+CQGGCWf1wMAAFAK9/WgmHV9naZn7lsNqmGmrOsvt1jX q0/ixrbcJ5vsPaNq7pxuySdqnVMPAJadMUr8CXB8vdNF9iS7sQg7QLEvvfUiicT5p+m5L0ypFNwM FJdU2gN844De7M+jhHpRTdM07v30+54ffXBjvXuy+G6s/TNRXza6yg3EjVJPr4H2cyXsAeAOqrT1 fP78uXiYEirQ++Bc78REnz9/Vkp9+vTpp59+isz25Zdfmjl3rMUxTZN5bUIW+xnCBzk7ZJ7nNnGk 04JgX1dk+4ud7dAT7ZnteeJTcmsYqlJKVc2f9iL2JoTm31HVSM0rCW2gyvlETm9TO8J+drf8Epm3 4lMG/cF2BIl2lFKrP0qpMMUc6+u62relOdOdiZ8/fy4SOjTjTaXozbG/7fv2pzxR6hNuwTDFXC3s VIpz+Q8t6w0FnIu9M8/mlCLbYm+U3BzvW/Y8Tn28ix9U9iLtDaFCG5j+iVSNJMoWLoMM89p8WcwL +1zk/JxwpoybV46IRyHmhGYPiGBec4Mx0lWJUUx8cOTLqb8DzsXbDk30Cx2g6Ok6sdFSqUjIhFlm u+wN1Oc7HfapQs+ZNL8LWzKXrnhIEbnqlApEUipZPIwoXuey1/6s0jaDzrK7Mb6uUrK+WZs9yUyY cr3rsfc8bP9cVL7oRM+gJ/74449Kqa+++qpltTGi8jGKHVXYh+zBokIle+OST58+tTkvlErYxIdI 0gGKet/YHZGfXMQkaQqmUvYtte8SXvvKV+QHulPIiSFFWekZsqpJlBP3gJM1Cc1WsLm2Nz/88MOv f/1r/dr+iSXDFDPFme3z588//vgjYQri+h0fZVkWb4gzTZM+vrX2FStuilIf47AdIZFJOJspodf7 mJ/L5r961y1Z8u7khOwrY7+Ib0Vi+ZE7sY+UrPru8GvatlSJ3RjS8x6wW2lPSVjWo9uIdYDyww8/ 6BOUzpHoGczryAv9eqzmeJxlyPFRvNdsM7FZEuW4eZ7jPXOVUl9++aV5/enTp32ZG9MBxZ5i6lDp p17K9Sl3HrsdITQlcV3Ogt4Xygqq5Eo32fPvWDyyIUcWD0kfPEbu7cgnUqO2lfZAet8vGXnYU+y2 HhXu0TJoiuWHH35wpqTny01axQQrpFIQN2SMonyhyXBSAhSl1E8//aTvIdIByu7Vhc6Gx3/nyQuG 7DcamT/yZ6SclCkpVfWuJVSlzel2f9J9NTxL7p4p9Yn0w/sFMRMjLyIlyL638RKGoDMo9pSsp/nY qRRafLCp6xhFN/c43VDsnhnj0mGBnSOJOxigKNGmk9Kafg21e0Xs1metgBR2c4/pDOv8q+eUU8z0 MyqOwXQdo8TpVIpz5S7Y0JMeQOyTkkQxDlbGuSEo1O5zVX2GAn3WCogz0Yk90RuahN7VL8yU0X9w oqreYxQ7lWKO5lB0UnC93X5tdmxmaHwU87pEvQDcgrmdx0mlKKtjip1Qsaebd9tWGQPrPUbx8vaZ vcO1Vm9swfFR7rDTAJSizxuRVIozRb7wtvvQJQUhQ8Yoqn5okpKuaJxr+fTp09dff/3dd9/tWDY0 Poq0LP7pGAWfIKqys7AylWJ4kygy3dKmzhjXADGKGSjFvu22QQLg66+/lhO/++473Y/keG+V3BJ0 gLIvieLcYLx7vFoAUNFeKepjjxPnLXtmRZiCLQPEKMZAA59sWt6Ht0+Z2WRQdm9+ZHwUAMgST6XI cESJWMSZh4YehIwRo1zygpoYphwPUMzqis+Jfhy/h/xKIezo9e/B5hFl+qY40+1USmhZOYI24LU/ Rrlkji4rvdHM8QAly+trrcf1oZ63t7cjizs9lkbvT80xfFz8iDKd7mUoYxp6lO+OHnl2JYmCiJ0x ytDnrzjzrQv1TjX9SI7f7Zw4xmvjvX3waocLGP0LzjHcgH360jck23FJb7/0MKgx2noaa3mCHv1i gGtznjijJ5o/7V7YTsDNgX0H+lP+8ccfdyxL+gQpiFEA/EIO7heKSLyLp8yDi/nqq68iYQqxCI4g RgHwCydlAqQgEEEl/3R2BbKlnD1HP8OG6j/6dgEAkG5PHqXlo15kC3ftlZ6ydc66rrSNGE5uKEzo fFuJLYDAbtl5FH0gavrcNL+z5zEvnLd2kKvz/muvcfe67K1zSou8OMK7ad4dKzd2H+8neLBMjG55 H+UvdKWRMyxi/GJlHbROm1HZbw36IT9Q7ynLuSg0qRquoEx/FLtXnf2v8nW4K0WuTp4Z9xWrPuZs vJV31ljK/PH+CLsCNVZXqjRnhyfurhpHBXazPwvz2jsxMlsoIxiaoR+bxzC8nO91/MTIVx65qvSZ bRMm29+KGmUuW4OXFFmvHRKpkc+MKTV3Yr5xN/ZcnOgrueFerfTrMfSWOanecFdjnyp9ZvWP/hol t1+dU7L9lS6y3sb7ykHSdVB9fnBceEZ0/FhaxNA45keITKtwkCBLdh5FtkQo0T5SNlKWq/PWR38x Dn7fvJsW+qYN+oNAfoL1NsH5OOzGuEW00ylxRNmVhINsSgOhc13KlIE+nePHkv0Vjmz+cHsGp9vT 1iOPMGeKDJl3H5ShddnTQ6+Pr86pf+jd2qsr/hOkxjkiFN4573or4I1dvAvCRphSljyGvb9VEqeM 9ensq6333CsnFj+D4T4K9EfhsIM6dhhwCO3DfitL7s941wrvPCZMGevTGau2uA9/jNL4eGV1p6+O dMVwuKjUlpjP8+Z6x0qibFZ1oG3BxXhiFOdp2rWxuh5WxzloLHxep5NRiN3WM1CYklLJx+NRvR6A jydG0Yfsy8tL67p0gwe77yB7uS6BLsybp+/QgtCKX/lCl9usRXYX1S15HC6+/uahKUNsdWIlh9gW XJK/refl5eXO1+lxz6pnCe0uZ7rTdc7pTydnUDRC9ep6XxDvFnnbcXZMAbCPJ0a5eYCilHo8HoQp J+LG48YW3/0pZ1YIAJRSlcaZBY7gAtkPpyHDHgPDnqJ8qS/Z6OOdDgAhxCgAgmRyJdR+J2cI5WbI 0wBIRIwC4JfUiBNAbPYHSu8wRNciALmIUQD4bQ4QkjUiMLkTALl2PlOw859E8zzHa9h5/YH2Nu8J L4VvH4BE2XkUc35pPAZA1tkzMsDGWfUHhrM5UI13Bm/fWDmOyCyea0M/FQCOPc89VoGRmuRs6uMJ y7kXQJ62nHKcid5zn7d85105Agdnw7L29Ygs+CkcLEp2wpAH0h0OmM2hPsyf8sVmCblFNbZ5DKS8 BaCsPf1RZN+6UD+7UHO1XnzzSmD+DGWh483hod9nsv4ohb3aADsZpXAsoXNl+sw6KV/vQb/5E02W k1uHzSmo6krnu3j4e7or7Wqci2MJPdsTo5jchpyo7T7oQ/mYsrz1x0GhRJd+4SS0nFY/5WvsC02x 2+8iR4h31U7b374DLLRRSmxXZKOO49LSjPfj2/xVNhCOJXSrTB4l8RDP+ibELz/ecvimdSXSGmg4 M3gXCU2Jpzq8cYMTr8QXt2ebA82X8eMwslFFcMCX5T3nRD6+Sh/rKS6wCbikYuOjeH9VLIE2oDnQ B3b52It2nmf7shSf31u+mYFvYG1LuM/yQQezHUazA8DsioMJm5QV1Sj2tkJpkkofX1c4ltCnYv1R st5KnN+ZLb2oSCGoR4Ypx3d+PNtRdimHN+rat2yNg5ADu5nL7+rLbyDGtXMMN8BrCfR6nq27za+a 07Lbg9TW2CEHXXIH9u+SCRWOJfSMsfBRmN3SIZvnVCCjHmrRCwU9u9/KnSeylFND7wvvIgfVuKg4 u4LrlhH5+Mp+rKcYt+a4CWIUFBBqlYufARMb7yJNfumNjN6lQovH6xB5N1TyEFeCISpZT/phVrUJ D4CNGAWN2KkFAAA2EaOgEaKT4ci2jJQpN3G37QVOQYwCQKnAWADmrcU30Iuc0qqyAG6BGCXoVifc S96wgCzygI8cFTKPggu71ckQpwidSYhRgl5fX8+uQjtvb29nVwF9SRxjhqvXHdzqZIhTPJ/Px+Mh zyf+GOXl5aV6jTr28vLCdxKI8I4pTLwCwJb+65c8CoAMcvyYyNgwZsr88VlFitgFuLfElMfz+fRO J0ZBAfERwDavUlzGTrdvrBo5ZXOomG55A7LlwPMQAGhH+hIQo6AM+zye+NSe2XpgZMWaXQ5XzUpG HHnvII4ldK7u83omHzM9vuDBlR5ZVi4eml5KqZJr1xOd4G4alHLWsdTgTMWZ8AKqP1NwXdd1Xe0X +vXmUkfWuG/BaZrWdynTCypScoN6ZtGPD1TvJ0Hzr31OTJnBaFLrYbBDanP2sDwOL3NYnrIVpU56 tVeBc8XaevTHLz/m0HRJziMv/85Ec8x554yULMmi7NXJ13KR0HSnPrL80FakVFKWv1nO8Xoez/fa p7lQXwTZjzI+Q+Ltr7dFor6sWYxiZ78VGr/uGp9C4lbI80nonOn8qZJPhvL8HCrHZOVl+Snn1dD5 kMimNtkfP+LM/ij6d7/9QvmObGcG+W68cPu1Ez3Ir5NzdIamy/rY5cv5I4ps7/F6Hh8fJeUEtznP Bc71LbG7ytrs2e3MPL8/37tmpRpJDFDk+USfTOwTuPfELv+UQufn+HnMW2biedV7Psw6gSOXvCUw LhajhD6nUp9f1oU8Kx7PKnyfSNxwfNU7tnffWmoUizaucWkciPeepmskUdI3wXveC8Ulznlst1Ll bK6l9irg3EuREqZU749SymrpoSfU+lHV8nvYXnTlAtfFcdndp7Ky1n3KOpayznt2D7kjJ8lS5eBc KWMZSHX7o5SyI/m2uUjPF/6bJBs3f4Ze4AJQQ6UAJdIb40iZ1winlvD4dUNvYKnKr1udOXLPt6H5 I+VUOm3SSaWUeZ6947nFexoEY5SCAYrp2WSWsqc47zrdP51FtJTgYw10XLW/S6YNMrfPrMxt2POn d5gtsr3p9ZT7P72ecd4zndNz1jtiiv1WZAZFn9nKZJ/QM2tzhtCPPHkoRha5ttB5L2V+2edDT3fO e97zc6Sc0HneW/7m+VBej1DWjo6PLfqjyPmdoGGz8Kw12od74gw7tvR4PQuW06Cep/DeK4Ta2NUI OXKqiZz2vYskLpt1isuq5GZV0UAwRikVoAC7cbE8ndPA4U23yEYikl4AimAsfACe/hbO61ADUGTg EEWwAtxe6GGBiYhRACgVCEdCg4IQiADYdPzkMMy9xwAaM2OUxRvdFkujmgEYwbIs67qm/ytLIEYB kPFzJ3LHOAkVALaXl5e3t7f0f2UJtPUA8PdHSRmfJjJwiCEfbXPP25uBu8kKULxhCjEKCuCScwHx QW4iEzcHDpFDjHR4tMieN3IGmUPiyAcijudRqrf1TB+F3q1dDZylVP6fdgSDXVFJSsea0O3Wgyp7 LHE+hyM3jyJLqB6jmCcsyEct2E9hqF2NZkoN+QxEEKaglFLH0iXP5ziobh4lFBEfj5RNCYlxtz2b s4g3SSNnqFS+nJ6+UfH5I8mnlE3w1lNuQnr5iczj1uwTn3k9v7P/jCwVKgeKvdGKPGjtFykHcP+f 1MEaRs4zuLnjeZRz+qOYRzYkRtyr9ezvNfAccPtP+XyHGuXL2exlc7fLFlpvyCSehWSXLxeX5RdM Wct+kZEhSuUU2eovZ4ZGZ4iyZAvOHB0qxlk2cgBXqW5RR46l3PM57qPufT03HA7f+ZrF45s+90Pi 8ybq/daJnOkiJ2tvF8Ui9bkwApSyjuzP0T+LlPrLk0af50D040b39ZiUQ8toXeYb2qy3AWcf7ngc 5Q5Z5/HRT/q1sX9QSuKxRESCXKP2R2mpVFV3lJO7yIlVbSwrR0JCRSJAQSm1j6Wxrhcoq2J/FH1U ebtKeKfHy3EWdCYmFiiTKE5bjPetUJ+MUOH2nLJfi5lHvWdZ7NdykcSNcuaPbNdmIfb8ThfaUPmq 5nnKtM3Lwb42l7JnlkNT3FalnZD+6VyVHQ3bR52cc/NoDC3YmyKf9eb5nATMbQ3QH8U7c8FDNlKU fUlOLyry7fIWmNj/Y3O9jQsp29bjHZtLTnROiIlLybdQnLeTcny2iwltV/yglb255QE8RLByROQ8 Qwbl5ir2R+mtwyzHOtDGVaOQlmRK5rZIotzZjZ7Xw4EOtBe/HRch7CKN8/bN3ei+HgD1eHsLMUoN gCNulEcBUFUoNDmpOgCGRx4FQEVkTQDsNsBzjwH0bzNfQkIFQK4BnnsMoH+6P4pm3z3rTDTdVubA M/YAwBi1P0ruQHBXdZn9EH/cWmIJzlKJ948cvM2Eu1QM734IjVKzOfjNcI4fw1nrGn13ASmO90ep nkfxjmvS4VW59vgrtffDuePHLMtiLl1DnHyHHlOVjEUli8U7w/X2/PW2CF3p/Xk9Ziz29KImi5wt a9Xp5UTqmVLOZpVK7Ycd5cfr7101+selBaVwLKGe3vujmNHlNefdaZr0dPt6uVrMdPOUH2d6SG45 oXomlpPyPJ0i+yG3/Hj9ncWL0/0Y7NfevguheZxynEWc2bwzbE6R/3oX6fMk3metLibS7UYe0inH UvUa79JtxTC6AZ7Xk1t+5Hqctd7eyonI3Q9ZQuWs1jMXi6zIS+fM57RnwcSHDjOvzZTQi8gi9syh 7i/eRXZsewORnYkdzAcd2auRQ1pOibzVm24rhqFdcHyUqhf+E8s5a70ddv3J5YQIi/UgZTPl+FpG PEGPWOeeeTsI68NPvhWJXLNm7gTHEmqom0cJ/c7e/ftbNz3kLtVe7Xr2UL6Zp/8PJXTluPlZ9eab f7r0/d9/To5jCZVUvK+nVICi2xQ0s5Tp4+n8a8/s9Ov0/puy0sRyvPXcLCe9w2mR/ZBbfrz+RuIm 1JB1yrbb+xfr+TI3xEWlDZOxixxsox+HHEuoZ4z+KHJ+e0pK/83I/Okr3Sxnc5HcOmwulbsfcstP mahfew+OUhbxvDo7hS57I9onzfiyuatzpsS7HXR77al3Ubl5dsr+xL37wW5nTOm8Yi9Vpoql3fnj RgPH8yjTsizmjWVZHo9H55l/1BAJYzHKlfv4JzjKloZwDBfHRQEH5QYoTkDSXZ9ZoAebP6mvR97Q BABHXPC+HqAHXKeVL1CzW9mcxg5vVCcbROLtdACuZNTn9QDoij2Sh51KsWMLM4NKGyAkMlAN2Rrg DgZ4Xg8AaJv9nQFcCXkUAGW0ufekQZeXea5Y+K0sy3x2FTA2+qMAOEoGDZXCCPvGXVIpwOWRRwFQ UWgUEO8AIYnD0ijRqYV+KsAlkUdBeVwkRnSkpUZ+4rLPrPwzslTiFLmWE4+9dX21/5ym51k1UUqt 6+u5FQCKII+C8l5fX7dnQmcYu+w4Oyw4N0potmqCIVRFHgXlcbWDlpXVIP02KMIU1EMeBQBq0Q1A +hJuGoPMFd1uHpqmZ2Rm+8/QbM50PcWZLldaajMJU1ADeRQAKMN7+beDBjObCSCcBZ2l7AWdcjan O4tHVlpq2wlTUBx5FAAoo+BFulQA0SxuIEBBDeRRAKAv9bIdlRCgoJLjeRTGwgeA+yJAQT25eRRZ AnkUAP6nFsMwfVfV+0XdnhKZuV41ShVYsDTAQX8UdCF0hUscNpTRRXsgn2N8K96rtT1RzuA06ERm ln1p7Q6zoeneAsdqRcLN0R8FvfBe4W54qWvgnjFEb2rcA9znSoHdquRR/nea7D//ZV1rVR9XxBPj Gmizh51n6+iJm4/asZeSC17GKSECcQnGQh4FXfNetyJdHzYvhDCK7xNvMCH3f3y9zkeWviCA66E/ CgYgQ43QdYvrWZaye2nHzpeBiPlT5lEA3A15FAxAXrdCuJ5l6TOMk1FL8wrMjdcIwIvxUTAGfd2K z2PimD4vvb05dy/ZgYj92jTqyY+bABS4G8ZHQXdkS4EJPnLbJsyljqjFUWOHRDq32jFHfNXORyYX jHS2BXAx9EdBL1KucLKPgtMZxftTmwuYo8YO8Zbp7Sq0+a4zZ+jPExuDInYETLJTTr11AWOhPwq6 EDrVhq5Dm9ctYCzph67sOX4i4iRURX8UXNY8z5xA0ZLJiJxdkabutr1oif4oGE9i2EF0gtPJsXxC o/s4vYZVtGXTaR7ydtnxNo9W+lLwYwCV0B8FAArw3qakfMPGyCmykPj83uBGhTsUN+hfTJiCGuiP AgA9knmUHcuaPxNHGNqNAAU1kEcB8LPn89YPczner6JGzwwnTbK7nH23DqUXXqNYgDwKAKXo+Xjs QhtvtSlV5sGiKoUpBCiohzwKAKXECCWPx2O92RPLvSe441L6wBqLGLNO3igk+7tECnTmIUDBWMij oAvFf4bSgw8teaONzbfsP9Pn31zECTdDhQD9qzI+yr+sq/1f/a0AkIFmHQBDOD4+CmO4oQz7wslF tDb2cBspSREAIYwziwHM78yfZqI9xXntLOUtx/v6Ju62vQCGQx4FvTDd+pyuJMSrthIAABLsSURB VOaWBLtvoH2fQqRAZx7vlMTSLulu2wtgLNzXgwHIS+m+hHnokrzUH+GqT3fbXgBj4b4edCQ0fkOR S2l8LKzQqi/sVhsLYET0R8FINtsm9jVemKEj7tP2QYACoH889xh98SZRsoaokh1pzWAS8baeSPkX c5PNbMw+uo7v4btl9QAv+qOgC/H2nawhqpzhrSJriawC2MFuTBziiDpez1G2FIM63h+Fth4A+OBW 7Yb32VK0Rx4FAOry3utu3jIT7Xkiy5q35IJOk6V3vXIeWqbQLe7rAYCKvBFJ4jze16Epdrjj3Kfm vOUt7SDCFNRAHgUA6nJaQ0wAEb8fvvh6Vc1+VwQoqIE8CgDUlXL9rnGNbxY3EKCgEsZHAYDCIm06 +sUSHjOwTUKlIAIU1MP4KABQhrff65IzwE/Kspul5a73SJBBgIKq6I+CXiSeeY+vxS5fdiGMz698 HRLj86e8hQuIfLjet5yJoT/lsptzhpZ1op9I3YBOMD4KujD7Hm6cslSpCuSeqdPnbxN7ZWFACwBD oD8KutPPtfzCCFMGxbcDt3K8PwoxCmox11H9wvxrX1/teey35Iv0dTlFyZXmzu/U3zuDLKQ2whQA naM/CrqQ0r9PRUegsnsUxn9rRq7Ns2+8ikiflcT5Q0vNTQbJiNjcVwBwIsZHQS9Sgox4+OLMOQce Zez0mU2vWKLN+fsJC/qpCQBI5FFwBSemIsZFgAKgc9zXgy54AwudC9nXHjG/3yhEyOJFgAKgf+RR 0IVIf5T4sBNlY5HcclLmX7aGyWofSBGg1CBbG9MX5BMBvOiPgl5kdeOQXWVDkU084omUI7uz2B1g 0+cPLRgpBIPaF2o0DlDKhkQEWKiKPAo6Ferx2mClWsqqc+evVwhwFsIU1EMeBZ065axX/BaeZoWg T+b2cvX+QTv9u01ToDOPnsFeJDSDE81vLqsqRBWEKaiEPAoAlOHtUxUZX8cRCmK8L7zTs5YtizAF NZBHAYAyvBdp2QVKxhP7SvaSXZrahA4EKKiBPAoAXMcQjaRAIsZHAYCmcpMo+zS7R4wABfWQRwGA MorcorWkPbtq97JlIyQCFFRFfxR0Yff4V0AnNjujxF+H3o3PHHkRWSnfL4yCPAp6seO8ya0E+7Df AAyB/ijAHTGgLYD+Hc+jEKOglvmd+dNMtOdpX7FrYNcB6FxuHkWWQFsPyvCOj2neajka1X3Q6AOg Z/RHQS9SLpZcUMtifwLoGf1RgJsiQAHQOfqjAHdEgAKgf/RHQafaj0Z1H+yxGooM4AbARn8UdCHx YWzyNRcD9EP28va6UmB9pW1Bh+iPAgCF2VnAy7vPlqI9+qMAQF3OSD/Kuq7Lt0Y0ev3RLfqjAEBd sg1INlaO3mgyev3RJ/qjAEBdkTTDZTIQBCiogeceA0BFzojJiW+NhQAFldAfBQAKu1XDx322FO3R HwUAyvCO6CPv8THj+lzg9h8CFFRFfxR0QZ7Ejxd1md6IGELkGJNvMcAPkIL+KOjFjpO1DD68T0vm MuAgaAMwBPqj4LK4DEeM3sQA4A6O90chRkEtzvBW+kVoLKx4OXZpFxs+a7fbbjiAUdAfBb1w+pF4 W23kC/lMH2+/RfWxe0qo/Lu57YYDGAL9UdCLlItl1jzeC/BlRqQoggAFQM/Io+BGnKjl5lfom28+ gP7x3GNcSnzQ8dBV+YYJFQIUAP0jj4JORXqWOPOExsvyNvSYt1LKv6q7bW8D8Z499PsB9qE/Crrg PYOHOr2q6BBYoSkpcwLIQviFqhgfBQCOcka1d15f+yp+w6ZSNMPzegCgBftafrGo5fJxGM5CHgUA GlneXS/3cL0tQg8YZxYACjCRh04qyKECr+0mm4nGyKMAAA4hQEEl5FEAoAz7Znh5Y/xV3WEbcRbG RwGARq43JM9lNgR9YnwUdMHpcBd6zk7oh+nm4kAb8YctcGQCWcijoBfpzwv0Riqc/QHgYnheDwC0 QBgN5CKPgq45jTgmg5LSG1G2/adP4XICAKejPwp64Q0XZDDhzBNZ3CnHKS0+5SZ3ZABAz8ijoBcH Y4JI1BKZWYY+OjohQAGA05FHwTVFcjA2b99bkigA0APGmcUdyajFjFyuxDNsAQCn4LnH6IV8Kmwo VkhJdchl7SmyfGeK0yuFfirY5BwbJx4q8cGEgIHQHwVdCJ1MnemyP2xk8ZQxVOJT5Oo46WMUbY5V IiFUxfgoAID9aBhFPeRRAKAip6FQtmkqcee87BfltELKRZSIFez1OnMWRzYFlXBfDwCUkZhR2Byn R4nmRRnoxAuJrC5zm1IRpqAG8igAUIbTZzZ9wR3NJemLtGmLIUBBDeRRAOBkOy7wiYskDhR0EAEK KmF8FACoSDfEJDaFVE2oVEKAgnoYHwUAqvM2A4XG6UkpLVJIaM4aCFBQFf1RUB6nrXGd/qN8XClj 9oTe2hwHKGWons1CgOHQHwXlvb6+nl0F7OT9IYLdnBuGAWQhj4LyuM4B2ma2A0AE48wCAIAecV8P AADo0fH7eohRAABAeeRRAABAj8ijAACAHpFHAYACSg0twxA1gEEeBV2YP/LOoMKn78hpPbKIs8b4 KgBIfF9QFeOjoBcp40Y4z6lPL9a7SPrAoABCsr6PQBbGmQWAWuSDeFKmDIcwBZXQHwVdc1p/5As5 v1kqcRFn2dCqgVz6yq2ZI9OZopSSU0Y0dOXRLZ57jF54f1/K35rOPN5yvO07cpHI71dn1fxGRHGh Y3tQfEdQA/1R0ItS57jcrioh17hyoHORQHwgBCiohP4ogB+nXVR1mfzcNbYCfSKPAmy4zLUEtdmJ ENnpRP8bmTIivhqoijwKeuGc31X49K2nZ50ccxeR1xIgznucbN7xLqdwvAEGeRR0IXReDp2+U6ab QCe+SOL8AIDGjudRuPcYAACUx/goAACgRzyvBwAA9Ig8CgAA6BF5FAAA0CPyKAAAoEc8rwcACkh/ pJRcsOyN7v3UBDiI8VHQixpjpslx4Tbnb3COjqwl9Ja86ug5uah0xf4sTvxoFt8zNSvhCERVjDOL LtR4zrBTTkpkcHy9BysfubowGin6RJiCesijoDuc73AlMkEYShl6n4EspygrlvWWU6Qm6cUqwhRU Qx4FXXPOod50y+4ztfp4srabTrzrdU7cofN4esVksfay8c2RWaL4utCA99AKHWMqcDynLBVfNlS3 3JpkRR6EKaiBPAq6sASe4bd5Ft7XSCQXca73kfO1jGaclUbCqUj9Q5coe87IWzt2AooLHaKb88tP LbJU1jw7mMM760DiqEMN5FHQi9BPOmee0M/KZtVzanLw1Jy++GZa5Ug1UEnigRrPakSWKlHH7fqk zF+pJrg58ijo1+ln6rjc83hVnVQDWezj58jhVPY4NMF3YrEce6iHPAq6kNVMk9LuU1vuebyZ3upz c4vViCmnRJJzkaU2y9msyfLevhlqYJ2T+8xysKEq8ijogvd0Kc/LiQt6F7ff9Z6svesNnYJD53Hv ZSb3PL4j0757XSglcqjEpzjxweZSiZ/15nojNeEoQifIo6AX3tNiysTI+TT3shE6RydeRY7MkF6B lPlxMaFoG7g28igA0DviEtzT8TwKzxTEYDjdA8AQeO4xAADo0fHnHhOjAACA8sijAACAHh3Po9Bn Fj97Pp9nVwEAcB3c14MyGIsdNyfHWEtfkH7cgBfjo6CMdV3PrgJwMmecwDtEHjfZTJyF/igAgP3I oaIe+qMAQEVy6PrQYPbeh2jKKWZiaJ72iQ2yKaiE/igAUIZ3xHo7gHCexBR6vbmUd1kz5ZSIgTAF NdAfBQDK8F6kI00hoQAlvlRonsV6nuXmssURoKAG8igAUIu3+UaK51ciS8XLaYYABZXwvB4AOIfT NrS786lp/TlYzj4EKKiHPAoA1CIjBnuKc3W3G2siS4XKMVNaBg0EKKiK/igAUEDoau1tkQn9KXva yrdCIU6kDsCgyKMAQO+8dwwBl0ceBQB6R1yCe2KcWQAA0KPj48wSowAAgPLIowAAgB7xvB4A+Nnz +Ty7CgB+wX09AKAUz+8F+sN9PQCglFLrup5dBQAf0B8FAAD0iPt6AABAj8ijAACAHpFHAQAAPSKP AgAAekQeBQAA9Ig8CgAA6BF5FAAA0CPyKAAAoEfkUQAAQI/IowAAgB6RRwEAAD0ijwIAAHpEHgUA APSIPAoAAOgReRQAANAj8igAAKBH5FEAAECPyKMAAIAekUcBAAA9Io8CAAB6RB4FAAD0iDwKAADo EXkUAADQI/IoAACgR+RRAABAj8ijAACAHpFHAQAAPSKPAgAAekQeBQAA9Ig8CgAA6BF5FAAA0CPy KAAAoEfkUQAAQI/IowAAgB6RRwEAAD0ijwIAAHpEHgUAAPSIPAoAAOgReRQAANAj8igAAKBH5FEA AECPyKMAAIAekUcBAAA9Io8CAAB6RB4FAAD0iDwKAADoEXkUAADQI/IoAACgR+RRAABAj8ijAACA HpFHAQAAPSKPAgAAekQeBQAA9Ig8CgAA6JEOOxL/nedZlvBFu8oCAIA78bbgSM/n0zudGAUAANTi bcRJRFsPAADoETEKAADoETEKAADoEf1RAABAXcuyyInee3ls5FEAAEBdMhx5fX3dvOuHGAUAAFRn hymvr68q4ZYfYhQAANCCDlMSAxRFjAIAAJrRYUrioCnEKAAAoJ30Ud2IUQAAQI+IUQAAQI8YHwUA AFQRelhgImIUAABQ3uYQbZs8McqRRxQCAACowNiyId6Axp9H2Rz6DQAAoIhQk1CwrYdsCgAAOBH3 9QAAgB4RowAAgB4RowAAgB7F7j12OtlmddDtwTz/Q79Yln/1vjaW5V+b1izTPP+j5xrq/RmpYef1 t83zbI7z//vNb/SLX33/vXfm//vNb0JvHWRWHa9A547vH/vjaEyf/eTac6cDOCKWR9Hft+Xd8Rud G9PXxci/+r9T67hhnv+hIwDzotl602eORyen1L8IfX2NXGXrhQ6/+v57s/aUtTgxTTPx9Q4aWmmh aCN3OoAjdo7hZscr5stpJtoBzblfXZ01Mf867+qJerpJBpg57UXs66tdjpOe8c7vXSQxNpI1iZfv rY+9aaH55UQ5c2R7Q5sWqn+f0n+1h1Is3vyHnvir7783L/ZVL1SO/tNbJbs+zvymHPlWpBy9lL1d 8fVG9k+oPvYi+kxyyjlEr/fERA4AtS9Gcb635k/7K93P1zsSoMjZTECjwvHNZhAj5z9Sf1mHUPmR oMpsmixZ/hkP6UIb5d0t3vpfgH2RNpymDee6bl/a94UpoXLsuCFeH3t+uUhofnu6E2SEtiVx/3jr U68FDcBwtmMUmRHZbPdxohOZEPaewopPj4t3THGSAZtxRmR+59p8/FIdLz800Ttld/yUUv7d2JkJ JQ7CUtfdrHIibTGyHKf+x9eeJb1kefLRZ5tS00upXU+mM/1K00O2YxRZrsyjxEsInX1qT9civ+MT L6s78iLe/MQ+dh+asuWXzfeEeOs/opTf9948wYlyA5pQO1FXQme0UtONzTNbXO16Mp3pV5oeknrv 8RLInRz8GtfmtF+E5skqcPOteIHHe48mLl58u46UfwedXNSLVCNSSOitTja/CP0zTOv8FAdc27Qs y8vLix75flmWx+NhpshWHpNBsd+aP950N3fT1yzr3mM5g+x26ryrPl6nUzrMmneP5BU2O+Sm1ye0 Xc5bieV7u+UOZE5ro5RvedscN/uuRsTLj3d3jeRC0uvp9GCN1D99vaFy4tvV/kwiT24qkKa2T3re 6QASOeGHmRKLUc6uM9BapStiD+0+I+rhpw6ABkIxCuPMAnU59+gCABLtHB8FuKQav9rJoOxGEgW4 OfIoAACgR/48yvP5bFwPAAAAmydG4V47AABwOk+Msq5r+3oAAIA7kzcU0x8FAAD0iBgFAAD0iBgF AAD0yB+jTO8KrslbYNlVtOetf/FdBwDADfljFN1ttmznWW9po/fPveRGAQDQg+xxZu0MgX0x3pzu XLm90/XEdV3NC+/88t1IPfX8ZmZZT3ulZop8K3G7NuuTvggAAHeWF6PYF3v18Vq+Od1p/rCDAHui biiRsYJTzmaA4l2vt572Sp14JVSfUP1T6iP/BAAAUpnn9Zir+8F5zJxFykkpTc4m5y8ST9BDBQCA LEkxyubvfpknOFqvyyFxAgBAlvL3HocClFKBy45yOo+ZQvcB5U4HAOBK/HkUfQmUF0KnncVuH3H6 qNr9OeR0u3C7f4lZr1kwVE58q1Lq6V2p8iWNIt17legf450u60xaBQCAOH+MErmCht6yp+e+Tpkh 96KeUs/ISrOqemR62aIAALiMMn1mGzjl3l0nxQIAAJoZJkY5JUogNAEA4Cw8rwcAAPTIzaMsy/L2 9nZKVQAAAIwPMcrr6+tZ9QAAALB9iFHIoAAAgE7QHwUAAPToC6XU8/k8uxoAAAAAAADd+381AQsN M2xF7gAAAABJRU5ErkJggg== ------=_NextPart_000_028A_01C0D25A.E0448390-- From youngs@xemacs.org Tue May 1 17:28:00 2001 Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [203.2.75.228]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA26207 for ; Tue, 1 May 2001 17:27:58 -0400 Received: from slackware.mynet.pc (wdcax13-087.dialup.optusnet.com.au [198.142.220.87]) by mail004.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f41LRih16155 for ; Wed, 2 May 2001 07:27:44 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.11.1/8.11.1) id f41LPoO14377; Wed, 2 May 2001 07:25:50 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: diff-mode for vc-backend-diff References: <15083.13622.630000.527100@muniversal.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 02 May 2001 07:25:49 +1000 In-Reply-To: <15083.13622.630000.527100@muniversal.com> (Jeff Mincy's message of "Sat, 28 Apr 2001 17:25:10 -0400") Message-ID: Lines: 30 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "JM" == Jeff Mincy writes: JM> In prog-modes/diff-mode.el [...] JM> The above breaks when the default-major-mode is something other JM> than fundamental-mode. As when: JM> (setq default-major-mode 'text-mode) JM> Please consider changing this to: JM> ... JM> (if (or (eq major-mode default-major-mode) JM> (memq major-mode '(fundamental-mode diff-mode))) JM> (diff-mode)) Jeff, please submit a patch to diff -u oldfile newfile > patchfile.diff And please include a ChangeLog entry. Thanks. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Tue May 1 17:38:02 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA26912 for ; Tue, 1 May 2001 17:38:01 -0400 Received: from slackware.mynet.pc (wdcax13-087.dialup.optusnet.com.au [198.142.220.87]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f41Lbp808375 for ; Wed, 2 May 2001 07:37:52 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.11.1/8.11.1) id f41LbTK14483; Wed, 2 May 2001 07:37:29 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: New/Updated Packages in Pre-Releases - April 30 References: <15085.31904.200000.621067@muniversal.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 02 May 2001 07:37:28 +1000 In-Reply-To: <15085.31904.200000.621067@muniversal.com> (Jeff Mincy's message of "Mon, 30 Apr 2001 10:54:24 -0400") Message-ID: Lines: 24 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "JM" == Jeff Mincy writes: JM> A have a fair amount of trouble downloading the prereleases. Is it just the packages in 'Pre-Releases' or do you have the same trouble with any package? JM> I don't have a Pre-Releases in 21.1 It's in XEmacs 21.1.14 JM> I assume this is the right way to add prereleases: JM> (add-to-list JM> 'package-get-download-sites JM> '("Pre-Releases" "ftp.xemacs.org" "/pub/xemacs/beta/experimental/packages")) Works for me. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From jmincy@muniversal.com Tue May 1 18:14:20 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA28954; Tue, 1 May 2001 18:14:11 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=DELL) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14uiPK-0005VZ-00 ; Tue, 01 May 2001 18:14:10 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.13778.510000.124310@muniversal.com> Date: Tue, 1 May 2001 18:16:50 -0400 To: Steve Youngs Cc: XEmacs Beta Subject: Re: New/Updated Packages in Pre-Releases - April 30 In-Reply-To: References: <15085.31904.200000.621067@muniversal.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Steve Youngs writes: |--==> "JM" == Jeff Mincy writes: JM> A have a fair amount of trouble downloading the prereleases. Is it just the packages in 'Pre-Releases' or do you have the same trouble with any package? Pre-releases are only available from xemacs.org I have trouble downloading packages in general from ftp.xemacs.org. I'm likely to get some sort of ftp error (200 people limit?) from xemacs.org. It appears that when an ftp error occurs the package downloader hangs until I do ^G, then I have to answer some y-or-n question about the *ftp* process, and then a warning that the ftp can't be killed. I suspect that the problem is that ms windows doesn't support kill and efs is trying to kill the ftp. Downloading multiple packages at once increase the odds that this problem occurs. I was eventually able to download the pre release packages singly. Note that the package downloader did not work at all until I made the following change: (setq efs-tmp-name-template "c:/TEMP/efs") ;; was "C:\\windows\\TEMP/efs" efs was passing c:\windows\TEMP/efsxxxx to ftp which then complained about c:windowsTEMP/efsxxxx not existing. JM> I don't have a Pre-Releases in 21.1 It's in XEmacs 21.1.14 Ok. I'm on 21.1.13. -jeff From Adrian.Aichner@t-online.de Tue May 1 18:23:19 2001 Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA29412; Tue, 1 May 2001 18:23:17 -0400 Received: from fwd07.sul.t-online.com by mailout00.sul.t-online.com with smtp id 14uiXu-0007KW-05; Wed, 02 May 2001 00:23:02 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.198]) by fwd07.sul.t-online.com with esmtp id 14uiXs-13srWCC; Wed, 2 May 2001 00:23:00 +0200 To: Jeff Mincy Cc: Steve Youngs , XEmacs Beta Subject: Re: New/Updated Packages in Pre-Releases - April 30 References: <15085.31904.200000.621067@muniversal.com> <15087.13778.510000.124310@muniversal.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Jeff" == Jeff Mincy writes: Jeff> Steve Youngs writes: Jeff> |--==> "JM" == Jeff Mincy writes: JM> A have a fair amount of trouble downloading the prereleases. Jeff> Is it just the packages in 'Pre-Releases' or do you have the same Jeff> trouble with any package? Jeff> Pre-releases are only available from xemacs.org Jeff> I have trouble downloading packages in general from ftp.xemacs.org. Jeff> I'm likely to get some sort of ftp error (200 people limit?) See http://www.xemacs.org/About/XEmacsServices.html#1 Jeff> from xemacs.org. It appears that when an ftp error occurs the Jeff> package downloader hangs until I do ^G, then I have to answer Jeff> some y-or-n question about the *ftp* process, and then a warning Jeff> that the ftp can't be killed. Jeff> I suspect that the problem is that ms windows doesn't support kill Jeff> and efs is trying to kill the ftp. Jeff> Downloading multiple packages at once increase the odds that Jeff> this problem occurs. I was eventually able to download the pre Jeff> release packages singly. Do you have Gnus fetching mail periodically? I found this to be interfering with package downloads, but haven't diagnosed it beyond circumstantial evidence. Adrian Jeff> Note that the package downloader did not work at all until Jeff> I made the following change: Jeff> (setq efs-tmp-name-template "c:/TEMP/efs") ;; was "C:\\windows\\TEMP/efs" Jeff> efs was passing c:\windows\TEMP/efsxxxx to ftp which then complained Jeff> about c:windowsTEMP/efsxxxx not existing. JM> I don't have a Pre-Releases in 21.1 Jeff> It's in XEmacs 21.1.14 Jeff> Ok. I'm on 21.1.13. Jeff> -jeff -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From steve@turnbull.sk.tsukuba.ac.jp Tue May 1 23:31:54 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA12988 for ; Tue, 1 May 2001 23:31:53 -0400 Received: by localhost id m14unHI-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 2 May 2001 12:26:12 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.32340.17714.266874@turnbull.sk.tsukuba.ac.jp> Date: Wed, 2 May 2001 12:26:12 +0900 To: Jeff Mincy Cc: xemacs-beta@xemacs.org Subject: tar-mode on auto-mode-alist In-Reply-To: <15086.50487.690000.951139@muniversal.com> References: <15086.50487.690000.951139@muniversal.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Jeff" == Jeff Mincy writes: Jeff> lisp/files.el (defvar auto-mode-alist '(... ("\\.tar\\'" . tar-mode) I suspect this should go away, since tar-mode should do its own update via auto-autoloads. In fact, maybe lisp/files.el should do (defvar auto-mode-alist nil ...) Jeff> Perhaps this should be replaced with one pattern that Jeff> matches .tar, .taz, and .tgz? The last two cannot work without jka-compr, which some people do not have in their environment because it can't be made buffer-local. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From jmincy@muniversal.com Tue May 1 23:52:00 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA13956; Tue, 1 May 2001 23:51:55 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=DELL) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14ung2-0007Nz-00 ; Tue, 01 May 2001 23:51:46 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.34011.800000.176645@muniversal.com> Date: Tue, 1 May 2001 23:54:03 -0400 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Steve Youngs , XEmacs Beta Subject: Re: New/Updated Packages in Pre-Releases - April 30 In-Reply-To: References: <15085.31904.200000.621067@muniversal.com> <15087.13778.510000.124310@muniversal.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Adrian Aichner writes: >>>>> "Jeff" == Jeff Mincy writes: Jeff> Steve Youngs writes: Jeff> |--==> "JM" == Jeff Mincy writes: JM> A have a fair amount of trouble downloading the prereleases. Jeff> Is it just the packages in 'Pre-Releases' or do you have the same Jeff> trouble with any package? Jeff> Pre-releases are only available from xemacs.org Jeff> I have trouble downloading packages in general from ftp.xemacs.org. Jeff> I'm likely to get some sort of ftp error (200 people limit?) See http://www.xemacs.org/About/XEmacsServices.html#1 I wasn't so much complaining about ftp.xemacs.org, just that using xemacs.org seems to be a reliable way to cause problems. Ummm, ok you got me, I wish ftp.xemacs.org was bigger.... Jeff> from xemacs.org. It appears that when an ftp error occurs the Jeff> package downloader hangs until I do ^G, then I have to answer Jeff> some y-or-n question about the *ftp* process, and then a warning Jeff> that the ftp can't be killed. Jeff> I suspect that the problem is that ms windows doesn't support kill Jeff> and efs is trying to kill the ftp. Jeff> Downloading multiple packages at once increase the odds that Jeff> this problem occurs. I was eventually able to download the pre Jeff> release packages singly. Do you have Gnus fetching mail periodically? Umm, not that I know of. I wasn't reading gnus at the time. I'm pretty sure that I hadn't started up a gnus. But you never know.. I haven't done much of anything to gnus, other than setting gnus-select-method. I found this to be interfering with package downloads, but haven't diagnosed it beyond circumstantial evidence. Jeff> Note that the package downloader did not work at all until Jeff> I made the following change: Jeff> (setq efs-tmp-name-template "c:/TEMP/efs") ;; was "C:\\windows\\TEMP/efs" Jeff> efs was passing c:\windows\TEMP/efsxxxx to ftp which then complained Jeff> about c:windowsTEMP/efsxxxx not existing. I just realized that the '/' came from me changing directory-sep-char. If I hadn't done that then the package download would have created c:windowsTEMPefsxxxx and would have probably 'worked', if only by accident. -jeff From jmincy@muniversal.com Wed May 2 00:03:26 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA14678 for ; Wed, 2 May 2001 00:03:26 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=DELL) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14unrB-0000h4-00 ; Wed, 02 May 2001 00:03:17 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.34705.130000.767532@muniversal.com> Date: Wed, 2 May 2001 00:05:37 -0400 To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: tar-mode on auto-mode-alist In-Reply-To: <15087.32340.17714.266874@turnbull.sk.tsukuba.ac.jp> References: <15086.50487.690000.951139@muniversal.com> <15087.32340.17714.266874@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Stephen J. Turnbull writes: >>>>> "Jeff" == Jeff Mincy writes: Jeff> lisp/files.el (defvar auto-mode-alist '(... ("\\.tar\\'" . tar-mode) I suspect this should go away, since tar-mode should do its own update via auto-autoloads. In fact, maybe lisp/files.el should do (defvar auto-mode-alist nil ...) You mean let each autoload file do whatever modifications to auto-mode-alist are necessary??? Sounds good. Jeff> Perhaps this should be replaced with one pattern that Jeff> matches .tar, .taz, and .tgz? The last two cannot work without jka-compr, which some people do not have in their environment because it can't be made buffer-local. I'm not entirely sure what you mean by "can't be made buffer-local"? But, yes, jka is required for tgz. So maybe one pattern ("\\.tar\\'" . tar-mode) and one pattern loaded by jka ("\\.t[ag]z\\'" . tar-mode) The main complaint was that .taz wasn't in auto-mode-alist, when .tgz was. And, I dislike the duplication of .tar. -jeff From steve@turnbull.sk.tsukuba.ac.jp Wed May 2 00:09:57 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA14978; Wed, 2 May 2001 00:09:55 -0400 Received: by localhost id m14uns7-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 2 May 2001 13:04:15 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.34622.799923.658634@turnbull.sk.tsukuba.ac.jp> Date: Wed, 2 May 2001 13:04:14 +0900 To: "James N. Potts" Cc: "XEmacs NT List" , Subject: 21.4 hang during custom menu activation In-Reply-To: <028d01c0d284$c9c43910$6501a8c0@mondas> References: <028d01c0d284$c9c43910$6501a8c0@mondas> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "James" == James N Potts writes: James> When I attempt to traverse through the customize menu James> hierarchy, my xemacs process hangs completely. It's win-specific, everybody sees it, if it's what others are seeing there is a fix which has been applied to 21.4.2, to be released very soon (a day or two). The patch is the event-msw.c hunks in http://list-archive.xemacs.org/xemacs-patches/200104/msg00095.html if you're in a hurry, or just curious about what fixed it. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Wed May 2 00:32:20 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA16819 for ; Wed, 2 May 2001 00:32:19 -0400 Received: by localhost id m14uoDk-00014dC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 2 May 2001 13:26:36 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.35962.277806.110621@turnbull.sk.tsukuba.ac.jp> Date: Wed, 2 May 2001 13:26:34 +0900 To: Jeff Mincy Cc: xemacs-beta@xemacs.org Subject: tar-mode on auto-mode-alist In-Reply-To: <15087.34705.130000.767532@muniversal.com> References: <15086.50487.690000.951139@muniversal.com> <15087.32340.17714.266874@turnbull.sk.tsukuba.ac.jp> <15087.34705.130000.767532@muniversal.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Jeff" == Jeff Mincy writes: Jeff> But, yes, jka is required for tgz. So maybe one pattern Jeff> ("\\.tar\\'" . tar-mode) and one pattern loaded by jka Jeff> ("\\.t[ag]z\\'" . tar-mode) Jeff> The main complaint was that .taz wasn't in auto-mode-alist, Jeff> when .tgz was. Submit a patch against jka-compr.el to xemacs-patches@xemacs.org. In the fullness of time it will be reviewed, applied, and appear on a mirror near you. Typically 2-3 weeks depending on Steve Youngs' schedule, a little longer to find its way into the SUMO. Jeff> And, I dislike the duplication of .tar. This will not get fixed in 21.4, it's nothing like a critical bug. But you could submit a patch against 21.5 for testing. And you can fix it locally if you're using CVS, CVS will preserve your mods. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From ben@666.com Wed May 2 05:50:33 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id FAA30631 for ; Wed, 2 May 2001 05:50:31 -0400 Received: (qmail 275 invoked by alias); 2 May 2001 09:50:30 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 215 invoked by uid 0); 2 May 2001 09:50:29 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 2 May 2001 09:50:29 -0000 Message-ID: <3AEFD8B6.419E1406@666.com> Date: Wed, 02 May 2001 02:51:50 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Aichner CC: XEmacs Beta List Subject: Re: mouse-track-insert bug (windows native) now also in 21.4.1, 21.5-b0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian Aichner wrote: > > See the thread starting at > http://list-archive.xemacs.org/xemacs-beta/200006/msg00136.html > > I was looking forward to 21.4 for a long time because this problem was > fixed there. are you sure? > > Now, alas, the problem is also in 21.4.1 and 21.5-b0. > > Can we try to fix this now? > > I will need some help with this. > > Ben, one suspect is this: > > > From: Ben Wing > > Subject: [PATCH] misc changes, some for 21.4 > > To: xemacs-patches@xemacs.org > > Date: Sat, 28 Apr 2001 03:50:28 -0400 > > Message-Id: <200104280750.DAA29568@gwyn.tux.org> > > I'm running out of time for today. > > Perhaps you can have a look at this. I sure miss C-double-click > between buffers! > > C-button1 at that spot runs the command mouse-track-insert > > Best regards, > > Adrian > > -- > Adrian Aichner > mailto:adrian@xemacs.org > http://www.xemacs.org/ -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From jmadams@stsci.edu Wed May 2 11:27:00 2001 Received: from stsci.edu (tnm.stsci.edu [130.167.1.235]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id LAA15241 for ; Wed, 2 May 2001 11:26:56 -0400 Received: by stsci.edu (SMI-8.6/SMI-SVR4-DNI-8.0) id LAA29210; Wed, 2 May 2001 11:26:08 -0400 Received: from cerberus.sogs.stsci.edu(130.167.174.45) by tnm.stsci.edu via smtp-stsci (V2.1) id xma029175; Wed, 2 May 01 11:25:33 -0400 Received: from anarky by cerberus (8.9.3+Sun/SMI-SVR4) id LAA26195; Wed, 2 May 2001 11:25:25 -0400 (EDT) Received: by anarky (8.9.3+Sun/SMI-SVR4) id LAA14546; Wed, 2 May 2001 11:25:26 -0400 (EDT) Sender: jmadams@stsci.edu To: Marco Walther Cc: Andy Piper , xemacs-beta@xemacs.org Subject: Re: Agony, persistent solaris8 hang of doom: Can I help debug this? References: <4.3.2.7.2.20010426120851.00da2f00@san-francisco.beasys.com> <15080.39329.572999.938761@jena.eng.sun.com> From: jmadams@stsci.edu (John M. Adams) Date: 02 May 2001 11:25:26 -0400 In-Reply-To: Marco Walther's message of "Thu, 26 Apr 2001 14:56:49 -0700" Message-ID: Lines: 16 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Marco Walther writes: > Hi John, > > the first question I have: Where did you get the /opt/X11R5/lib/* > stuff from?? > > On Solaris the X11 lives in > /usr/openwin/[include|lib|...] > and for Solaris8 this would be X11R6 I believe. For some reason, our admins have a bunch of symlinks in /opt/X11R5/lib pointing to stuff in /usr/openwin/... -- John M. Adams From jmadams@stsci.edu Wed May 2 11:50:51 2001 Received: from stsci.edu (tnm.stsci.edu [130.167.1.235]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id LAA16559; Wed, 2 May 2001 11:50:50 -0400 Received: by stsci.edu (SMI-8.6/SMI-SVR4-DNI-8.0) id LAA00021; Wed, 2 May 2001 11:50:29 -0400 Received: from cerberus.sogs.stsci.edu(130.167.174.45) by tnm.stsci.edu via smtp-stsci (V2.1) id xma000009; Wed, 2 May 01 11:50:22 -0400 Received: from anarky by cerberus (8.9.3+Sun/SMI-SVR4) id LAA26401; Wed, 2 May 2001 11:50:16 -0400 (EDT) Received: by anarky (8.9.3+Sun/SMI-SVR4) id LAA14609; Wed, 2 May 2001 11:50:16 -0400 (EDT) Sender: jmadams@stsci.edu To: Ben Wing Cc: Gunnar Evermann , Andy Piper , gunnar@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Agony, persistent solaris8 hang of doom: Can I help debug this? References: <4.3.2.7.2.20010426120851.00da2f00@san-francisco.beasys.com> <4.3.2.7.2.20010426132425.00e9eee0@san-francisco.beasys.com> <3AE8CCDD.E704A3C7@666.com> From: jmadams@stsci.edu (John M. Adams) Date: 02 May 2001 11:50:15 -0400 In-Reply-To: Ben Wing's message of "Thu, 26 Apr 2001 18:35:25 -0700" Message-ID: Lines: 56 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > John -- if you're interested in doing a bit of coding to fix your problem, > here's what i wrote to Gunnar about rewriting the quit handling. this should > probably fix your problem along with it. > > > -- drain_X_queue[] has a bug in it. it should read: > > > while (XEventsQueued (display, QueuedAfterReading)) > XtAppProcessEvent (Xt_app_con, XtIMXEvent); > > NOT: > > while (XtAppPending (Xt_app_con) & XtIMXEvent) > XtAppProcessEvent (Xt_app_con, XtIMXEvent); What I ended up trying, and I do not know whether it is the right idea or completely wrong, is this. Please forgive me if this is stupid, as I am new to the sources and have a limited amount of time to work on this. However, I will keep at it. This code didn't fix anything. Index: event-Xt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v retrieving revision 1.41.2.42 diff -u -w -b -r1.41.2.42 event-Xt.c --- event-Xt.c 2001/03/02 11:42:08 1.41.2.42 +++ event-Xt.c 2001/05/02 15:22:37 @@ -2903,8 +2903,24 @@ static void drain_X_queue (void) { + Lisp_Object devcons, concons; + CONSOLE_LOOP (concons) + { + struct console *con = XCONSOLE (XCAR (concons)); + if (!con->input_enabled) + continue; + + CONSOLE_DEVICE_LOOP (devcons, con) + { + Display* display = DEVICE_X_DISPLAY (XDEVICE (XCAR (devcons))); + while (XEventsQueued (display, QueuedAfterReading)) + XtAppProcessEvent (Xt_app_con, XtIMXEvent); + } + } + /* while (XtAppPending (Xt_app_con) & XtIMXEvent) XtAppProcessEvent (Xt_app_con, XtIMXEvent); + */ } -- John M. Adams From andyp@bea.com Wed May 2 13:33:01 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA23977; Wed, 2 May 2001 13:32:56 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA13118; Wed, 2 May 2001 10:31:51 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001292wss.beasys.com [192.168.6.123]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id KAA11134; Wed, 2 May 2001 10:32:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20010502102837.00b204d0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 May 2001 10:29:45 -0700 To: jmadams@stsci.edu (John M. Adams), Ben Wing From: Andy Piper Subject: Re: Agony, persistent solaris8 hang of doom: Can I help debug this? Cc: Gunnar Evermann , gunnar@xemacs.org, xemacs-beta@xemacs.org In-Reply-To: References: <4.3.2.7.2.20010426120851.00da2f00@san-francisco.beasys.com> <4.3.2.7.2.20010426132425.00e9eee0@san-francisco.beasys.com> <3AE8CCDD.E704A3C7@666.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:50 AM 5/2/01 -0400, John M. Adams wrote: >+ CONSOLE_DEVICE_LOOP (devcons, con) >+ { >+ Display* display = DEVICE_X_DISPLAY (XDEVICE (XCAR (devcons))); Just FYI you should check that the device is actually an X device before narrowing to it - it could be a tty device FI. andy From ben@666.com Wed May 2 19:29:19 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA24895 for ; Wed, 2 May 2001 19:28:34 -0400 Received: (qmail 43858 invoked by alias); 2 May 2001 23:28:33 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 43819 invoked by uid 0); 2 May 2001 23:28:32 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 2 May 2001 23:28:32 -0000 Message-ID: <3AF09871.70F5DA19@666.com> Date: Wed, 02 May 2001 16:29:53 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "John M. Adams" CC: Gunnar Evermann , Andy Piper , gunnar@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Agony, persistent solaris8 hang of doom: Can I help debug this? References: <4.3.2.7.2.20010426120851.00da2f00@san-francisco.beasys.com> <4.3.2.7.2.20010426132425.00e9eee0@san-francisco.beasys.com> <3AE8CCDD.E704A3C7@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this is fine, given andy's request. but you certainly won't see any fix until you change emacs_Xt_quit_p. "John M. Adams" wrote: > > Ben Wing writes: > > > John -- if you're interested in doing a bit of coding to fix your problem, > > here's what i wrote to Gunnar about rewriting the quit handling. this should > > probably fix your problem along with it. > > > > > > -- drain_X_queue[] has a bug in it. it should read: > > > > > > while (XEventsQueued (display, QueuedAfterReading)) > > XtAppProcessEvent (Xt_app_con, XtIMXEvent); > > > > NOT: > > > > while (XtAppPending (Xt_app_con) & XtIMXEvent) > > XtAppProcessEvent (Xt_app_con, XtIMXEvent); > > What I ended up trying, and I do not know whether it is the right idea > or completely wrong, is this. Please forgive me if this is stupid, as > I am new to the sources and have a limited amount of time to work on > this. However, I will keep at it. This code didn't fix anything. > > Index: event-Xt.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v > retrieving revision 1.41.2.42 > diff -u -w -b -r1.41.2.42 event-Xt.c > --- event-Xt.c 2001/03/02 11:42:08 1.41.2.42 > +++ event-Xt.c 2001/05/02 15:22:37 > @@ -2903,8 +2903,24 @@ > static void > drain_X_queue (void) > { > + Lisp_Object devcons, concons; > + CONSOLE_LOOP (concons) > + { > + struct console *con = XCONSOLE (XCAR (concons)); > + if (!con->input_enabled) > + continue; > + > + CONSOLE_DEVICE_LOOP (devcons, con) > + { > + Display* display = DEVICE_X_DISPLAY (XDEVICE (XCAR (devcons))); > + while (XEventsQueued (display, QueuedAfterReading)) > + XtAppProcessEvent (Xt_app_con, XtIMXEvent); > + } > + } > + /* > while (XtAppPending (Xt_app_con) & XtIMXEvent) > XtAppProcessEvent (Xt_app_con, XtIMXEvent); > + */ > } > > -- > John M. Adams -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Wed May 2 19:37:02 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA25438 for ; Wed, 2 May 2001 19:36:59 -0400 Received: (qmail 67407 invoked by alias); 2 May 2001 23:36:54 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 67378 invoked by uid 0); 2 May 2001 23:36:53 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 2 May 2001 23:36:53 -0000 Message-ID: <3AF09A66.8020D811@666.com> Date: Wed, 02 May 2001 16:38:14 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: XEmacs Beta List Subject: Re: [bug] kill-line broken in macros References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ok. i hereby withdraw my change, and the associated news file entry: ** The variable `kill-whole-line' now only takes effect interactively. (This variable controls the behavior of `kill-line'.) Although this is a departure from a previous behavior in the case of setting this variable `kill-whole-line' to t, it is almost certainly what has always been intended, and most likely the old way of doing things introduced bugs. after my previous kill-line change was withdrawn, there's no point to this one either. Hrvoje Niksic wrote: > > Ben, I believe one of your changes to kill-line broke its execution in > macros. > > For some time now I've been witnessing a strange discrepancy in the > behavior of keyboard macros during recording and execution. Finally > I've narrowed it down to `kill-line' misbehaving. The problem is that > the variable `kill-whole-line' is not respected when `kill-line' is > executed as part of a keyboard macro. > > TO REPEAT: > > Start `xemacs -vanilla', set `kill-whole-line' to t. See that > kill-line at BOL kills the entire line. Now record a macro solely > consisting of C-k: > > C-x ( C-k C-x ) > > Try executing it with `C-x e' and you'll see that it no longer kills > the whole line, but only the part up to the newline, as if > kill-whole-line were set to nil. > > I haven't had the time to investigate this properly, but I suspect the > problem is in this change: > > If called interactively, may kill the entire line when given no > ^^^^^^^^^^^^^^^^^^^^^^^ > argument at the beginning of a line; see `kill-whole-line'. > > Apparently functions bound to keys executed in keyboard macros get > call non-interactively[1]. In the case of kill-line, it makes a big > difference, thus causing the macro weirdness. > > I'm working around the problem by redefining kill-line in my .emacs, > but a real fix would be to make macro execution execute commands with > `call-interactively', as God intended. (But this may cause other side > effects.) > > [1] > This is easy to test by creating a dummy command that prints a message > if (interactive-p) and binding it to a key. And indeed, I confirmed > that such a command prints its message on a key press, but not when > invoked as part of macro execution! -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From karlheg@hegbloom.net Thu May 3 00:49:09 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA15296 for ; Thu, 3 May 2001 00:49:08 -0400 Received: from karl.hegbloom.net (localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f434n78l008450 for ; Wed, 2 May 2001 21:49:07 -0700 Received: (from karlheg@localhost) by karl.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f434n6Uj008447; Wed, 2 May 2001 21:49:06 -0700 X-Authentication-Warning: karl.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.member.dsl-only.net To: XEmacs Beta Subject: [bug] Multiple frame multiple server, cursor position after `switch-to-other-buffer' X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii `switch-to-other-buffer', or perhaps something lower down (?) will, when you have frames open on multiple displays, get confused as to which cursor position to use when you flip back to the other buffer. I've got an XEmacs (recent CVS, X build, since GTK doesn't work with multiple X displays) that's running on the machine I develop on at work. It's got frames on my home workstation's X server, my workstation at work's, and on a third machine (my progeny sidekick) at work. On sidekick, I've got an Apache error log tail -f going, and on my workstation I edit code. When I left home this morning, one file I'm working in was left showing with the cursor somewhere within it... I cannot recall where. (when I got home the cursor was at upper left). On my workstation, I'd switch buffers using `M-C-l' (switch-to-other-buffer) between the code and the shell I was restarting the Apache from. If I left the shell showing, while I watched the error log tail over to my right on sidekick's display, then flipped back to the code buffer, the cursor would lose position and be shown at the upper left. I think it was getting confused about which frame/window it needed to display... but when I flipped back right away, not sitting around waiting for the server restart messages to print to the shell, but right back to the code in front of me on the workstation, the cursor would stay put. I am not sure where to begin looking for the bug or what the symptoms indicate. Will someone please essay? TIA. I'd fix it if I could. From kkm@dtmx.com Thu May 3 02:50:07 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id CAA22322 for ; Thu, 3 May 2001 02:50:06 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 02 May 2001 23:43:27 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010502234617.00b9d2e0@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 May 2001 23:48:48 -0700 To: xemacs-beta@xemacs.org From: "Kirill 'Big K' Katsnelson" Subject: loadup.el fails Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed `temacs -l ../lisp/loadup.el' fails in faces.el with (void-function frame-list). It is not normal, no? -kkm From kkm@dtmx.com Thu May 3 02:50:06 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id CAA22319; Thu, 3 May 2001 02:50:03 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 02 May 2001 23:43:27 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010502233201.04bc1da8@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 May 2001 23:49:55 -0700 To: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org From: "Kirill 'Big K' Katsnelson" Subject: [PATCH] Do not preempt redisplay of a printer Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_463966458==_" --=====================_463966458==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Ben noticed that printer would not print because redisplay gets preempted by a pending input event. Printers should not obey the regular preemption rules. Here's a fix. Also, I moved "implementation flags", so they are no more returned by a device method, rather stored in console method table. Since they are inherently static, they should not be returned by implicitly dynamic device method mechanism. I think this change is lucid enough, pardon the pun, to to into 20.4? I found one thingy in redisplay.c which I did not include in this patch, as it is definitely controversial - separate patch follows. Bill, could you please verify device-gtk.c? -kkm 2001-05-02 Kirill 'Big K' Katsnelson * console.h (struct console_methods): Added flags member. (CONSOLE_IMPLEMENTATION_FLAGS): Defined. (CONMETH_IMPL_FLAG): (CONSOLE_IMPL_FLAG): Macro to check implememntation flags. Defined XDEVIMPF_DONT_PREEMPT_REDISPLAY. * device.c (window_system_pixelated_geometry): Use the above macros. * device.h (DEVICE_IMPL_FLAG): Macro to check a device implememntation flag. * device.h (DEVICE_DISPLAY_P): Use it. * frame.c (delete_frame_internal): Use the above macro. * redisplay.c (redisplay_device): Use it. (redisplay_device): Obey XDEVIMPF_DONT_PREEMPT_REDISPLAY. (redisplay_frame): Ditto. * device-msw.c (mswindows_device_implementation_flags): Removed. (msprinter_device_implementation_flags): Removed. (console_type_create_device_mswindows): Removed references to implementation_flags methods, set implementation flags here. (console_type_create_device_mswindows): Added XDEVIMPF_DONT_PREEMPT. * device-gtk.c (gtk_device_implementation_flags): Removed method. (console_type_create_device_gtk): Removed method declaration. Added commented out statement which semantically matches the commented out statement in the above removed method. --=====================_463966458==_ Content-Type: text/plain; charset="us-ascii" Index: console.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/console.h,v retrieving revision 1.24 diff -u -r1.24 console.h --- console.h 2001/04/12 18:23:30 1.24 +++ console.h 2001/05/03 06:26:51 @@ -63,11 +63,34 @@ extern const struct struct_description cted_description; extern const struct struct_description console_methods_description; + +/* + * Constants returned by device_implementation_flags_method + */ + +/* Set when device uses pixel-based geometry */ +#define XDEVIMPF_PIXEL_GEOMETRY 0x00000001L + +/* Indicates that the device is a printer */ +#define XDEVIMPF_IS_A_PRINTER 0x00000002L + +/* Do not automatically redisplay this device */ +#define XDEVIMPF_NO_AUTO_REDISPLAY 0x00000004L + +/* Do not delete the device when last frame's gone */ +#define XDEVIMPF_FRAMELESS_OK 0x00000008L + +/* Do not preempt resiaply of frame or device once it starts */ +#define XDEVIMPF_DONT_PREEMPT_REDISPLAY 0x00000010L + struct console_methods { const char *name; /* Used by print_console, print_device, print_frame */ Lisp_Object symbol; Lisp_Object predicate_symbol; + unsigned int flags; /* Read-only implementation flags, set once upon + console type creation. INITIALIZE_CONSOLE_TYPE sets + this member to 0. */ /* console methods */ void (*init_console_method) (struct console *, Lisp_Object props); @@ -93,7 +116,6 @@ void (*asynch_device_change_method) (void); Lisp_Object (*device_system_metrics_method) (struct device *, enum device_metrics); - unsigned int (*device_implementation_flags_method) (void); Lisp_Object (*own_selection_method)(Lisp_Object selection_name, Lisp_Object selection_value, Lisp_Object how_to_add, @@ -303,26 +325,12 @@ #endif }; -/* - * Constants returned by device_implementation_flags_method - */ - -/* Set when device uses pixel-based geometry */ -#define XDEVIMPF_PIXEL_GEOMETRY 0x00000001L - -/* Indicates that the device is a printer */ -#define XDEVIMPF_IS_A_PRINTER 0x00000002L - -/* Do not automatically redisplay this device */ -#define XDEVIMPF_NO_AUTO_REDISPLAY 0x00000004L - -/* Do not delete the device when last frame's gone */ -#define XDEVIMPF_FRAMELESS_OK 0x00000008L - +#define CONMETH_TYPE(meths) ((meths)->symbol) +#define CONMETH_IMPL_FLAG(meths, f) ((meths)->flags & (f)) #define CONSOLE_TYPE_NAME(c) ((c)->conmeths->name) #define CONSOLE_TYPE(c) ((c)->conmeths->symbol) -#define CONMETH_TYPE(meths) ((meths)->symbol) +#define CONSOLE_IMPL_FLAG(c, f) CONMETH_IMPL_FLAG ((c)->conmeths, (f)) /******** Accessing / calling a console method *********/ @@ -406,6 +414,10 @@ implementation from console-type FROMTYPE */ #define CONSOLE_INHERITS_METHOD(type, fromtype, m) \ (type##_console_methods->m##_method = fromtype##_##m) + +/* Define console type implementation flags */ +#define CONSOLE_IMPLEMENTATION_FLAGS(type, flg) \ + (type##_console_methods->flags = flg) struct console { Index: device-gtk.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-gtk.c,v retrieving revision 1.2 diff -u -r1.2 device-gtk.c --- device-gtk.c 2001/04/12 18:23:32 1.2 +++ device-gtk.c 2001/05/03 06:26:51 @@ -680,12 +680,6 @@ return (result); } -static unsigned int -gtk_device_implementation_flags (void) -{ - return 0; /* XDEVIMPF_PIXEL_GEOMETRY; */ -} - /************************************************************************/ /* initialization */ @@ -717,7 +711,10 @@ CONSOLE_HAS_METHOD (gtk, mark_device); CONSOLE_HAS_METHOD (gtk, delete_device); CONSOLE_HAS_METHOD (gtk, device_system_metrics); - CONSOLE_HAS_METHOD (gtk, device_implementation_flags); + /* CONSOLE_IMPLEMENTATION_FLAGS (gtk, XDEVIMPF_PIXEL_GEOMETRY); */ + /* I inserted the above commented out statement, as the original + implementation of gtk_device_implementation_flags(), which I + deleted, contained commented out XDEVIMPF_PIXEL_GEOMETRY - kkm*/ } void Index: device-msw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device-msw.c,v retrieving revision 1.24 diff -u -r1.24 device-msw.c --- device-msw.c 2001/04/12 18:23:32 1.24 +++ device-msw.c 2001/05/03 06:26:51 @@ -334,12 +334,6 @@ return Qunbound; } -static unsigned int -mswindows_device_implementation_flags (void) -{ - return XDEVIMPF_PIXEL_GEOMETRY; -} - /************************************************************************/ /* printer helpers */ @@ -527,14 +521,6 @@ mark_object (DEVICE_MSPRINTER_DEVMODE (d)); } -static unsigned int -msprinter_device_implementation_flags (void) -{ - return ( XDEVIMPF_PIXEL_GEOMETRY - | XDEVIMPF_IS_A_PRINTER - | XDEVIMPF_NO_AUTO_REDISPLAY - | XDEVIMPF_FRAMELESS_OK ); -} /************************************************************************/ /* printer Lisp subroutines */ @@ -1291,13 +1277,17 @@ CONSOLE_HAS_METHOD (mswindows, mark_device); CONSOLE_HAS_METHOD (mswindows, delete_device); CONSOLE_HAS_METHOD (mswindows, device_system_metrics); - CONSOLE_HAS_METHOD (mswindows, device_implementation_flags); + CONSOLE_IMPLEMENTATION_FLAGS (mswindows, XDEVIMPF_PIXEL_GEOMETRY); CONSOLE_HAS_METHOD (msprinter, init_device); CONSOLE_HAS_METHOD (msprinter, mark_device); CONSOLE_HAS_METHOD (msprinter, delete_device); CONSOLE_HAS_METHOD (msprinter, device_system_metrics); - CONSOLE_HAS_METHOD (msprinter, device_implementation_flags); + CONSOLE_IMPLEMENTATION_FLAGS (msprinter, (XDEVIMPF_PIXEL_GEOMETRY + | XDEVIMPF_IS_A_PRINTER + | XDEVIMPF_NO_AUTO_REDISPLAY + | XDEVIMPF_DONT_PREEMPT_REDISPLAY + | XDEVIMPF_FRAMELESS_OK)); } Index: device.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device.c,v retrieving revision 1.16 diff -u -r1.16 device.c --- device.c 2001/04/12 18:23:33 1.16 +++ device.c 2001/05/03 06:26:52 @@ -1175,8 +1175,7 @@ Lisp_Object winsy = domain_device_type (domain); struct console_methods *meth = decode_console_type (winsy, ERROR_ME_NOT); assert (meth); - return (MAYBE_INT_CONTYPE_METH (meth, device_implementation_flags, ()) - & XDEVIMPF_PIXEL_GEOMETRY); + return CONMETH_IMPL_FLAG (meth, XDEVIMPF_PIXEL_GEOMETRY); } DEFUN ("domain-device-type", Fdomain_device_type, 0, 1, 0, /* Index: device.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/device.h,v retrieving revision 1.9 diff -u -r1.9 device.h --- device.h 2001/04/12 18:23:33 1.9 +++ device.h 2001/05/03 06:26:52 @@ -48,6 +48,7 @@ #define DEVICE_TYPE_NAME(d) ((d)->devmeths->name) #define DEVICE_TYPE(d) ((d)->devmeths->symbol) +#define DEVICE_IMPL_FLAG(d, f) CONMETH_IMPL_FLAG ((d)->devmeths, (f)) #define DEVICE_SPECIFIC_FRAME_PROPS(d) \ ((d)->devmeths->device_specific_frame_props) @@ -273,9 +274,7 @@ #define DEVICE_DISPLAY_P(dev) \ (DEVICE_LIVE_P (dev) && \ - (MAYBE_INT_DEVMETH (dev, \ - device_implementation_flags, ()) \ - & XDEVIMPF_IS_A_PRINTER) ? 0 : 1) + !DEVICE_IMPL_FLAG (dev, XDEVIMPF_IS_A_PRINTER)) #define CHECK_DISPLAY_DEVICE(dev) \ do { \ Index: frame.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/frame.c,v retrieving revision 1.40 diff -u -r1.40 frame.c --- frame.c 2001/04/12 18:23:47 1.40 +++ frame.c 2001/05/03 06:26:53 @@ -1304,9 +1304,8 @@ console = DEVICE_CONSOLE (d); con = XCONSOLE (console); - if (!called_from_delete_device && - !(MAYBE_INT_DEVMETH (d, device_implementation_flags, ()) - & XDEVIMPF_FRAMELESS_OK)) + if (!called_from_delete_device + && !DEVICE_IMPL_FLAG (d, XDEVIMPF_FRAMELESS_OK)) { /* If we're deleting the only non-minibuffer frame on the device, delete the device. */ Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.62 diff -u -r1.62 redisplay.c --- redisplay.c 2001/04/12 18:24:14 1.62 +++ redisplay.c 2001/05/03 06:26:57 @@ -6276,7 +6276,8 @@ { struct device *d = XDEVICE (f->device); - if (preemption_check) + if (preemption_check + && !DEVICE_IMPL_FLAG (d, XDEVIMPF_DONT_PREEMPT_REDISPLAY)) { /* The preemption check itself takes a lot of time, so normally don't do it here. We do it if called @@ -6436,27 +6437,29 @@ redisplay_device (struct device *d, int automatic) { Lisp_Object frame, frmcons; - int preempted = 0; int size_change_failed = 0; struct frame *f; - if (automatic - && (MAYBE_INT_DEVMETH (d, device_implementation_flags, ()) - & XDEVIMPF_NO_AUTO_REDISPLAY)) + if (automatic && DEVICE_IMPL_FLAG (d, XDEVIMPF_NO_AUTO_REDISPLAY)) return 0; if (DEVICE_STREAM_P (d)) /* nothing to do */ return 0; /* It is possible that redisplay has been called before the - device is fully initialized. If so then continue with the - next device. */ + device is fully initialized, or that the console implementation + allows frameless devices. If so then continue with the next + device. */ if (NILP (DEVICE_SELECTED_FRAME (d))) return 0; - REDISPLAY_PREEMPTION_CHECK; - if (preempted) - return 1; + if (!DEVICE_IMPL_FLAG (d, XDEVIMPF_DONT_PREEMPT_REDISPLAY)) + { + int preempted; + REDISPLAY_PREEMPTION_CHECK; + if (preempted) + return 1; + } /* Always do the selected frame first. */ frame = DEVICE_SELECTED_FRAME (d); @@ -6470,12 +6473,11 @@ { if (CLASS_REDISPLAY_FLAGS_CHANGEDP(f)) { - preempted = redisplay_frame (f, 0); + int preempted = redisplay_frame (f, 0); + if (preempted) + return 1; } - if (preempted) - return 1; - /* If the frame redisplay did not get preempted, then this flag should have gotten set to 0. It might be possible for that not to happen if a size change event were to occur at an odd @@ -6500,11 +6502,10 @@ { if (CLASS_REDISPLAY_FLAGS_CHANGEDP (f)) { - preempted = redisplay_frame (f, 0); + int preempted = redisplay_frame (f, 0); + if (preempted) + return 1; } - - if (preempted) - return 1; if (f->size_change_pending) size_change_failed = 1; --=====================_463966458==_-- From kkm@dtmx.com Thu May 3 02:56:48 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id CAA22735 for ; Thu, 3 May 2001 02:56:45 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 02 May 2001 23:50:11 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010502235332.00b9d2e0@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 May 2001 23:56:39 -0700 To: xemacs-beta@xemacs.org From: "Kirill 'Big K' Katsnelson" Subject: Re: loadup.el fails In-Reply-To: <4.3.2.7.2.20010502235318.0f11ae38@pop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Some time ago, moi wrote... >`temacs -l ../lisp/loadup.el' fails in faces.el Unsend. -batch. I am hebetudinous after this long day. But hey, I can still spell "hebetudinous"! -kkm From kkm@dtmx.com Thu May 3 04:13:33 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id EAA27572; Thu, 3 May 2001 04:13:32 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 03 May 2001 00:55:20 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010503005430.00b9d5d8@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 May 2001 01:01:48 -0700 To: xemacs-beta@xemacs.org, xemacs-patches@xemacs.org From: "Kirill 'Big K' Katsnelson" Subject: [PATCH] Warnings/const fix Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Dumper should treat opaques as const until it comes to loading them, where it to uncast unconst explicitly. This can as well go into 21.4, as it suppresses a bunch of warnings when compiling dumper.c... Well, a bunch of exactly two warnings, to be specific. -kkm 2001-05-03 Kirill 'Big K' Katsnelson * lisp.h: (dump_add_opaque): make varaddress parameter const. * dumper.c (struct pdump_opaque): make varaddress const. (dump_add_opaque): make varaddress parameter const. (pdump_load_finish): override const when copying into info.varaddress. Index: lisp.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp.h,v retrieving revision 1.46 diff --unified=3 -r1.46 lisp.h --- lisp.h 2001/04/30 09:12:03 1.46 +++ lisp.h 2001/05/03 07:58:30 @@ -2163,7 +2163,7 @@ /* dump_add_opaque (&var, size) dumps the opaque static structure `var'. */ #ifdef PDUMP -void dump_add_opaque (void *, size_t); +void dump_add_opaque (const void *, size_t); #else #define dump_add_opaque(varaddr,size) DO_NOTHING #endif Index: dumper.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/dumper.c,v retrieving revision 1.2 diff --unified=3 -r1.2 dumper.c --- dumper.c 2001/04/12 18:23:35 1.2 +++ dumper.c 2001/05/03 07:58:10 @@ -44,7 +44,7 @@ typedef struct { - void *varaddress; + const void *varaddress; size_t size; } pdump_opaque; @@ -84,7 +84,7 @@ /* Mark SIZE bytes at non-heap address VARADDRESS for dumping as is, without any bit-twiddling. */ void -dump_add_opaque (void *varaddress, size_t size) +dump_add_opaque (const void *varaddress, size_t size) { pdump_opaque info; info.varaddress = varaddress; @@ -1114,7 +1114,7 @@ for (i=0; inb_opaques; i++) { pdump_opaque info = PDUMP_READ_ALIGNED (p, pdump_opaque); - memcpy (info.varaddress, p, info.size); + memcpy ((void*)info.varaddress, p, info.size); p += info.size; } From martin@m17n.org Thu May 3 06:02:26 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA02468; Thu, 3 May 2001 06:02:24 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id TAA13639; Thu, 3 May 2001 19:02:12 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id TAA08531; Thu, 3 May 2001 19:02:11 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f43A27825640; Thu, 3 May 2001 19:02:07 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.11422.918179.464463@gargle.gargle.HOWL> Date: Thu, 3 May 2001 19:02:06 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: "Kirill 'Big K' Katsnelson" , Olivier Galibert Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] Warnings/const fix In-Reply-To: <4.3.2.7.2.20010503005430.00b9d5d8@pop> References: <4.3.2.7.2.20010503005430.00b9d5d8@pop> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "kkm" == Kirill Katsnelson writes: kkm> Dumper should treat opaques as const until it comes to loading them, kkm> where it to uncast unconst explicitly. This can as well go into 21.4, kkm> as it suppresses a bunch of warnings when compiling dumper.c... Well, kkm> a bunch of exactly two warnings, to be specific. I don't get any warnings with gcc or sun cc. This is a very Martinesque change - so much so, in fact, that I may have made the same change some time ago myself, but eventually reverted, either because of a comment by Olivier, or the fact that to be truly const-correct and never cast away const, you should have a pre-dump and post-dump version of the same structure, differing only in const-ness, which would not be worth the extra confusion. Anyways, it's clearly an improvement that dump_add_opaque's first arg is const, and I've tested with gcc, sun cc, sun CC, so: reviewed and approved; please commit to the trunk. From rendhalver@users.sourceforge.net Thu May 3 07:14:07 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA07560 for ; Thu, 3 May 2001 07:14:03 -0400 Received: from ulthwe.dyndns.org (p178-tnt1.brs.ihug.com.au [203.173.188.178]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id VAA10932 for ; Thu, 3 May 2001 21:13:55 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p178-tnt1.brs.ihug.com.au [203.173.188.178] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15089.15593.733492.369528@ulthwe.dyndns.org> Date: Thu, 3 May 2001 21:11:37 +1000 To: xemacs-beta@xemacs.org Subject: [WAY OFF TOPIC} but funny :) X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII hi all apologies if you have already seen this it is amusing http://www.gamespy.com/comics2/archive.asp?id=358 :) Rendhalver & the Happy Vandal From npak@ispras.ru Thu May 3 07:29:38 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id HAA08689 for ; Thu, 3 May 2001 07:29:15 -0400 Received: (qmail 23982 invoked from network); 3 May 2001 11:28:42 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 3 May 2001 11:28:42 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f43BSTU05914; Thu, 3 May 2001 15:28:29 +0400 (MSK) Received: tid PAA13027; Fri, 3 May 1996 15:27:58 +0300 Received: from dallas.kazbek.ispras.ru (dallas.kazbek.ispras.ru [194.186.94.155]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f43BS1g08763; Thu, 3 May 2001 15:28:01 +0400 (MSD) (envelope-from npak@ispras.ru) Received: (from npak@localhost) by dallas.kazbek.ispras.ru (8.9.3/8.9.3) id PAA01647; Thu, 3 May 2001 15:29:14 +0400 X-Authentication-Warning: dallas.kazbek.ispras.ru: npak set sender to npak@ispras.ru using -f Sender: npak@kazbek.ispras.ru To: "Stephen J. Turnbull" Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-nt@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [Success, failing tests!] XEmacs 21.4-b1 "Copyleft", i586-pc-win32 References: <15080.24042.217988.356947@turnbull.sk.tsukuba.ac.jp> From: npak@ispras.ru (Nick V. Pakoulin) Date: 03 May 2001 15:29:13 +0400 In-Reply-To: "Stephen J. Turnbull"'s message of "Fri, 27 Apr 2001 02:42:02 +0900" Message-ID: Lines: 80 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Urania) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii intro: "SJT" == Stephen J Turnbull writes: SJT> Nick Pakoulin in points out that these are all SJT> failures of "format." SJT> Can somebody check out what format is returning and try to find out why? SJT> It isn't happening on Unix platforms. SJT> FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02") SJT> FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02") SJT> FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06") SJT> FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06") SJT> FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02") SJT> FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02") SJT> FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06") SJT> FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06") SJT> FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02") SJT> FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02") SJT> FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06") SJT> FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06") SJT> FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02") SJT> FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02") SJT> FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06") SJT> FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06") I think, the problem is in Microsoft's handling of floating-point `format' instructions. Our tests expect exponent to be two digits long. Their implementation of `sprintf' (Visual Studio 6.0, MS Windows 2000) makes it three digits long. I evaluated `(format "%??" xx)' from tests and here is what I got: ------------------------------------------------------------------------------- (string= (format "%e" 100) "1.000000e+02") ==> (string= "1.000000e+002" "1.000000e+02") (string= (format "%E" 100) "1.000000E+02") ==> (string= "1.000000E+002" "1.000000E+02") (string= (format "%g" 1e-006) "1e-06") ==> (string= "1e-006" "1e-06") (string= (format "%G" 1e-006) "1E-06") ==> (string= "1E-006" "1E-06") (string= (format "%#e" 100) "1.000000e+02") ==> (string= "1.000000e+002" "1.000000e+02") (string= (format "%#E" 100) "1.000000E+02") ==> (string= "1.000000E+002" "1.000000E+02") (string= (format "%#g" 1e-006) "1.00000e-06") ==> (string= "1.00000e-006" "1.00000e-06") (string= (format "%#G" 1e-006) "1.00000E-06") ==> (string= "1.00000E-006" "1.00000E-06") (string= (format "%e" 100) "1.000000e+02") ==> (string= "1.000000e+002" "1.000000e+02") (string= (format "%E" 100) "1.000000E+02") ==> (string= "1.000000E+002" "1.000000E+02") (string= (format "%g" 1e-006) "1e-06") ==> (string= "1e-006" "1e-06") (string= (format "%G" 1e-006) "1E-06") ==> (string= "1E-006" "1E-06") (string= (format "%#e" 100) "1.000000e+02") ==> (string= "1.000000e+002" "1.000000e+02") (string= (format "%#E" 100) "1.000000E+02") ==> (string= "1.000000E+002" "1.000000E+02") (string= (format "%#g" 1e-006) "1.00000e-06") ==> (string= "1.00000e-006" "1.00000e-06") (string= (format "%#G" 1e-006) "1.00000E-06") ==> (string= "1.00000E-006" "1.00000E-06") Nick. From andyp@bea.com Thu May 3 12:31:25 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA09277 for ; Thu, 3 May 2001 12:31:24 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA02395 for ; Thu, 3 May 2001 09:31:28 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001193wss.beasys.com [192.168.6.17]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA01591 for ; Thu, 3 May 2001 09:32:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20010503092826.00b585c0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 May 2001 09:29:29 -0700 To: xemacs-beta@xemacs.org From: Andy Piper Subject: Dumb paths question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed So remind me, if I put stuff in /usr/local/lib/xemacs/site-lisp should XEmacs pick this up if I use load-library? andy From youngs@xemacs.org Thu May 3 18:43:38 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA02504 for ; Thu, 3 May 2001 18:43:36 -0400 Received: from slackware.mynet.pc (wdcax13-021.dialup.optusnet.com.au [198.142.220.21]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f43MhW815093 for ; Fri, 4 May 2001 08:43:32 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f43MpJoS012485; Fri, 4 May 2001 08:51:19 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Dumb paths question References: <4.3.2.7.2.20010503092826.00b585c0@san-francisco.beasys.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 04 May 2001 08:51:17 +1000 In-Reply-To: <4.3.2.7.2.20010503092826.00b585c0@san-francisco.beasys.com> (Andy Piper's message of "Thu, 03 May 2001 09:29:29 -0700") Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "AP" == Andy Piper writes: AP> So remind me, if I put stuff in /usr/local/lib/xemacs/site-lisp should AP> XEmacs pick this up if I use load-library? Depends on whether or not you './configure --with-site-lisp=yes' -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Thu May 3 19:54:40 2001 Received: from mail003.syd.optusnet.com.au (mail003.syd.optusnet.com.au [203.2.75.251]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA06351 for ; Thu, 3 May 2001 19:54:39 -0400 Received: from slackware.mynet.pc (wdcax13-021.dialup.optusnet.com.au [198.142.220.21]) by mail003.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f43NsRO01909; Fri, 4 May 2001 09:54:28 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f43NkuEd012985; Fri, 4 May 2001 09:46:56 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: Paul Kinnucan Subject: [sandipc@netscape.com (Sandip Chokshi)] XEmacs JDE Support? From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 04 May 2001 09:46:55 +1000 Message-ID: Lines: 53 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Can anyone help this person out? Paul, is it something you could help with? Thanks. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: sandipc@netscape.com (Sandip Chokshi) To: Subject: XEmacs JDE Support? Date: Thu, 3 May 2001 10:04:53 -0700 MIME-Version: 1.0 Hi youngs. I was looking through the Emacs FAQ and I saw your name/email on the section regarding the Java Development Environment for Xemacs. I recently upgraded to XEmacs 21.4 and it has a lot of great new features. One of the features that I've noticed is the "Classes" menu on my tool bar. It allows me to browse the classes/methods/.. of the .java file that I'm currently editing. This feature came out of the box with the 21.4 installation. Related to this feature, on my horizontal slider I see the class/method that my cursor is currently in. ----XEmacs: SXServlet.java (JDE PenDel Senator Font Fill Abbrev)--L57-C31--1%--[M:SXServlet.init] Emacs updates the method name every time I move my cursor. The problem that I have is that this feature appears to slow down the performance of my editing experience because it appears to re-parse the surround text to determine the current method. Is there any way I can turn off this feature and remove it from my horizantal splitter? I've tried to set jde-which-method-update to null but that didn't seem to work. Is there a fix for this in any version of xeamcs or JDE? If so, where can I get the new package. Any help would be greatly appreciated. This new emacs rocks except for this performance problem when editing java files. - Sandip (sandipc@netscape.com). --=-=-= -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| --=-=-=-- From CraigL@Knology.net Thu May 3 23:49:38 2001 Received: from smtp3.knology.net (user-24-214-63-13.knology.net [24.214.63.13]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id XAA18340 for ; Thu, 3 May 2001 23:49:37 -0400 Message-Id: <200105040349.XAA18340@gwyn.tux.org> Received: (qmail 21168 invoked from network); 4 May 2001 03:47:11 -0000 Received: from user-24-214-22-213.knology.net (24.214.22.213) by user-24-214-63-13.knology.net with SMTP; 4 May 2001 03:47:11 -0000 Date: Thu, 3 May 2001 23:46:49 -0400 (Eastern Daylight Time) From: Craig Lanning Subject: MinGW (gcc -mno-cygwin) Update To: xemacs-winnt@xemacs.org, xemacs-beta@xemacs.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Mailer: Mahogany, 0.62 'Mars', running under Windows 98 Well, the good news is that I finally succeeded in getting XEmacs 21.4.1 to build with MinGW (-mno-cygwin). I tried to use pdump but xemacs.exe kept crashing during initialization. If somebody with more knowledge of the pdump code wants to give me pointers on how to debug the problem, I'll try pdump again. I finally hacked unexcw.c to compile again and finally succeeded in producing a runable xemacs.exe. Long term, we should probably try to use unexnt.c for the MinGW port instead of unexcw.c, but I didn't have time today to try to get it to work. Below is a diff between my workspace and the 21.4 branch in CVS. This is not a final patch, by any means, and is only included for people to comment on. Craig Index: src/nt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/nt.c,v retrieving revision 1.21 diff -u -r1.21 nt.c --- src/nt.c 2001/04/12 18:24:06 1.21 +++ src/nt.c 2001/05/04 03:15:34 @@ -1216,10 +1216,10 @@ } #else -#if defined(MINGW) && CYGWIN_VERSION_DLL_MAJOR <= 21 -#define LowPart u.LowPart -#define HighPart u.HighPart -#endif +//#if defined(MINGW) && CYGWIN_VERSION_DLL_MAJOR <= 21 +//#define LowPart u.LowPart +//#define HighPart u.HighPart +//#endif static LARGE_INTEGER utc_base_li; Index: src/sysdep.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.c,v retrieving revision 1.38 diff -u -r1.38 sysdep.c --- src/sysdep.c 2001/04/12 18:24:22 1.38 +++ src/sysdep.c 2001/05/04 03:15:38 @@ -33,7 +33,7 @@ #ifdef WIN32_NATIVE #ifdef MINGW -#include +#include <../mingw/process.h> #else /* should not conflict with "process.h", as per ANSI definition. This is not true with visual c though. The trick below works with Index: src/syswindows.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/syswindows.h,v retrieving revision 1.2 diff -u -r1.2 syswindows.h --- src/syswindows.h 2001/04/12 18:24:23 1.2 +++ src/syswindows.h 2001/05/04 03:15:39 @@ -57,8 +57,7 @@ #include -#if (defined (CYGWIN) || defined(MINGW)) && \ - CYGWIN_VERSION_DLL_MAJOR < 21 +#if defined(CYGWIN) && CYGWIN_VERSION_DLL_MAJOR < 21 extern BOOL WINAPI DdeFreeStringHandle(DWORD,HSZ); extern BOOL WINAPI PlaySound(LPCSTR,HMODULE,DWORD); #define stricmp strcasecmp Index: src/unexcw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/unexcw.c,v retrieving revision 1.6 diff -u -r1.6 unexcw.c --- src/unexcw.c 2001/04/12 18:24:27 1.6 +++ src/unexcw.c 2001/05/04 03:15:39 @@ -37,7 +37,7 @@ #define PERROR(arg) perror(arg);exit(-1) -#ifndef HAVE_A_OUT_H +#if !defined(HAVE_A_OUT_H) && !defined(MINGW) unexec (char *, char *, void *, void *, void *) { PERROR("cannot unexec() a.out.h not installed"); @@ -47,7 +47,11 @@ #ifndef MAX_PATH #define MAX_PATH 260 #endif +#ifdef MINGW +#include <../../include/a.out.h> +#else #include +#endif #define ALLOC_UNIT 0xFFFF #define ALLOC_MASK ~((unsigned long)(ALLOC_UNIT)) cvs server: Diffing src/m cvs server: Diffing src/s Index: src/s/mingw32.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/s/mingw32.h,v retrieving revision 1.2 diff -u -r1.2 mingw32.h --- src/s/mingw32.h 2001/04/12 18:24:43 1.2 +++ src/s/mingw32.h 2001/05/04 03:15:40 @@ -133,13 +133,13 @@ #ifndef NOT_C_CODE #include -#include +#include <../mingw/process.h> #define mkdir __mkdir #include #undef mkdir -#ifdef HAVE_CYGWIN_VERSION_H -#include -#endif +//#ifdef HAVE_CYGWIN_VERSION_H +//#include +//#endif /* IO calls that are emulated or shadowed */ #define pipe sys_pipe @@ -192,10 +192,10 @@ gid_t getgid (void); gid_t getegid (void); -#if CYGWIN_VERSION_DLL_MAJOR <= 21 -#define _ftime ftime -#define _timeb timeb -#endif +//#if CYGWIN_VERSION_DLL_MAJOR <= 21 +//#define _ftime ftime +//#define _timeb timeb +//#endif /* Stuff that gets set wrongly or otherwise */ #define HAVE_SETITIMER From kkm@dtmx.com Fri May 4 01:59:25 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id BAA26106; Fri, 4 May 2001 01:59:24 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 03 May 2001 22:52:57 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010503225437.0f0eff08@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 May 2001 22:59:22 -0700 To: Martin Buchholz , Olivier Galibert From: "Kirill 'Big K' Katsnelson" Subject: Re: [PATCH] Warnings/const fix Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org In-Reply-To: <15089.11422.918179.464463@gargle.gargle.HOWL> References: <4.3.2.7.2.20010503005430.00b9d5d8@pop> <4.3.2.7.2.20010503005430.00b9d5d8@pop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Some time ago, Martin Buchholz wrote... >I don't get any warnings with gcc or sun cc. Perhaps Microsoft C is more picky about consts - it implicitly "upcasts" struct foo* to void* and const struct foo* to const void* without a warning, but warns about an implicit cast of const struct foo* to void*. >This is a very Martinesque change Thanks :) -kkm From steve@turnbull.sk.tsukuba.ac.jp Fri May 4 04:38:09 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA01392; Fri, 4 May 2001 04:38:07 -0400 Received: by localhost id m14vazv-00014dC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 4 May 2001 17:31:35 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.26854.897270.623019@turnbull.sk.tsukuba.ac.jp> Date: Fri, 4 May 2001 17:31:34 +0900 To: npak@ispras.ru (Nick V. Pakoulin) Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-nt@xemacs.org, xemacs-beta@xemacs.org Subject: Re: [Success, failing tests!] XEmacs 21.4-b1 "Copyleft", i586-pc-win32 In-Reply-To: References: <15080.24042.217988.356947@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Nick" == Nick V Pakoulin writes: Nick> I think, the problem is in Microsoft's handling of Nick> floating-point `format' instructions. Our tests expect Nick> exponent to be two digits long. Their implementation of Nick> `sprintf' (Visual Studio 6.0, MS Windows 2000) makes it Nick> three digits long. Thanks. (Adrian already reported this; sorry you missed it. Thank you too, Adrian, I think I forgot to before.) Fixes to tests/automated/ will be given preferred treatment for 21.4; I'll handle the FAQs if they break other tests. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From paston@bea.com Fri May 4 09:37:53 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA17097 for ; Fri, 4 May 2001 09:37:53 -0400 Received: from london.beasys.com (london [10.5.1.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA29730 for ; Fri, 4 May 2001 06:37:56 -0700 (PDT) Received: from paston.beasys.com (wsp001281wss.beasys.com [192.168.6.112]) by london.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id OAA06608 for ; Fri, 4 May 2001 14:37:41 +0100 (BST) Date: Fri, 4 May 2001 14:38:15 +0100 Message-ID: <9442-Fri04May2001143815+0100-paston@bea.com> X-Mailer: 21.5 (beta0) "alfalfa" XEmacs Lucid (via feedmail 8 Q) From: "Philip Aston" To: xemacs-beta@xemacs.org Subject: assertion failed, file event-stream.c, line 1037, tm This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.5 (beta0) "alfalfa" [Lucid] (i686-pc-cygwin) of Wed Apr 18 2001 on PASTON configured using `configure --with-dragndrop --site-includes=/usr/include/w32api' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: For a whlie now I've been getting occasional assertions: Fatal error: assertion failed, file event-stream.c, line 1037, tm Until now, I did not have a repeatable test case. With the latest source from CVS I've managed to repeat this when rendering an HTML rich VM message. I have a VM folder containing said message with which ... $ xemacs -q M-x vm-visit-folder bug (Spinning, messages about contacting www:80 etc) Assertion failure This happens under cygwin/native NT UI. It does not happen with -nw. The e-mail is private, but I'll forward it if anyone wants to investigate. - Phil Recent keystrokes: M-button1 M-button1up misc-user misc-user Recent messages (most recent first): Parsing /home/philipa/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... M-Sh-insert not defined. M-Sh-insert not defined. M-Sh-insert not defined. Loading emacsbug...done Loading emacsbug... 5 messages, 0 new, 0 unread, 0 deleted Loading smiley...done From paulk@mathworks.com Fri May 4 10:48:14 2001 Received: from smtp.mathworks.com (smtp.mathworks.com [144.212.95.12]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA21627; Fri, 4 May 2001 10:48:09 -0400 Received: from kinnucan (kinnucan.dhcp.mathworks.com [144.212.115.196]) by smtp.mathworks.com (8.11.2/8.11.2) with SMTP id f44Em4O08664; Fri, 4 May 2001 10:48:04 -0400 (EDT) Message-Id: <4.1.20010504104713.02a33910@pop.mathworks.com> X-Sender: paulk@pop.mathworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 04 May 2001 10:48:04 -0400 To: Steve Youngs , XEmacs Beta From: Paul Kinnucan Subject: Re: [sandipc@netscape.com (Sandip Chokshi)] XEmacs JDE Support? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:46 AM 5/4/01 +1000, Steve Youngs wrote: >Can anyone help this person out? Paul, is it something you could help >with? I already replied to him. He never acknowledged my reply. Paul From Olivier.Fambon@inrialpes.fr Fri May 4 12:06:21 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA26867 for ; Fri, 4 May 2001 12:06:16 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id SAA03124 for ; Fri, 4 May 2001 18:05:21 +0200 (MEST) Received: from inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f44G6BC27891 for ; Fri, 4 May 2001 18:06:12 +0200 (MEST) Message-ID: <3AF2D448.D7C9C1D6@inrialpes.fr> Date: Fri, 04 May 2001 18:09:44 +0200 From: Olivier Fambon X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: Problem with indentation on 21.4 Content-Type: multipart/digest; boundary="------------0C462EE8EBD3477129A2B614" This is a multi-part message in MIME format. --------------0C462EE8EBD3477129A2B614 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, [I'm not subscribed, but I've seen a bit of similar talk...] [This has been posted to comp.emacs.xemacs too] --------------0C462EE8EBD3477129A2B614 Path: news.inrialpes.fr!not-for-mail From: Olivier Fambon Newsgroups: comp.emacs.xemacs Subject: Problem with indentation in 21.4.1 Date: Thu, 03 May 2001 17:58:39 +0200 Organization: Unite de Recherche INRIA Rhone-Alpes France Message-ID: <3AF1802F.1CADE32E@inrialpes.fr> NNTP-Posting-Host: hahutu.inrialpes.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Xref: news.inrialpes.fr comp.emacs.xemacs:38631 Hi all, can anyone try this one: class Bozo { void func() { if () { if () { // } } else { /* */ } } } The last '}' will not indent correctly. - removing the first // comment, or adding a */ cures the problem - removing one level of if() does not show the problem I already submitted this to bug-cc-mode@gnu.org... but... It does not seem to be a cc-mode bug, coz it works in 21.1.8 with the same cc-mode package installed. It does not work with 21.4.0 (binary kit), nor with the version I have compiled (21.4.1). As I don't know excatly what depends on what in indentation... Thanxs. --------------0C462EE8EBD3477129A2B614 Path: news.inrialpes.fr!not-for-mail From: Olivier Fambon Newsgroups: comp.emacs.xemacs Subject: Re: Problem with indentation in 21.4.1 Date: Thu, 03 May 2001 19:29:03 +0200 Organization: Unite de Recherche INRIA Rhone-Alpes France Message-ID: <3AF1955F.82DE3CA5@inrialpes.fr> References: <3AF1802F.1CADE32E@inrialpes.fr> NNTP-Posting-Host: hahutu.inrialpes.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Xref: news.inrialpes.fr comp.emacs.xemacs:38632 If it is of interest, it's a cygwin XEmacs I am using... XEmacs 21.4 (patch 1) "Copyleft" [Lucid] (i686-pc-cygwin) of Thu May 3 2001 on HAHUTU --------------0C462EE8EBD3477129A2B614 Path: news.inrialpes.fr!not-for-mail From: Olivier Fambon Newsgroups: comp.emacs.xemacs Subject: Re: Problem with indentation in 21.4.1 Date: Fri, 04 May 2001 11:51:05 +0200 Organization: Unite de Recherche INRIA Rhone-Alpes France Message-ID: <3AF27B89.A08157E0@inrialpes.fr> References: <3AF1802F.1CADE32E@inrialpes.fr> <3AF1955F.82DE3CA5@inrialpes.fr> NNTP-Posting-Host: hahutu.inrialpes.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Xref: news.inrialpes.fr comp.emacs.xemacs:38659 Olivier Fambon wrote: > > If it is of interest, it's a cygwin XEmacs I am using... > > XEmacs 21.4 (patch 1) "Copyleft" [Lucid] (i686-pc-cygwin) of Thu May 3 > 2001 on HAHUTU Same verdict on a Linux: XEmacs 21.4 (patch 1) "Copyleft" [Lucid] (i686-pc-linux) of Fri May 4 2001 on sci-serv.inrialpes.fr Also note that the paren highlighting seems have a problem too (which might be linked ?). Forward highlighting works fine, but backwards gets mixed-up... A problem with regexps ? --------------0C462EE8EBD3477129A2B614-- From Olivier.Fambon@inrialpes.fr Fri May 4 12:16:24 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA27459 for ; Fri, 4 May 2001 12:16:19 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id SAA03352 for ; Fri, 4 May 2001 18:15:24 +0200 (MEST) Received: from inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f44GGFC28787 for ; Fri, 4 May 2001 18:16:15 +0200 (MEST) Message-ID: <3AF2D6A3.1AC88ED9@inrialpes.fr> Date: Fri, 04 May 2001 18:19:47 +0200 From: Olivier Fambon X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: 21.4.1 will not link on cygwin References: <3AF2D448.D7C9C1D6@inrialpes.fr> Content-Type: multipart/digest; boundary="------------A2D859EF5BD045566969BC5F" This is a multi-part message in MIME format. --------------A2D859EF5BD045566969BC5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [me again] + minor fix [compilation warnings] in src/sysfile.h: line 197: #if !S_IXUSR -> #ifndef S_IXUSR --------------A2D859EF5BD045566969BC5F Path: news.inrialpes.fr!not-for-mail From: Olivier Fambon Newsgroups: comp.emacs.xemacs Subject: 21.4.1 will not link on cygwin Date: Fri, 04 May 2001 17:30:49 +0200 Organization: Unite de Recherche INRIA Rhone-Alpes France Message-ID: <3AF2CB29.42031D4@inrialpes.fr> NNTP-Posting-Host: hahutu.inrialpes.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Xref: news.inrialpes.fr comp.emacs.xemacs:38662 This is due to linuxplay.o beeing linked-in when it should not. The cygwin I have is the 'latest' (as of this week...) It seems that configure.in adds linuxplay.o to the link (based on detection of soundcard.h), but links anyway with ntplay.o, which causes a duplicate definition. Removing linuxplay.o from the generated GNUMakefile cures it... Here is what I did: $ autoconf $ configure --with-x=no --with-dragndrop ... $ make ... gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith -mwindows -Wl,-export-dynamic -o temacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o unexcw.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o dragdrop.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o file-coding.o realpath.o getloadavg.o inline.o linuxplay.o miscplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o sheap.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o -ltiff -lpng -ljpeg -lz -lXpm -lgdbm -lncurses -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lwinspool linuxplay.o: In function `play_sound_file': /home/fambon/xemacs-21.4/src/linuxplay.c(.text+0xce8): multiple definition of `play_sound_file' ntplay.o(.text+0x0):/home/fambon/xemacs-21.4/src/ntplay.c: first defined here linuxplay.o: In function `play_sound_data': /home/fambon/xemacs-21.4/src/linuxplay.c(.text+0xd4c): multiple definition of `play_sound_data' ntplay.o(.text+0x11c):/home/fambon/xemacs-21.4/src/ntplay.c: first defined here /bin/ld: warning: cannot find entry symbol _WinMainCRTStartup; defaulting to 00401000 collect2: ld returned 1 exit status make[1]: *** [temacs] Error 1 make[1]: Leaving directory `/home/fambon/xemacs-21.4/src' make: *** [src] Error 2 [hahutu:~/xemacs-21.4] > --------------A2D859EF5BD045566969BC5F Path: news.inrialpes.fr!ciril.fr!fr.usenet-edu.net!usenet-edu.net!news.stealth.net!207.35.177.132.MISMATCH!news3.bellglobal.com!nntp.giganews.com!nntp2.aus1.giganews.com!NetNews1!attws2!Raleigh.netIQCorporation.com!attws1!ip.att.net!news.jhu.edu!not-for-mail NNTP-Posting-Host: fermat.mts.jhu.edu Newsgroups: comp.emacs.xemacs Date: Fri, 4 May 2001 11:44:30 -0400 Message-ID: From: Nevin Kapur Subject: Re: 21.4.1 will not link on cygwin Organization: None References: <3AF2CB29.42031D4@inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.jhu.edu 988989859 750966 128.220.17.18 (4 May 2001 15:24:19 GMT) X-Complaints-To: news@jhu.edu NNTP-Posting-Date: 4 May 2001 15:24:19 GMT X-Face: 5qz+Fg"Lb1Z3i<6h&9Ax$jfq]k{-f:z_Uk_fQ_DOy|7;xWm4@bDK52s/-A\!8g'3a}peKv> u;mMlqf!3"K"X5B;2E|Nz}< This is due to linuxplay.o beeing linked-in when it should not. [...] I can confirm this. I get the same behavior. -- Nevin GPG key: http://www.mts.jhu.edu/~kapur/pgp.txt --------------A2D859EF5BD045566969BC5F Path: news.inrialpes.fr!not-for-mail From: Olivier Fambon Newsgroups: comp.emacs.xemacs Subject: Re: 21.4.1 will not link on cygwin Date: Fri, 04 May 2001 18:06:02 +0200 Organization: Unite de Recherche INRIA Rhone-Alpes France Message-ID: <3AF2D36A.C2F9D207@inrialpes.fr> References: <3AF2CB29.42031D4@inrialpes.fr> NNTP-Posting-Host: hahutu.inrialpes.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Xref: news.inrialpes.fr comp.emacs.xemacs:38664 Nevin Kapur wrote: > > On Fri, 04 May 2001, Olivier Fambon wrote: > > > This is due to linuxplay.o beeing linked-in when it should not. > > [...] > > I can confirm this. I get the same behavior. > Fix: Just swap the tests in configure.in, i.e put MS sound detection *before* the linux one... --------------A2D859EF5BD045566969BC5F-- From andyp@bea.com Fri May 4 12:31:03 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA28250; Fri, 4 May 2001 12:30:48 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA13679; Fri, 4 May 2001 09:30:52 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA08395; Fri, 4 May 2001 09:31:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20010504093026.0224fe60@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 May 2001 09:31:29 -0700 To: Craig Lanning , xemacs-winnt@xemacs.org, xemacs-beta@xemacs.org From: Andy Piper Subject: Re: MinGW (gcc -mno-cygwin) Update In-Reply-To: <200105040349.XAA18333@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:46 PM 5/3/01 -0400, Craig Lanning wrote: >I finally hacked unexcw.c to compile again and finally succeeded in >producing a runable xemacs.exe. Long term, we should probably try to >use unexnt.c for the MinGW port instead of unexcw.c, but I didn't have >time today to try to get it to work. I will veto any such move :) This would be a regression. Instead we should fix unexcw.c to use the standard windows defines (instead of a.out.h) and then make the native port use that. Thanks for your hard work. andy From andyp@bea.com Fri May 4 12:31:40 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA28303 for ; Fri, 4 May 2001 12:31:39 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA14369 for ; Fri, 4 May 2001 09:31:44 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA08490; Fri, 4 May 2001 09:32:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010504093201.0223bd70@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 May 2001 09:32:20 -0700 To: "Philip Aston" , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: assertion failed, file event-stream.c, line 1037, tm In-Reply-To: <9442-Fri04May2001143815+0100-paston@bea.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hey Phil, You need to produce a C stacktrace. Thanks andy At 02:38 PM 5/4/01 +0100, Philip Aston wrote: >This bug report will be sent to the XEmacs Development Team, > not to your local site managers!! >Please write in English, because the XEmacs maintainers do not have >translators to read other languages for them. > >In XEmacs 21.5 (beta0) "alfalfa" [Lucid] (i686-pc-cygwin) of Wed Apr 18 >2001 on PASTON >configured using `configure --with-dragndrop >--site-includes=/usr/include/w32api' > >Please describe exactly what actions triggered the bug >and the precise symptoms of the bug: > >For a whlie now I've been getting occasional assertions: > > Fatal error: assertion failed, file event-stream.c, line 1037, tm > >Until now, I did not have a repeatable test case. > >With the latest source from CVS I've managed to repeat this when >rendering an HTML rich VM message. I have a VM folder containing said >message with which ... > > $ xemacs -q > M-x vm-visit-folder bug > (Spinning, messages about contacting www:80 etc) > Assertion failure > >This happens under cygwin/native NT UI. It does not happen with -nw. > >The e-mail is private, but I'll forward it if anyone wants to >investigate. > >- Phil > > >Recent keystrokes: > >M-button1 M-button1up misc-user misc-user > > >Recent messages (most recent first): > >Parsing /home/philipa/.mailrc... >Loading mail-abbrevs...done >Loading mail-abbrevs... >M-Sh-insert not defined. >M-Sh-insert not defined. >M-Sh-insert not defined. >Loading emacsbug...done >Loading emacsbug... >5 messages, 0 new, 0 unread, 0 deleted >Loading smiley...done From andyp@bea.com Fri May 4 12:37:16 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA28623 for ; Fri, 4 May 2001 12:37:16 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA18368; Fri, 4 May 2001 09:37:17 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA09586; Fri, 4 May 2001 09:37:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20010504093744.0224ad80@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 May 2001 09:37:54 -0700 To: Olivier Fambon , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Problem with indentation on 21.4 In-Reply-To: <3AF2D448.D7C9C1D6@inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I see similar oddities andy At 06:09 PM 5/4/01 +0200, Olivier Fambon wrote: >Hi all, > >[I'm not subscribed, but I've seen a bit of similar talk...] >[This has been posted to comp.emacs.xemacs too]Path: >news.inrialpes.fr!not-for-mail >From: Olivier Fambon >Newsgroups: comp.emacs.xemacs >Subject: Problem with indentation in 21.4.1 >Date: Thu, 03 May 2001 17:58:39 +0200 >Organization: Unite de Recherche INRIA Rhone-Alpes France >Message-ID: <3AF1802F.1CADE32E@inrialpes.fr> >NNTP-Posting-Host: hahutu.inrialpes.fr >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) >X-Accept-Language: en >Xref: news.inrialpes.fr comp.emacs.xemacs:38631 >Content-Transfer-Encoding: 7bit > >Hi all, can anyone try this one: > > >class Bozo { > > void func() { > if () { > if () { // > } > } else { > /* */ > } > } > } > > >The last '}' will not indent correctly. > >- removing the first // comment, or adding a */ cures the problem >- removing one level of if() does not show the problem > >I already submitted this to bug-cc-mode@gnu.org... but... > >It does not seem to be a cc-mode bug, coz it works in 21.1.8 with the >same cc-mode package installed. > >It does not work with 21.4.0 (binary kit), nor with the version I have >compiled (21.4.1). > >As I don't know excatly what depends on what in indentation... > >Thanxs. >Path: news.inrialpes.fr!not-for-mail >From: Olivier Fambon >Newsgroups: comp.emacs.xemacs >Subject: Re: Problem with indentation in 21.4.1 >Date: Thu, 03 May 2001 19:29:03 +0200 >Organization: Unite de Recherche INRIA Rhone-Alpes France >Message-ID: <3AF1955F.82DE3CA5@inrialpes.fr> >References: <3AF1802F.1CADE32E@inrialpes.fr> >NNTP-Posting-Host: hahutu.inrialpes.fr >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) >X-Accept-Language: en >Xref: news.inrialpes.fr comp.emacs.xemacs:38632 >Content-Transfer-Encoding: 7bit > > >If it is of interest, it's a cygwin XEmacs I am using... > >XEmacs 21.4 (patch 1) "Copyleft" [Lucid] (i686-pc-cygwin) of Thu May 3 >2001 on HAHUTU >Path: news.inrialpes.fr!not-for-mail >From: Olivier Fambon >Newsgroups: comp.emacs.xemacs >Subject: Re: Problem with indentation in 21.4.1 >Date: Fri, 04 May 2001 11:51:05 +0200 >Organization: Unite de Recherche INRIA Rhone-Alpes France >Message-ID: <3AF27B89.A08157E0@inrialpes.fr> >References: <3AF1802F.1CADE32E@inrialpes.fr> <3AF1955F.82DE3CA5@inrialpes.fr> >NNTP-Posting-Host: hahutu.inrialpes.fr >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) >X-Accept-Language: en >Xref: news.inrialpes.fr comp.emacs.xemacs:38659 >Content-Transfer-Encoding: 7bit > > > >Olivier Fambon wrote: > > > > If it is of interest, it's a cygwin XEmacs I am using... > > > > XEmacs 21.4 (patch 1) "Copyleft" [Lucid] (i686-pc-cygwin) of Thu May 3 > > 2001 on HAHUTU > >Same verdict on a Linux: > >XEmacs 21.4 (patch 1) "Copyleft" [Lucid] (i686-pc-linux) of Fri May 4 >2001 on sci-serv.inrialpes.fr > > >Also note that the paren highlighting seems have a problem too (which >might be linked ?). > >Forward highlighting works fine, but backwards gets mixed-up... > >A problem with regexps ? From Adrian.Aichner@t-online.de Fri May 4 14:26:50 2001 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA04094; Fri, 4 May 2001 14:26:49 -0400 Received: from fwd02.sul.t-online.com by mailout01.sul.t-online.com with smtp id 14vkHv-0001UD-06; Fri, 04 May 2001 20:26:47 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.41]) by fwd02.sul.t-online.com with esmtp id 14vkI4-1QtCCWC; Fri, 4 May 2001 20:26:56 +0200 To: Ben Wing Cc: XEmacs Web Maintainers , XEmacs Beta List Subject: Re: XEmacs on the Emacs web ring References: <3AEA5A4C.2A618526@666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Ben" == Ben Wing writes: Ben> adrian -- i've added www.xemacs.org to the Emacs web ring. Ben> please add this html somewhere on the site: Ben, All! You'll be thrilled to hear that XEmacs is now part of the Emacs Web Ring See http://www.gnusoftware.com/WebRing/zone.cgi?list Thanks, Ben, for suggesting this. Best regards, Adrian Ben>

Emacs-Ring - Site Number 28
[ Ben> href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=next">Next Site Ben> | href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=skipnext">Skip Next Ben> Site | href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=prev">Previous Ben> Site | href="http://www.gnusoftware.com/WebRing/zone.cgi?id=28&dir=skipprev">Skip Ben> Previous Site | href="http://www.gnusoftware.com/WebRing/zone.cgi?list">List Sites | href="http://www.gnusoftware.com/WebRing/">Home ]

Ben> Ben> -- Ben> ben Ben> I'm sometimes slow in getting around to reading my mail, so if you Ben> want to reach me faster, call 520-661-6661. Ben> See http://www.666.com/ben/chronic-pain/ for the hell I've been Ben> through. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From jason-dated-989700866.554634@mastaler.com Fri May 4 16:54:32 2001 Received: from sclp3.sclp.com (sclp3.sclp.com [209.196.61.66]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id QAA14495 for ; Fri, 4 May 2001 16:54:30 -0400 Received: (qmail 20424 invoked from network); 4 May 2001 20:54:29 -0000 Received: from localhost (HELO nightshade.la.mastaler.com) (jason@127.0.0.1) by localhost with SMTP; 4 May 2001 20:54:29 -0000 Received: (qmail 22093 invoked by uid 500); 4 May 2001 20:54:26 -0000 From: "Jason R. Mastaler" To: xemacs-beta@xemacs.org Subject: [21.4.1] png.h errors on mips-sgi-irix6.5 Mail-Copies-To: always X-Face: "Whz7py/hGVg+:}u&Q$/5z>j)gy%qNRX{j]0xGF&?Z"^b3`[6dY'^jSDlZDHh$m1~YX6U3J 1gOce%&je3)lVMOa/P,=9Kj:lmZb6]1hMmam*SW$GrVPa>b05y9/svb[uX.i><]^; iE1^(p_*=eLQJ6g$[aOX9I#`DCP\^O=RR:7|95hZ Date: 04 May 2001 14:54:25 -0600 Message-ID: Lines: 671 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Delivery-Agent: TMDA v0.12/Python 2.1 I'm trying to build 21.4.1 on IRIX 6.5, but am having problems getting the PNG support accepted. configure pokes along and fails when it detects my png lib due to a ton of errors in png.h. Anyone know why this is? [please CC: me on followups to be as I'm not on the list] checking for png.h... yes checking for png_read_image in -lpng... yes checking for workable png version information... no configure:8526: checking for workable png version information configure:8537: cc -o conftest -64 -O3 -OPT:Olimit=0 -I/users/jasonrm/include -xansi -L/users/jasonrm/lib/irix conftest.c -lpng -lz -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -lm 1>&5 cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 889 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_error_ptr) PNGARG((png_structp, png_const_charp)); ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 890 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_rw_ptr) PNGARG((png_structp, png_bytep, png_size_t)); ^ cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 890 "PNGAPI" has already been declared in the current scope. typedef void (PNGAPI *png_rw_ptr) PNGARG((png_structp, png_bytep, png_size_t)); ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 891 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_flush_ptr) PNGARG((png_structp)); ^ cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 891 "PNGAPI" has already been declared in the current scope. typedef void (PNGAPI *png_flush_ptr) PNGARG((png_structp)); ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 892 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_read_status_ptr) PNGARG((png_structp, png_uint_32, ^ cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 892 "PNGAPI" has already been declared in the current scope. typedef void (PNGAPI *png_read_status_ptr) PNGARG((png_structp, png_uint_32, ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 894 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_write_status_ptr) PNGARG((png_structp, png_uint_32, ^ cc-1275 cc: WARNING File = /users/jasonrm/include/png.h, Line = 894 The indicated "typedef" name has already been declared (with same type). typedef void (PNGAPI *png_write_status_ptr) PNGARG((png_structp, png_uint_32, ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 898 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_progressive_info_ptr) PNGARG((png_structp, png_infop)); ^ cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 898 "PNGAPI" has already been declared in the current scope. typedef void (PNGAPI *png_progressive_info_ptr) PNGARG((png_structp, png_infop)); ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 899 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_progressive_end_ptr) PNGARG((png_structp, png_infop)); ^ cc-1275 cc: WARNING File = /users/jasonrm/include/png.h, Line = 899 The indicated "typedef" name has already been declared (with same type). typedef void (PNGAPI *png_progressive_end_ptr) PNGARG((png_structp, png_infop)); ^ cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 900 An unmatched left parentheses "(" appears in an expression. typedef void (PNGAPI *png_progressive_row_ptr) PNGARG((png_structp, png_bytep, ^ cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 900 "PNGAPI" has already been declared in the current scope. typedef void (PNGAPI *png_progressive_row_ptr) PNGARG((png_structp, png_bytep, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 953 The identifier "png_error_ptr" is undefined. png_error_ptr error_fn; /* function for printing errors and aborting */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 954 The identifier "png_error_ptr" is undefined. png_error_ptr warning_fn; /* function for printing warnings */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 956 The identifier "png_rw_ptr" is undefined. png_rw_ptr write_data_fn; /* function for writing output data */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 957 The identifier "png_rw_ptr" is undefined. png_rw_ptr read_data_fn; /* function for reading input data */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1046 The identifier "png_flush_ptr" is undefined. png_flush_ptr output_flush_fn;/* Function for flushing output */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1082 The identifier "png_read_status_ptr" is undefined. png_read_status_ptr read_row_fn; /* called after each row is decoded */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1083 The identifier "png_write_status_ptr" is undefined. png_write_status_ptr write_row_fn; /* called after each row is encoded */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1085 The identifier "png_progressive_info_ptr" is undefined. png_progressive_info_ptr info_fn; /* called after header data fully read */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1086 The identifier "png_progressive_row_ptr" is undefined. png_progressive_row_ptr row_fn; /* called after each prog. row is decoded */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1087 The identifier "png_progressive_end_ptr" is undefined. png_progressive_end_ptr end_fn; /* called after image is complete */ ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1179 The identifier "png_fixed_point" is undefined. png_fixed_point int_gamma; ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1203 The identifier "png_access_version_number" is undefined. extern PNG_EXPORT(png_uint_32,png_access_version_number) PNGARG((void)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1203 Function returning function is not allowed. extern PNG_EXPORT(png_uint_32,png_access_version_number) PNGARG((void)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1208 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_sig_bytes) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1208 The identifier "png_set_sig_bytes" is undefined. extern PNG_EXPORT(void,png_set_sig_bytes) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1208 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_sig_bytes) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1216 The identifier "png_sig_cmp" is undefined. extern PNG_EXPORT(int,png_sig_cmp) PNGARG((png_bytep sig, png_size_t start, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1216 Function returning function is not allowed. extern PNG_EXPORT(int,png_sig_cmp) PNGARG((png_bytep sig, png_size_t start, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1222 The identifier "png_check_sig" is undefined. extern PNG_EXPORT(int,png_check_sig) PNGARG((png_bytep sig, int num)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1222 Function returning function is not allowed. extern PNG_EXPORT(int,png_check_sig) PNGARG((png_bytep sig, int num)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1225 The identifier "png_create_read_struct" is undefined. extern PNG_EXPORT(png_structp,png_create_read_struct) ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1226 The identifier "png_error_ptr" is undefined. PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1226 The identifier "png_error_ptr" is undefined. PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1226 Function returning function is not allowed. PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1230 The identifier "png_create_write_struct" is undefined. extern PNG_EXPORT(png_structp,png_create_write_struct) ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1231 The identifier "png_error_ptr" is undefined. PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1231 The identifier "png_error_ptr" is undefined. PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1231 Function returning function is not allowed. PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1234 The identifier "png_get_compression_buffer_size" is undefined. extern PNG_EXPORT(png_uint_32,png_get_compression_buffer_size) ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1235 Function returning function is not allowed. PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1237 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_compression_buffer_size) ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1237 The identifier "png_set_compression_buffer_size" is undefined. extern PNG_EXPORT(void,png_set_compression_buffer_size) ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1238 Function returning function is not allowed. PNGARG((png_structp png_ptr, png_uint_32 size)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1241 The identifier "png_reset_zstream" is undefined. extern PNG_EXPORT(int,png_reset_zstream) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1241 Function returning function is not allowed. extern PNG_EXPORT(int,png_reset_zstream) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1255 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_write_chunk) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1255 The identifier "png_write_chunk" is undefined. extern PNG_EXPORT(void,png_write_chunk) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1255 Function returning function is not allowed. extern PNG_EXPORT(void,png_write_chunk) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1259 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_write_chunk_start) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1259 The identifier "png_write_chunk_start" is undefined. extern PNG_EXPORT(void,png_write_chunk_start) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1259 Function returning function is not allowed. extern PNG_EXPORT(void,png_write_chunk_start) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1263 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_write_chunk_data) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1263 The identifier "png_write_chunk_data" is undefined. extern PNG_EXPORT(void,png_write_chunk_data) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1263 Function returning function is not allowed. extern PNG_EXPORT(void,png_write_chunk_data) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1267 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_write_chunk_end) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1267 The identifier "png_write_chunk_end" is undefined. extern PNG_EXPORT(void,png_write_chunk_end) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1267 Function returning function is not allowed. extern PNG_EXPORT(void,png_write_chunk_end) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1270 The identifier "png_create_info_struct" is undefined. extern PNG_EXPORT(png_infop,png_create_info_struct) ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1271 Function returning function is not allowed. PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1277 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_write_info_before_PLTE) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1277 The identifier "png_write_info_before_PLTE" is undefined. extern PNG_EXPORT(void,png_write_info_before_PLTE) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1277 Function returning function is not allowed. extern PNG_EXPORT(void,png_write_info_before_PLTE) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1279 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_write_info) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1279 The identifier "png_write_info" is undefined. extern PNG_EXPORT(void,png_write_info) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1279 Function returning function is not allowed. extern PNG_EXPORT(void,png_write_info) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1283 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_read_info) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1283 The identifier "png_read_info" is undefined. extern PNG_EXPORT(void,png_read_info) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1283 Function returning function is not allowed. extern PNG_EXPORT(void,png_read_info) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1295 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_convert_from_struct_tm) PNGARG((png_timep ptime, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1295 The identifier "png_convert_from_struct_tm" is undefined. extern PNG_EXPORT(void,png_convert_from_struct_tm) PNGARG((png_timep ptime, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1295 Function returning function is not allowed. extern PNG_EXPORT(void,png_convert_from_struct_tm) PNGARG((png_timep ptime, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1299 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_convert_from_time_t) PNGARG((png_timep ptime, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1299 The identifier "png_convert_from_time_t" is undefined. extern PNG_EXPORT(void,png_convert_from_time_t) PNGARG((png_timep ptime, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1299 Function returning function is not allowed. extern PNG_EXPORT(void,png_convert_from_time_t) PNGARG((png_timep ptime, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1306 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_expand) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1306 The identifier "png_set_expand" is undefined. extern PNG_EXPORT(void,png_set_expand) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1306 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_expand) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1307 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_gray_1_2_4_to_8) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1307 The identifier "png_set_gray_1_2_4_to_8" is undefined. extern PNG_EXPORT(void,png_set_gray_1_2_4_to_8) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1307 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_gray_1_2_4_to_8) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1308 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_palette_to_rgb) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1308 The identifier "png_set_palette_to_rgb" is undefined. extern PNG_EXPORT(void,png_set_palette_to_rgb) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1308 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_palette_to_rgb) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1309 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_tRNS_to_alpha) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1309 The identifier "png_set_tRNS_to_alpha" is undefined. extern PNG_EXPORT(void,png_set_tRNS_to_alpha) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1309 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_tRNS_to_alpha) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1314 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_bgr) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1314 The identifier "png_set_bgr" is undefined. extern PNG_EXPORT(void,png_set_bgr) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1314 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_bgr) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1319 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_gray_to_rgb) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1319 The identifier "png_set_gray_to_rgb" is undefined. extern PNG_EXPORT(void,png_set_gray_to_rgb) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1319 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_gray_to_rgb) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1334 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_build_grayscale_palette) PNGARG((int bit_depth, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1334 The identifier "png_build_grayscale_palette" is undefined. extern PNG_EXPORT(void,png_build_grayscale_palette) PNGARG((int bit_depth, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1334 Function returning function is not allowed. extern PNG_EXPORT(void,png_build_grayscale_palette) PNGARG((int bit_depth, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1353 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_filler) PNGARG((png_structp png_ptr, ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1353 The identifier "png_set_filler" is undefined. extern PNG_EXPORT(void,png_set_filler) PNGARG((png_structp png_ptr, ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1353 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_filler) PNGARG((png_structp png_ptr, ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1362 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_swap) PNGARG((png_structp png_ptr)); ^ cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1362 The identifier "png_set_swap" is undefined. extern PNG_EXPORT(void,png_set_swap) PNGARG((png_structp png_ptr)); ^ cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1362 Function returning function is not allowed. extern PNG_EXPORT(void,png_set_swap) PNGARG((png_structp png_ptr)); ^ cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1367 A parameter cannot have "void" type. extern PNG_EXPORT(void,png_set_packing) PNGARG((png_structp png_ptr)); ^ cc-3452 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1367 The compilation is aborted due to the number of errors. 101 errors detected in the compilation of "conftest.c". configure: failed program was: #line 8529 "configure" #include "confdefs.h" #include int main(int c, char **v) { if (c == 1) return 0; if (strcmp(png_libpng_ver, PNG_LIBPNG_VER_STRING) != 0) return 1; return (PNG_LIBPNG_VER < 10002) ? 2 : 0 ;} -- (TMDA - http://tmda.sourceforge.net/) (OSI-certified SPAM reduction system) From gabe@sgrail.com Fri May 4 19:17:34 2001 Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA22977 for ; Fri, 4 May 2001 19:17:12 -0400 Received: from sgrail.com ([208.190.152.25]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GCU004J12CDCD@mta5.rcsntx.swbell.net> for xemacs-beta@xemacs.org; Fri, 4 May 2001 17:55:28 -0500 (CDT) Date: Fri, 04 May 2001 17:54:39 -0500 From: Gabe Foster Subject: Re: [21.4.1] png.h errors on mips-sgi-irix6.5 Sender: gabe@mta5.rcsntx.swbell.net To: "Jason R. Mastaler" Cc: xemacs-beta@xemacs.org Message-id: <3AF3332F.D4D65685@sgrail.com> Organization: Silicon Grail MIME-version: 1.0 X-Mailer: Mozilla 4.75 [en] (X11; U; IRIX64 6.5 IP30) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: I've seen this problem as well. SGI install an old version of png in /usr/include and /usr/lib{n32,64,}. What I did was to point to versions I had installed from from SGI's freeware base (and other libraries I installed myself in /usr/include.) ./configure --site-includes=/usr/local/include:/usr/freeware/include --site-libraries=/usr/local/lib32:/usr/freeware/lib32 --libdir=/usr/local/lib32 As I recall this did not help completely, so I moved the png.h and pngconf.h files in /usr/include to png.h.bak and pngconf.h.bak and things worked much better. --> Gabe "Jason R. Mastaler" wrote: > > I'm trying to build 21.4.1 on IRIX 6.5, but am having problems getting > the PNG support accepted. configure pokes along and fails when it > detects my png lib due to a ton of errors in png.h. Anyone know why > this is? [please CC: me on followups to be as I'm not on the list] > > checking for png.h... yes > checking for png_read_image in -lpng... yes > checking for workable png version information... no > > configure:8526: checking for workable png version information > configure:8537: cc -o conftest -64 -O3 -OPT:Olimit=0 -I/users/jasonrm/include -xansi -L/users/jasonrm/lib/irix conftest.c -lpng -lz -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -lm 1>&5 > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 889 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_error_ptr) PNGARG((png_structp, png_const_charp)); > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 890 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_rw_ptr) PNGARG((png_structp, png_bytep, png_size_t)); > ^ > > cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 890 > "PNGAPI" has already been declared in the current scope. > > typedef void (PNGAPI *png_rw_ptr) PNGARG((png_structp, png_bytep, png_size_t)); > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 891 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_flush_ptr) PNGARG((png_structp)); > ^ > > cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 891 > "PNGAPI" has already been declared in the current scope. > > typedef void (PNGAPI *png_flush_ptr) PNGARG((png_structp)); > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 892 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_read_status_ptr) PNGARG((png_structp, png_uint_32, > ^ > > cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 892 > "PNGAPI" has already been declared in the current scope. > > typedef void (PNGAPI *png_read_status_ptr) PNGARG((png_structp, png_uint_32, > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 894 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_write_status_ptr) PNGARG((png_structp, png_uint_32, > ^ > > cc-1275 cc: WARNING File = /users/jasonrm/include/png.h, Line = 894 > The indicated "typedef" name has already been declared (with same type). > > typedef void (PNGAPI *png_write_status_ptr) PNGARG((png_structp, png_uint_32, > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 898 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_progressive_info_ptr) PNGARG((png_structp, png_infop)); > ^ > > cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 898 > "PNGAPI" has already been declared in the current scope. > > typedef void (PNGAPI *png_progressive_info_ptr) PNGARG((png_structp, png_infop)); > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 899 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_progressive_end_ptr) PNGARG((png_structp, png_infop)); > ^ > > cc-1275 cc: WARNING File = /users/jasonrm/include/png.h, Line = 899 > The indicated "typedef" name has already been declared (with same type). > > typedef void (PNGAPI *png_progressive_end_ptr) PNGARG((png_structp, png_infop)); > ^ > > cc-1018 cc: ERROR File = /users/jasonrm/include/png.h, Line = 900 > An unmatched left parentheses "(" appears in an expression. > > typedef void (PNGAPI *png_progressive_row_ptr) PNGARG((png_structp, png_bytep, > ^ > > cc-1101 cc: WARNING File = /users/jasonrm/include/png.h, Line = 900 > "PNGAPI" has already been declared in the current scope. > > typedef void (PNGAPI *png_progressive_row_ptr) PNGARG((png_structp, png_bytep, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 953 > The identifier "png_error_ptr" is undefined. > > png_error_ptr error_fn; /* function for printing errors and aborting */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 954 > The identifier "png_error_ptr" is undefined. > > png_error_ptr warning_fn; /* function for printing warnings */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 956 > The identifier "png_rw_ptr" is undefined. > > png_rw_ptr write_data_fn; /* function for writing output data */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 957 > The identifier "png_rw_ptr" is undefined. > > png_rw_ptr read_data_fn; /* function for reading input data */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1046 > The identifier "png_flush_ptr" is undefined. > > png_flush_ptr output_flush_fn;/* Function for flushing output */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1082 > The identifier "png_read_status_ptr" is undefined. > > png_read_status_ptr read_row_fn; /* called after each row is decoded */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1083 > The identifier "png_write_status_ptr" is undefined. > > png_write_status_ptr write_row_fn; /* called after each row is encoded */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1085 > The identifier "png_progressive_info_ptr" is undefined. > > png_progressive_info_ptr info_fn; /* called after header data fully read */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1086 > The identifier "png_progressive_row_ptr" is undefined. > > png_progressive_row_ptr row_fn; /* called after each prog. row is decoded */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1087 > The identifier "png_progressive_end_ptr" is undefined. > > png_progressive_end_ptr end_fn; /* called after image is complete */ > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1179 > The identifier "png_fixed_point" is undefined. > > png_fixed_point int_gamma; > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1203 > The identifier "png_access_version_number" is undefined. > > extern PNG_EXPORT(png_uint_32,png_access_version_number) PNGARG((void)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1203 > Function returning function is not allowed. > > extern PNG_EXPORT(png_uint_32,png_access_version_number) PNGARG((void)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1208 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_sig_bytes) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1208 > The identifier "png_set_sig_bytes" is undefined. > > extern PNG_EXPORT(void,png_set_sig_bytes) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1208 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_sig_bytes) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1216 > The identifier "png_sig_cmp" is undefined. > > extern PNG_EXPORT(int,png_sig_cmp) PNGARG((png_bytep sig, png_size_t start, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1216 > Function returning function is not allowed. > > extern PNG_EXPORT(int,png_sig_cmp) PNGARG((png_bytep sig, png_size_t start, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1222 > The identifier "png_check_sig" is undefined. > > extern PNG_EXPORT(int,png_check_sig) PNGARG((png_bytep sig, int num)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1222 > Function returning function is not allowed. > > extern PNG_EXPORT(int,png_check_sig) PNGARG((png_bytep sig, int num)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1225 > The identifier "png_create_read_struct" is undefined. > > extern PNG_EXPORT(png_structp,png_create_read_struct) > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1226 > The identifier "png_error_ptr" is undefined. > > PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1226 > The identifier "png_error_ptr" is undefined. > > PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1226 > Function returning function is not allowed. > > PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1230 > The identifier "png_create_write_struct" is undefined. > > extern PNG_EXPORT(png_structp,png_create_write_struct) > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1231 > The identifier "png_error_ptr" is undefined. > > PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1231 > The identifier "png_error_ptr" is undefined. > > PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1231 > Function returning function is not allowed. > > PNGARG((png_const_charp user_png_ver, png_voidp error_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1234 > The identifier "png_get_compression_buffer_size" is undefined. > > extern PNG_EXPORT(png_uint_32,png_get_compression_buffer_size) > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1235 > Function returning function is not allowed. > > PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1237 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_compression_buffer_size) > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1237 > The identifier "png_set_compression_buffer_size" is undefined. > > extern PNG_EXPORT(void,png_set_compression_buffer_size) > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1238 > Function returning function is not allowed. > > PNGARG((png_structp png_ptr, png_uint_32 size)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1241 > The identifier "png_reset_zstream" is undefined. > > extern PNG_EXPORT(int,png_reset_zstream) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1241 > Function returning function is not allowed. > > extern PNG_EXPORT(int,png_reset_zstream) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1255 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_write_chunk) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1255 > The identifier "png_write_chunk" is undefined. > > extern PNG_EXPORT(void,png_write_chunk) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1255 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_write_chunk) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1259 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_write_chunk_start) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1259 > The identifier "png_write_chunk_start" is undefined. > > extern PNG_EXPORT(void,png_write_chunk_start) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1259 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_write_chunk_start) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1263 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_write_chunk_data) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1263 > The identifier "png_write_chunk_data" is undefined. > > extern PNG_EXPORT(void,png_write_chunk_data) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1263 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_write_chunk_data) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1267 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_write_chunk_end) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1267 > The identifier "png_write_chunk_end" is undefined. > > extern PNG_EXPORT(void,png_write_chunk_end) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1267 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_write_chunk_end) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1270 > The identifier "png_create_info_struct" is undefined. > > extern PNG_EXPORT(png_infop,png_create_info_struct) > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1271 > Function returning function is not allowed. > > PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1277 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_write_info_before_PLTE) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1277 > The identifier "png_write_info_before_PLTE" is undefined. > > extern PNG_EXPORT(void,png_write_info_before_PLTE) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1277 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_write_info_before_PLTE) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1279 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_write_info) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1279 > The identifier "png_write_info" is undefined. > > extern PNG_EXPORT(void,png_write_info) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1279 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_write_info) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1283 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_read_info) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1283 > The identifier "png_read_info" is undefined. > > extern PNG_EXPORT(void,png_read_info) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1283 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_read_info) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1295 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_convert_from_struct_tm) PNGARG((png_timep ptime, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1295 > The identifier "png_convert_from_struct_tm" is undefined. > > extern PNG_EXPORT(void,png_convert_from_struct_tm) PNGARG((png_timep ptime, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1295 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_convert_from_struct_tm) PNGARG((png_timep ptime, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1299 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_convert_from_time_t) PNGARG((png_timep ptime, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1299 > The identifier "png_convert_from_time_t" is undefined. > > extern PNG_EXPORT(void,png_convert_from_time_t) PNGARG((png_timep ptime, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1299 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_convert_from_time_t) PNGARG((png_timep ptime, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1306 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_expand) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1306 > The identifier "png_set_expand" is undefined. > > extern PNG_EXPORT(void,png_set_expand) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1306 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_expand) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1307 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_gray_1_2_4_to_8) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1307 > The identifier "png_set_gray_1_2_4_to_8" is undefined. > > extern PNG_EXPORT(void,png_set_gray_1_2_4_to_8) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1307 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_gray_1_2_4_to_8) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1308 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_palette_to_rgb) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1308 > The identifier "png_set_palette_to_rgb" is undefined. > > extern PNG_EXPORT(void,png_set_palette_to_rgb) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1308 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_palette_to_rgb) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1309 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_tRNS_to_alpha) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1309 > The identifier "png_set_tRNS_to_alpha" is undefined. > > extern PNG_EXPORT(void,png_set_tRNS_to_alpha) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1309 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_tRNS_to_alpha) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1314 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_bgr) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1314 > The identifier "png_set_bgr" is undefined. > > extern PNG_EXPORT(void,png_set_bgr) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1314 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_bgr) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1319 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_gray_to_rgb) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1319 > The identifier "png_set_gray_to_rgb" is undefined. > > extern PNG_EXPORT(void,png_set_gray_to_rgb) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1319 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_gray_to_rgb) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1334 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_build_grayscale_palette) PNGARG((int bit_depth, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1334 > The identifier "png_build_grayscale_palette" is undefined. > > extern PNG_EXPORT(void,png_build_grayscale_palette) PNGARG((int bit_depth, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1334 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_build_grayscale_palette) PNGARG((int bit_depth, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1353 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_filler) PNGARG((png_structp png_ptr, > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1353 > The identifier "png_set_filler" is undefined. > > extern PNG_EXPORT(void,png_set_filler) PNGARG((png_structp png_ptr, > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1353 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_filler) PNGARG((png_structp png_ptr, > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1362 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_swap) PNGARG((png_structp png_ptr)); > ^ > > cc-1020 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1362 > The identifier "png_set_swap" is undefined. > > extern PNG_EXPORT(void,png_set_swap) PNGARG((png_structp png_ptr)); > ^ > > cc-1090 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1362 > Function returning function is not allowed. > > extern PNG_EXPORT(void,png_set_swap) PNGARG((png_structp png_ptr)); > ^ > > cc-1529 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1367 > A parameter cannot have "void" type. > > extern PNG_EXPORT(void,png_set_packing) PNGARG((png_structp png_ptr)); > ^ > > cc-3452 cc: ERROR File = /users/jasonrm/include/png.h, Line = 1367 > The compilation is aborted due to the number of errors. > > 101 errors detected in the compilation of "conftest.c". > configure: failed program was: > #line 8529 "configure" > #include "confdefs.h" > #include > int main(int c, char **v) { > if (c == 1) return 0; > if (strcmp(png_libpng_ver, PNG_LIBPNG_VER_STRING) != 0) return 1; > return (PNG_LIBPNG_VER < 10002) ? 2 : 0 ;} > > -- > (TMDA - http://tmda.sourceforge.net/) > (OSI-certified SPAM reduction system) -- * J. Gabriel Foster "We have advanced to new and surprising * Silicon Grail levels of bafflement" - Lois McMaster Bujold * gabe@sgrail.com From abegel@eecs.berkeley.edu Fri May 4 20:37:35 2001 Received: from ups.millennium.berkeley.edu (ups.Millennium.Berkeley.EDU [169.229.48.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA26699 for ; Fri, 4 May 2001 20:37:35 -0400 content-class: urn:content-classes:message Subject: Bug fix for defining types in external modules MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 4 May 2001 17:37:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug fix for defining types in external modules Thread-Index: AcDU+5HwG5jtu3w6RaCmHNH9IiqTnw== From: "Andrew Begel" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id UAA26699 Here's a small bug fix to compiling external modules that declare new lrecord types: Index: lrecord.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lrecord.h,v retrieving revision 1.9 diff -u -r1.9 lrecord.h --- lrecord.h 2001/04/12 18:24:00 1.9 +++ lrecord.h 2001/05/05 00:20:16 @@ -495,7 +495,7 @@ #define INIT_EXTERNAL_LRECORD_IMPLEMENTATION(type) do { \ lrecord_type_##type = lrecord_type_count++; \ - lrecord_##type.lrecord_type_index = lrecord_type_##type; \ + lrecord_##type.lrecord_type_index = (enum lrecord_type)lrecord_type_##type; \ INIT_LRECORD_IMPLEMENTATION(type); \ } while (0) We just needed one more typecast to stop gcc from complaining about casting an unsigned int to an enum lrecord_type. Andrew From abegel@eecs.berkeley.edu Fri May 4 20:46:56 2001 Received: from ups.millennium.berkeley.edu (ups.Millennium.Berkeley.EDU [169.229.48.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA27345 for ; Fri, 4 May 2001 20:46:56 -0400 content-class: urn:content-classes:message Subject: Bug in XEmacs config script for finding ld MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 4 May 2001 17:46:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug in XEmacs config script for finding ld Thread-Index: AcDU/N8oLJMiyO5RR4GU8k2HgeIFlQ== From: "Andrew Begel" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id UAA27345 I was trying to build XEmacs 21.4.1 on Solaris 8. I've got gcc 2.95.2 installed and configured to use GNU ld. However, I also have Solaris's ld installed too. The XEmacs configure script uses a macro defined in aclocal.m4 to check for GNU ld vs. the local platform's ld. This macro has a mistake in it. It uses gcc -print-prog-name=ld to get the path to the linker used by gcc, and then should use the result to run ld -v to see if the linker is GNU. But the original macro assumes that if the linker's path has gcc-lib in it, then running gcc -v must be just as good as running the linker with -v directly. But that's not ok. Running gcc -v tells you nothing about the linker that gcc is using, so the GNU ld test fails when it's supposed to succeed. You should really run the linker that gcc reports. This bug fix to the macro will allow configure to correctly use the GNU ld when building XEmacs. Andrew Index: aclocal.m4 =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/aclocal.m4,v retrieving revision 1.3 diff -u -r1.3 aclocal.m4 --- aclocal.m4 2001/04/12 18:20:32 1.3 +++ aclocal.m4 2001/05/04 22:46:03 @@ -313,12 +313,13 @@ # Accept absolute paths. /*) if test -z "$LTLD"; then - case "$ac_prog" in - *gcc-lib*) LTLD="$CC" - ;; - *) LTLD="$ac_prog" - ;; - esac +# case "$ac_prog" in +# *gcc-lib*) LTLD="$CC" +# ;; +# *) + LTLD="$ac_prog" +# ;; +# esac fi ;; "") From ben@666.com Sat May 5 04:45:38 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id EAA19635 for ; Sat, 5 May 2001 04:45:35 -0400 Received: (qmail 26534 invoked by alias); 5 May 2001 08:45:31 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 26482 invoked by uid 0); 5 May 2001 08:45:29 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 5 May 2001 08:45:29 -0000 Message-ID: <3AF3BDFF.6B111AE4@666.com> Date: Sat, 05 May 2001 01:46:55 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs beta list , XEmacs NT List , "Kirill M. Katsnelson" Subject: about those print margins ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit i changed top and bottom defaults to 0.5". 1" seemed like wasted space. comments? -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From youngs@xemacs.org Sat May 5 06:06:56 2001 Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [203.2.75.229]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA22558 for ; Sat, 5 May 2001 06:06:54 -0400 Received: from slackware.mynet.pc (wdcax13-248.dialup.optusnet.com.au [198.142.220.248]) by mail005.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f45A6ll13180 for ; Sat, 5 May 2001 20:06:47 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f45A5Gqo011041; Sat, 5 May 2001 20:05:16 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: find-function & load-history From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 05 May 2001 20:05:16 +1000 Message-ID: Lines: 22 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Just because I'm a curious old soul, and this has been bugging me for a while now... By default, 'M-x find-function RET abbrev-mode RET'[1] shows a buffer with /usr/local/src/xemacs-21.5/lisp/abbrev.el in it. And if that file doesn't exist, an error. How can I make it show me: /usr/local/lib/xemacs-21.5-b0/lisp/abbrev.el ie, the installed version? Footnotes: [1] Just a randomly chosen defun in core lisp to make the point. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From steve@turnbull.sk.tsukuba.ac.jp Sat May 5 07:28:46 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA25606; Sat, 5 May 2001 07:28:45 -0400 Received: by localhost id m14w09U-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Sat, 5 May 2001 20:23:08 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15091.58000.258819.143117@turnbull.sk.tsukuba.ac.jp> Date: Sat, 5 May 2001 20:22:56 +0900 To: Steve Youngs Cc: XEmacs Beta Subject: find-function & load-history In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "SY" == Steve Youngs writes: SY> How can I make [find-function] show me [...] the installed SY> version? (setq find-function-source-path nil) should work. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From hniksic@arsdigita.com Sat May 5 08:09:51 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA27081 for ; Sat, 5 May 2001 08:09:50 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14w0s9-00028Y-00; Sat, 05 May 2001 14:09:17 +0200 Sender: hniksic@florida.arsdigita.de To: Ben Wing Cc: XEmacs Beta List Subject: Re: [bug] kill-line broken in macros References: <3AF09A66.8020D811@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 05 May 2001 14:09:17 +0200 In-Reply-To: <3AF09A66.8020D811@666.com> (Ben Wing's message of "Wed, 02 May 2001 16:38:14 -0700") Message-ID: Lines: 7 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > i hereby withdraw my change, and the associated news file entry: Hmph. Why? Shouldn't we just fix the macro thing? kill-line is not the only function that behaves differently depending on whether you call it interactively. From mast@lysator.liu.se Sat May 5 10:43:39 2001 Received: from godzilla.idonex.se (godzilla.idonex.se [194.52.182.190]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA01375 for ; Sat, 5 May 2001 10:43:38 -0400 Received: from lister.idonex.se (mast@lister.idonex.se [194.52.182.147]) by godzilla.idonex.se (8.9.3/8.9.3) with SMTP id QAA15125; Sat, 5 May 2001 16:43:35 +0200 (MET DST) Sender: mast@lister.idonex.se To: Charles Hines Cc: bug-cc-mode@gnu.org, XEmacs Beta List Subject: Re: Bug in cc-mode v5.27 and v5.28 References: <15060.36286.463731.109050@gargle.gargle.HOWL> Reply-To: bug-cc-mode@gnu.org Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Martin Stjernholm Date: 05 May 2001 16:43:35 +0200 In-Reply-To: Charles Hines's message of "Wed, 11 Apr 2001 13:00:46 -0400" Message-ID: <5b4ruzg8ko.fsf@lister.idonex.se> Lines: 29 X-Mailer: Gnus v5.6.45/Emacs 19.34 Charles Hines wrote: > void > foo(int a) > { > switch (a) > { > case 1: // Example: "1:2:3" > { > } > break; // "unbalanced paren" error occurs here > } > } The following patch fixes this. Thanks. diff -u -r5.106 cc-langs.el --- cc-langs.el 2001/02/18 16:09:44 5.106 +++ cc-langs.el 2001/05/05 13:14:36 @@ -344,7 +344,7 @@ (make-variable-buffer-local 'c-comment-start-regexp) ;; Regexp describing a switch's case or default label for all languages -(defconst c-switch-label-key "\\(\\(case[( \t]+\\S .*\\)\\|default[ \t]*\\):") +(defconst c-switch-label-key "\\(\\(case[( \t]+\\S [^:]*\\)\\|default[ \t]*\\):") ;; Regexp describing any label. (defconst c-label-key (concat c-symbol-key ":\\([^:]\\|$\\)")) From rendhalver@users.sourceforge.net Sat May 5 10:49:32 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA01715 for ; Sat, 5 May 2001 10:49:18 -0400 Received: from ulthwe.dyndns.org (p497-tnt1.brs.ihug.com.au [203.173.189.243]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id AAA13088 for ; Sun, 6 May 2001 00:49:03 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p497-tnt1.brs.ihug.com.au [203.173.189.243] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15092.4694.989469.685700@ulthwe.dyndns.org> Date: Sun, 6 May 2001 00:46:46 +1000 To: xemacs-beta@xemacs.org Subject: promblem with xemacs 21.5 X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII i got this after compiling latest cvs of 21.5 (1) (initialization/error) An error has occurred while loading /home/rendhalver/.xemacs/init.el: Cannot open load file: dired To ensure normal operation, you should investigate the cause of the error in your initialization file and remove it. Use the `-debug-init' option to XEmacs to view a complete error backtrace. configure options sh configure '--package-path=/usr/local/xemacs-beta/lib/xemacs/xemacs-packages' '--with-mule' '--with-gnome=no' '--prefix=/usr/local/xemacs-beta' '--with-prefix' '--srcdir=/usr/local/src/xemacs/xemacs-21.5' um anything else i need to send to help work this out et me know i can send a full build report if that is needed (thanks adrian for your cool build package its reali useful for this) -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From Adrian.Aichner@t-online.de Sat May 5 11:51:59 2001 Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA05001 for ; Sat, 5 May 2001 11:51:59 -0400 Received: from fwd04.sul.t-online.com by mailout00.sul.t-online.com with smtp id 14w4Ld-0001hk-05; Sat, 05 May 2001 17:51:57 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.64]) by fwd04.sul.t-online.com with esmtp id 14w4Lp-0GI0dUC; Sat, 5 May 2001 17:52:09 +0200 To: rendhalver@users.sourceforge.net Cc: xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 References: <15092.4694.989469.685700@ulthwe.dyndns.org> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 54 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Peter" == Peter Brown writes: Peter> i got this after compiling latest cvs of 21.5 (1) Peter> (initialization/error) An error has occurred while loading Peter> /home/rendhalver/.xemacs/init.el: Peter> Cannot open load file: dired Peter> To ensure normal operation, you should investigate the Peter> cause of the error in your initialization file and remove Peter> it. Use the `-debug-init' option to XEmacs to view a Peter> complete error backtrace. Peter> configure options Peter> sh configure '--package-path=/usr/local/xemacs-beta/lib/xemacs/xemacs-packages' Peter> '--with-mule' '--with-gnome=no' '--prefix=/usr/local/xemacs-beta' Peter> '--with-prefix' '--srcdir=/usr/local/src/xemacs/xemacs-21.5' Peter> um anything else i need to send to help work this out et me Peter> know Yes, see above. Please send us output of xemacs ... -debug-init Peter> i can send a full build report if that is needed Peter> (thanks adrian for your cool build package its reali useful Peter> for this) You're quite welcome. Thanks for your braveness, user number 1! Best regards, Adrian Peter> -- Peter> ------------------------------------------------------------------------- Peter> Peter Brown Peter> Web Programmer/Sys Admin/Apache Admin Education Development Web Peter> peter@edw.com.au www.edw.com.au Peter> rendhalver@users.sourceforge.net Peter> ------------------------------------------------------------------------- -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From jmincy@muniversal.com Sat May 5 12:54:16 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA08267 for ; Sat, 5 May 2001 12:54:16 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=shrdlu.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14w5Jw-0002JB-00 for xemacs-beta@xemacs.org; Sat, 05 May 2001 12:54:16 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15092.11542.60000.650214@shrdlu.muniversal.com> Date: Sat, 5 May 2001 12:40:54 -0400 To: xemacs-beta@xemacs.org Subject: jde/setnu.el X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid IN 21.1.13 xemacs, jde/setnu.el. I do (find-file " (require 'setnu) (setnu-mode) When I try to kill-line, I get the following: Signaling: (wrong-type-argument extentp nil) setnu-set-extent-property(nil setnu-next-extent #>) setnu-extent-at-create(13121 nil) setnu-before-change-function(13121 13122) kill-region(13121 13122) kill-line(nil) call-interactively(kill-line) BTW, it seems like jde is the wrong place for this file? Wouldn't text-modes or something be more appropriate? -jeff From Adrian.Aichner@t-online.de Sat May 5 13:42:20 2001 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA10282 for ; Sat, 5 May 2001 13:42:19 -0400 Received: from fwd02.sul.t-online.com by mailout01.sul.t-online.com with smtp id 14w64Q-0006Hs-0D; Sat, 05 May 2001 19:42:18 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.64]) by fwd02.sul.t-online.com with esmtp id 14w64e-0JmQ7sC; Sat, 5 May 2001 19:42:32 +0200 To: Jeff Mincy Cc: xemacs-beta@xemacs.org Subject: Re: jde/setnu.el References: <15092.11542.60000.650214@shrdlu.muniversal.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Jeff" == Jeff Mincy writes: Kyle Jones wrote one setnu.el a few years ago. See http://www.wonderworks.com/ It does not appear to be part of XEmacs, though. Steve Youngs may know more about this. Best regards, Adrian Jeff> IN 21.1.13 xemacs, jde/setnu.el. Jeff> I do Jeff> (find-file " Jeff> (require 'setnu) Jeff> (setnu-mode) Jeff> When I try to kill-line, I get the following: Jeff> Signaling: (wrong-type-argument extentp nil) Jeff> setnu-set-extent-property(nil setnu-next-extent #>) Jeff> setnu-extent-at-create(13121 nil) Jeff> setnu-before-change-function(13121 13122) Jeff> kill-region(13121 13122) Jeff> kill-line(nil) Jeff> call-interactively(kill-line) Jeff> BTW, it seems like jde is the wrong place for this file? Jeff> Wouldn't text-modes or something be more appropriate? Jeff> -jeff -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From jmincy@muniversal.com Sat May 5 14:09:23 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA11508 for ; Sat, 5 May 2001 14:09:23 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=shrdlu.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14w6Uc-0003gC-00 ; Sat, 05 May 2001 14:09:22 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15092.16016.630000.397121@shrdlu.muniversal.com> Date: Sat, 5 May 2001 13:55:28 -0400 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: jde/setnu.el In-Reply-To: References: <15092.11542.60000.650214@shrdlu.muniversal.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Adrian Aichner writes: >>>>> "Jeff" == Jeff Mincy writes: Kyle Jones wrote one setnu.el a few years ago. See http://www.wonderworks.com/ It does not appear to be part of XEmacs, though. It's part of jde package. pkginfo/MANIFEST.jde ... lisp/jde/jde-setnu.el lisp/jde/jde-setnu.elc ... lisp/jde/setnu.el lisp/jde/setnu.elc It doesn't have autoloads for setnu-mode. Steve Youngs may know more about this. Best regards, Adrian Jeff> IN 21.1.13 xemacs, jde/setnu.el. Jeff> I do Jeff> (find-file " Jeff> (require 'setnu) Jeff> (setnu-mode) Jeff> When I try to kill-line, I get the following: Jeff> Signaling: (wrong-type-argument extentp nil) Jeff> setnu-set-extent-property(nil setnu-next-extent #>) Jeff> setnu-extent-at-create(13121 nil) Jeff> setnu-before-change-function(13121 13122) Jeff> kill-region(13121 13122) Jeff> kill-line(nil) Jeff> call-interactively(kill-line) Jeff> BTW, it seems like jde is the wrong place for this file? Jeff> Wouldn't text-modes or something be more appropriate? From rendhalver@users.sourceforge.net Sat May 5 14:09:54 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA11526 for ; Sat, 5 May 2001 14:09:52 -0400 Received: from ulthwe.dyndns.org (p497-tnt1.brs.ihug.com.au [203.173.189.243]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id EAA00504; Sun, 6 May 2001 04:09:38 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p497-tnt1.brs.ihug.com.au [203.173.189.243] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15092.16726.63690.956636@ulthwe.dyndns.org> Date: Sun, 6 May 2001 04:07:18 +1000 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: References: <15092.4694.989469.685700@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Adrian Aichner writes: > >>>>> "Peter" == Peter Brown writes: > > Yes, see above. > > Please send us output of > xemacs ... -debug-init i started xemacs with -debug-init it did not spit out anything i ran it from compile directory it usually outputs something to a buffer does it not ?? > You're quite welcome. completely happy to help out > Thanks for your braveness, user number 1! :) cool i like this title gives me a sense of being involved in something rather nifty -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From steve@turnbull.sk.tsukuba.ac.jp Sat May 5 14:12:24 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA11683 for ; Sat, 5 May 2001 14:12:24 -0400 Received: by localhost id m14w6Rt-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Sun, 6 May 2001 03:06:33 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15092.16676.19388.150200@turnbull.sk.tsukuba.ac.jp> Date: Sun, 6 May 2001 03:06:28 +0900 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: rendhalver@users.sourceforge.net, xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: References: <15092.4694.989469.685700@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "APA" == Adrian Aichner writes: >>>>> "Peter" == Peter Brown writes: Peter> Cannot open load file: dired APA> Please send us output of APA> xemacs ... -debug-init And `xemacs -debug-paths'. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From Adrian.Aichner@t-online.de Sat May 5 14:16:31 2001 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA11874 for ; Sat, 5 May 2001 14:16:30 -0400 Received: from fwd02.sul.t-online.com by mailout05.sul.t-online.com with smtp id 14w6bZ-0006FW-00; Sat, 05 May 2001 20:16:33 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.64]) by fwd02.sul.t-online.com with esmtp id 14w6bm-1mTXEWC; Sat, 5 May 2001 20:16:46 +0200 To: rendhalver@users.sourceforge.net Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 References: <15092.4694.989469.685700@ulthwe.dyndns.org> <15092.16726.63690.956636@ulthwe.dyndns.org> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Peter" == Peter Brown writes: Peter> Adrian Aichner writes: >> >>>>> "Peter" == Peter Brown writes: >> >> Yes, see above. >> >> Please send us output of >> xemacs ... -debug-init Peter> i started xemacs with -debug-init Peter> it did not spit out anything Peter> i ran it from compile directory Peter> it usually outputs something to a buffer does it not ?? No, the stdout or stderr. Start XEmacs from a shell window. >> You're quite welcome. Peter> completely happy to help out >> Thanks for your braveness, user number 1! Peter> :) Peter> cool i like this title Peter> gives me a sense of being involved in something rather nifty Peter> -- Peter> ------------------------------------------------------------------------- Peter> Peter Brown Peter> Web Programmer/Sys Admin/Apache Admin Education Development Web Peter> peter@edw.com.au www.edw.com.au Peter> rendhalver@users.sourceforge.net Peter> ------------------------------------------------------------------------- -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From rendhalver@users.sourceforge.net Sat May 5 14:54:43 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA13741 for ; Sat, 5 May 2001 14:54:41 -0400 Received: from ulthwe.dyndns.org (p497-tnt1.brs.ihug.com.au [203.173.189.243]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id EAA30091; Sun, 6 May 2001 04:54:34 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p497-tnt1.brs.ihug.com.au [203.173.189.243] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15092.19426.99706.609676@ulthwe.dyndns.org> Date: Sun, 6 May 2001 04:52:18 +1000 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: References: <15092.4694.989469.685700@ulthwe.dyndns.org> <15092.16726.63690.956636@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Adrian Aichner writes: > >>>>> "Peter" == Peter Brown writes: > > Peter> i started xemacs with -debug-init > > Peter> it did not spit out anything > Peter> i ran it from compile directory > > Peter> it usually outputs something to a buffer does it not ?? > > No, the stdout or stderr. > > Start XEmacs from a shell window. yep did that did not spit out anything to stderr or stdout just thought could it be a problem with my packages tree ?? should i create it again and give it another go could have gotten stuffed up while i was playing with cvs versions of the packages -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From rendhalver@users.sourceforge.net Sat May 5 14:57:48 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA13873 for ; Sat, 5 May 2001 14:57:45 -0400 Received: from ulthwe.dyndns.org (p497-tnt1.brs.ihug.com.au [203.173.189.243]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id EAA30113; Sun, 6 May 2001 04:57:38 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p497-tnt1.brs.ihug.com.au [203.173.189.243] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15092.19608.857582.455140@ulthwe.dyndns.org> Date: Sun, 6 May 2001 04:55:20 +1000 To: "Stephen J. Turnbull" Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: <15092.16676.19388.150200@turnbull.sk.tsukuba.ac.jp> References: <15092.4694.989469.685700@ulthwe.dyndns.org> <15092.16676.19388.150200@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Stephen J. Turnbull writes: > >>>>> "APA" == Adrian Aichner writes: > > >>>>> "Peter" == Peter Brown writes: > > Peter> Cannot open load file: dired > > APA> Please send us output of > APA> xemacs ... -debug-init > > And `xemacs -debug-paths'. ok output from xemacs -debug-init -debug-paths emacs-roots: ("/Hacking/src/xemacs/xemacs-21.5/" "/usr/local/xemacs-beta/") configure-package-path: ("/usr/local/xemacs-beta/lib/xemacs/xemacs-packages") early-packages and early-package-load-path: nil nil late-packages and late-package-load-path: ("/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/") ("/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/Sun/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/ada/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/apel/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/auctex/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/bbdb/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/build/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/c-support/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/calc/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/calendar/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/cc-mode/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/cookie/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/crisp/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/debug/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/dired/" "/usr/local/xemacs-beta/lib/xema! cs/xemacs-packages/lisp/edebug/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/ediff/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/edit-utils/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/edt/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/efs/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/eicq/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/eieio/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/elib/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/emerge/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/epl/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/eshell/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/eterm/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/eudc/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/footnote/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/forms/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/frame! -icon/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/fsf-compat/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/games/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/gnats/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/gnus/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/hm--html-menus/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/idlwave/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/igrep/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/ilisp/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/ispell/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/jde/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/mail-lib/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/mailcrypt/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/mew/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/mh-e/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/mine/" "/usr/! local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/misc-games/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/net-utils/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/os-utils/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/pc/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/pcl-cvs/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/pcomplete/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/prog-modes/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/ps-print-nomule/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/psgml/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/reftex/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/rmail/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/scheme/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/semantic/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/sgml/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/sh-script/"! "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/slider/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/sounds-au/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/sounds-wav/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/speedbar/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/strokes/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/supercite/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/texinfo/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/text-modes/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/textools/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/time/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/tm/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/tooltalk/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/tpu/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/vc/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/vc-cc/" "/usr/l! ocal/xemacs-beta/lib/xemacs/xemacs-packages/lisp/vhdl/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/view-process/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/viper/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/vm/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/w3/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/x-symbol/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/xemacs-base/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/xemacs-devel/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/xslt-process/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/zenirc/") last-packages and last-package-load-path: nil nil lisp-directory: "/Hacking/src/xemacs/xemacs-21.5/lisp/" mule-lisp-directory: "/Hacking/src/xemacs/xemacs-21.5/lisp/mule/" Info-directory-list: ("/Hacking/src/xemacs/xemacs-21.5/info/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/info/" "/usr/local/info" "/usr/info" "/usr/share/info") exec-directory: /Hacking/src/xemacs/xemacs-21.5/lib-src/ exec-path: ("/usr/bin/" "/bin/" "/usr/X11R6/bin/" "/usr/local/bin/" "/opt/bin/" "/usr/X11R6/bin/" "/home/rendhalver/bin/" "/usr/X11R6/bin/" "/home/rendhalver/bin/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lib-src/" "/Hacking/src/xemacs/xemacs-21.5/lib-src/") doc-directory: "/Hacking/src/xemacs/xemacs-21.5/lib-src/" data-directory: "/Hacking/src/xemacs/xemacs-21.5/etc/" data-directory-list: ("/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/auctex/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/bbdb/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/e/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/ediff/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/eicq/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/frame-icon/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/gnats/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/gnus/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/gnusrefcard/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/hm--html-menus/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/idlwave/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/ilisp/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/jde/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/message/" "/usr/local/xemacs-beta/lib/xemacs/! xemacs-packages/etc/mew/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/mine/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/perllib/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/psgml/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/reftex/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/slider/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/smilies/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/sounds/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/time/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/vm/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/w3/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/x-symbol/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/xslt-process/" "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/etc/zenirc/" "/Hacking/src/xemacs/xemacs-21.5/etc/") From youngs@xemacs.org Sat May 5 15:32:23 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA16101 for ; Sat, 5 May 2001 15:32:21 -0400 Received: from slackware.mynet.pc (wdcax13-248.dialup.optusnet.com.au [198.142.220.248]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f45JWD825194 for ; Sun, 6 May 2001 05:32:14 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f45JUo20014896; Sun, 6 May 2001 05:30:50 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: find-function & load-history References: <15091.58000.258819.143117@turnbull.sk.tsukuba.ac.jp> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 06 May 2001 05:30:49 +1000 In-Reply-To: <15091.58000.258819.143117@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Sat, 5 May 2001 20:22:56 +0900") Message-ID: Lines: 15 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "SJT" == Stephen J Turnbull writes: >>>>>>"SY" == Steve Youngs writes: SY> How can I make [find-function] show me [...] the installed SY> version? SJT> (setq find-function-source-path nil) should work. Nope, tried that. It doesn't work, sorry. Any other ideas? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From ben@666.com Sat May 5 19:38:58 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA09349 for ; Sat, 5 May 2001 19:38:57 -0400 Received: (qmail 53948 invoked by alias); 5 May 2001 23:38:56 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 53938 invoked by uid 0); 5 May 2001 23:38:56 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 5 May 2001 23:38:56 -0000 Message-ID: <3AF48F67.8D219FC0@666.com> Date: Sat, 05 May 2001 16:40:23 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: XEmacs Beta List Subject: Re: [bug] kill-line broken in macros References: <3AF09A66.8020D811@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit agreed, but this change is gratuitous at this point. it only mattered at all because of the previous changes, which i also withdrew. also, the macro fixes aren't going into 21.4. Hrvoje Niksic wrote: > > Ben Wing writes: > > > i hereby withdraw my change, and the associated news file entry: > > Hmph. Why? Shouldn't we just fix the macro thing? kill-line is not > the only function that behaves differently depending on whether you > call it interactively. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From rendhalver@users.sourceforge.net Sat May 5 23:34:06 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA20856 for ; Sat, 5 May 2001 23:34:02 -0400 Received: from ulthwe.dyndns.org (p497-tnt1.brs.ihug.com.au [203.173.189.243]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id NAA11694; Sun, 6 May 2001 13:33:55 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p497-tnt1.brs.ihug.com.au [203.173.189.243] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15092.50586.896598.240834@ulthwe.dyndns.org> Date: Sun, 6 May 2001 13:31:38 +1000 To: "Stephen J. Turnbull" Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: <15092.19426.99706.609676@ulthwe.dyndns.org> References: <15092.4694.989469.685700@ulthwe.dyndns.org> <15092.16726.63690.956636@ulthwe.dyndns.org> <15092.19426.99706.609676@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Peter Brown writes: > Adrian Aichner writes: > > >>>>> "Peter" == Peter Brown writes: > just thought could it be a problem with my packages tree ?? > should i create it again and give it another go > could have gotten stuffed up while i was playing with cvs versions of the packages it was my package tree i was playing arround with latest cvs of packages was not really sure what i was doing i must have trashed parts of the package tree unknowingly i keep a separate one for my beta version so i did not notice it was stuffed during use of non-beta version thanks for all your help -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From nk@lamia.lf.net Sun May 6 13:03:47 2001 Received: from lamia.lf.net (lamia.LF.net [212.9.160.192]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA01512 for ; Sun, 6 May 2001 13:03:46 -0400 Received: by lamia.lf.net (Smail3.2.0.111/lamia.lf.net) via LF.net GmbH Internet Services for mail.xemacs.org id m14wRwc-001Sq4C; Sun, 6 May 2001 19:03:42 +0200 (CEST) Sender: nk@lamia.lf.net (Norbert Koch) To: xemacs-beta@xemacs.org Subject: Byte-compiler tests fail Organization: LF.net GmbH X-Attribution: viteno X-NCC-RegID: de.lfnet X-URL: http://www.LF.net/ X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R: lt{Y/s1g[=5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 06 May 2001 19:03:42 +0200 Message-ID: Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi! XEmacs 21.5 (beta0) "alfalfa" [Lucid] (i386-unknown-freebsd4.3, Mule) of Thu May 3 2001 on lamia.LF.net The byte-compiler-test fail at the moment: Testing /usr/local/users/support/nk/cvs/xemacs/tests/automated/byte-compiler-tests.el Unexpected error (void-function defadvice) while executing interpreted code. Test suite execution aborted. Unexpected error (void-variable message) while executing byte-compiled code. Test suite execution aborted. byte-compiler-tests.el: No tests run Test suite execution failed unexpectedly. norbert. From jimdres@mindspring.com Sun May 6 14:17:48 2001 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA04648 for ; Sun, 6 May 2001 14:15:14 -0400 Received: from eeyore.lewismoss.org (user-2ivf1uc.dialup.mindspring.com [165.247.135.204]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA30279 for ; Sun, 6 May 2001 14:15:06 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14wT3L-0000gQ-00 for ; Sun, 06 May 2001 14:14:43 -0400 To: xemacs-beta@xemacs.org Subject: Crash with 21.4.1 From: James LewisMoss X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 06 May 2001 14:14:23 -0400 Message-ID: Lines: 166 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss Here's the backtrace printed to the log file: Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes@xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/bin/xemacs21 core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: dispatch-non-command-events() # (condition-case ... . ((nil))) progress-feedback-dispatch-non-command-events() # bind (tmsg top frame value message label) append-progress-feedback(font-lock "Fontifying test... " 100 nil) # bind (frame value message label) display-progress-feedback(font-lock "Fontifying test... " 100) # bind (str) # (unwind-protect ...) # bind (args value fmt label) progress-feedback-with-label(font-lock "Fontifying %s... " 100 "test") # bind (loudly loudvar end start) font-lock-fontify-keywords-region(1 11452 nil) # (unwind-protect ...) # bind (modified buffer-undo-list inhibit-read-only old-syntax-table buffer-file-name buffer-file-truename loudly end beg) font-lock-default-fontify-region(1 11452 nil) # bind (loudly end beg) font-lock-fontify-region(1 11452) # bind (val end beg) #(1 11452 t) map-range-table(# #s(range-table data ((1 11452) t))) # bind (zmacs-region-stays) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # bind (dummy buffer) # nil font-lock-pending t put-text-property map-range-table #] 9>(# t) maphash(# nil font-lock-pending t put-text-property map-range-table #] 9> #) # (unwind-protect ...) # bind (match-data) font-lock-fontify-pending-extents() byte-code("..." [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2) # (condition-case ... . ((error (warn "Error caught in `font-lock-pre-idle-hook': %s" font-lock-error)))) font-lock-pre-idle-hook() # (condition-case ... . error) # (condition-case ... . error) # (catch top-level ...) The backtrace from the core file isn't so interesting: #0 0x40422801 in ?? () #1 0x40422738 in ?? () #2 0x8172cb6 in RadioUnset () #3 0x4014f905 in ?? () #4 0x4014f5eb in ?? () #5 0x4014f334 in ?? () #6 0x4014fcee in ?? () #7 0x40150058 in ?? () #8 0x4015a970 in ?? () #9 0x8151964 in emacs_Xt_event_handler () #10 0x8151a2e in emacs_Xt_event_handler () #11 0x80cb49f in allocate_command_builder () #12 0x80cd426 in Fdispatch_non_command_events () #13 0x80a85c6 in Feval () #14 0x80a6556 in condition_case_1 () #15 0x80a67df in condition_case_3 () #16 0x808af8d in execute_rare_opcode () #17 0x808a50b in funcall_compiled_function () #18 0x808a37f in funcall_compiled_function () #19 0x80a8bc1 in Ffuncall () #20 0x808a677 in funcall_compiled_function () #21 0x808a37f in funcall_compiled_function () #22 0x80a8bc1 in Ffuncall () ---Type to continue, or q to quit--- #23 0x808a677 in funcall_compiled_function () #24 0x808a37f in funcall_compiled_function () #25 0x80a8bc1 in Ffuncall () #26 0x808a677 in funcall_compiled_function () #27 0x808a37f in funcall_compiled_function () #28 0x80a8bc1 in Ffuncall () #29 0x808a677 in funcall_compiled_function () #30 0x808a37f in funcall_compiled_function () #31 0x80a8bc1 in Ffuncall () #32 0x808a677 in funcall_compiled_function () #33 0x808a37f in funcall_compiled_function () #34 0x80a8bc1 in Ffuncall () #35 0x808a677 in funcall_compiled_function () #36 0x808a37f in funcall_compiled_function () #37 0x80a8bc1 in Ffuncall () #38 0x808a677 in funcall_compiled_function () #39 0x808a37f in funcall_compiled_function () #40 0x80a8bc1 in Ffuncall () #41 0x8122a93 in Fmap_range_table () #42 0x80a8aca in Ffuncall () #43 0x808a677 in funcall_compiled_function () #44 0x808a37f in funcall_compiled_function () #45 0x80a8bc1 in Ffuncall () ---Type to continue, or q to quit--- #46 0x80a1a87 in Fmaphash () #47 0x80a8aca in Ffuncall () #48 0x808a677 in funcall_compiled_function () #49 0x808a37f in funcall_compiled_function () #50 0x80a8bc1 in Ffuncall () #51 0x808a677 in funcall_compiled_function () #52 0x808c8d1 in Fbyte_code () #53 0x80a85f2 in Feval () #54 0x80a6556 in condition_case_1 () #55 0x80a67df in condition_case_3 () #56 0x808af8d in execute_rare_opcode () #57 0x808a50b in funcall_compiled_function () #58 0x808a37f in funcall_compiled_function () #59 0x80a8bc1 in Ffuncall () #60 0x80a93cf in run_hook_with_args_in_buffer () #61 0x80a943e in run_hook_with_args () #62 0x80a919d in Frun_hooks () #63 0x80a9538 in run_hook () #64 0x80a9f11 in eval_in_buffer_trapping_errors () #65 0x80a6556 in condition_case_1 () #66 0x80aa104 in safe_run_hook_trapping_errors () #67 0x80ccda5 in in_single_console_state () #68 0x80cd015 in Fnext_event () ---Type to continue, or q to quit--- #69 0x8091a47 in Fcommand_loop_1 () #70 0x8091905 in Frecursive_edit () #71 0x80a6556 in condition_case_1 () #72 0x8091553 in Freally_early_error_handler () #73 0x8091577 in Freally_early_error_handler () #74 0x80a622c in internal_catch () #75 0x80916ae in initial_command_loop () #76 0x80a32e1 in xemacs_21_4_1_i386_debian_linux () #77 0x80a3a52 in main () #78 0x4041316b in ?? () I'm trying to get a better backtrace. This is with my default setup I'll also try with -vanilla, but figured this might be enough for someone to figure out what is happening. Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From jimdres@mindspring.com Sun May 6 14:49:48 2001 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA06395 for ; Sun, 6 May 2001 14:47:16 -0400 Received: from eeyore.lewismoss.org (user-2ivf1uc.dialup.mindspring.com [165.247.135.204]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id OAA04960 for ; Sun, 6 May 2001 14:47:10 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14wTYN-0000jh-00 for ; Sun, 06 May 2001 14:46:47 -0400 To: xemacs-beta@xemacs.org Subject: Update to last message From: James LewisMoss X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 06 May 2001 14:46:26 -0400 Message-ID: Lines: 326 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: James LewisMoss Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id OAA06395 Here's a better backtrace: #0 0x401a8df0 in XDrawLine () from /usr/X11R6/lib/libX11.so.6 #1 0x8172cb6 in GaugeExpose (w=0x8760cc8, event=0xbfffd95c, region=0x840cc80) at xlwgauge.c:425 #2 0x4014f905 in _XtEventInitialize () from /usr/X11R6/lib/libXt.so.6 #3 0x4014f5eb in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #4 0x4014f334 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #5 0x4014fcee in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 #6 0x40150058 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #7 0x4015a970 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #8 0x8151964 in drain_X_queue () at event-Xt.c:2907 #9 0x8151a2e in emacs_Xt_event_pending_p (user_p=0) at event-Xt.c:3024 #10 0x80cb49f in event_stream_event_pending_p (user=0) at event-stream.c:438 #11 0x80cd426 in Fdispatch_non_command_events () at event-stream.c:2386 #12 0x80a85c6 in Feval (form=138209552) at eval.c:3331 #13 0x80a6556 in condition_case_1 (handlers=138209048, bfun=0x80a817c , barg=138209552, hfun=0x80a65ac , harg=136170236) at eval.c:1651 #14 0x80a67df in condition_case_3 (bodyform=138209552, var=136170236, handlers=138209048) at eval.c:1729 #15 0x808af8d in execute_rare_opcode (stack_ptr=0xbfffdcc0, program_ptr=0x882a8cc "\207", opcode=Bcondition_case) at bytecode.c:1271 #16 0x808a50b in execute_optimized_program (program=0x882a8c8 "ÀÁÂ\217\207", stack_depth=3, constants_data=0x83cb880) at bytecode.c:656 #17 0x808a37f in funcall_compiled_function (fun=138171632, nargs=0, args=0xbfffddcc) at bytecode.c:515 #18 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffddc8) at eval.c:3563 #19 0x808a677 in execute_optimized_program (program=0x84e0d98 "\r¬\004Æ \025\n@\211\031A\036\020\b\t@a«%\t\f¡\210\016\020\fk«\020Ç\016\021È\013#\210ÉÊ\r!!\210ª\aË\f\013\r#\210Ì \210ª\r\b\fB\nB\022Ë\f\013\r#\210Í \210\013Îa­\004Ï\b!*\207ÿÿÿÿ\031", stack_depth=5, constants_data=0x83cb8a0) at bytecode.c:746 #20 0x808a37f in funcall_compiled_function (fun=138171660, nargs=4, args=0xbfffdeec) at bytecode.c:515 #21 0x80a8bc1 in Ffuncall (nargs=5, args=0xbfffdee8) at eval.c:3563 #22 0x808a677 in execute_optimized_program (program=0x84e0d50 "\fÅa«\aÆ\n\t\013#\207ÇÈ\013\"«\004\b«\026É\n\t\fÊa«\004˪\aÌ\fÍ¥Î\"P\013#\207Ï\n\t\f\013$\207\001", stack_depth=6, constants_data=0x83cba98) at bytecode.c:746 #23 0x808a37f in funcall_compiled_function (fun=138171744, nargs=3, args=0xbfffe00c) at bytecode.c:515 #24 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe008) at eval.c:3563 #25 0x808a677 in execute_optimized_program (program=0x8856268 "\212\013¬\f\n¬\tÅÆ\tÅ\"\210ª\017ÇÈ\013\n#\034É\t\f\b#\210\f))\207\b8", stack_depth=4, constants_data=0x83cbb30) at bytecode.c:746 #26 0x808a37f in funcall_compiled_function (fun=138171856, nargs=4, args=0xbfffe12c) at bytecode.c:515 #27 0x80a8bc1 in Ffuncall (nargs=5, args=0xbfffe128) at eval.c:3563 #28 0x808a677 in execute_optimized_program (program=0x84e0878 "\016=­\a\f\rZ\016>Y\0366\016?\036@\016:¢Æa«\005\016:ª\003Ç A\036+È \036;É\211\0361\0367Ê\0363\016+G\0368Ë\211\0369\036.Ë\036)\016+\203q\004\016+@\211\0269@\026.\rb\210`\fW\203Q\004\016.;«\tÌ\016.\fÆ#ª\005\016.\f!\203=\004`\rZÍ_\f\rZ\0168_¥\0163Í_\0168¥\\É\\\0261\0166«\021\0161\0167V«\nÎÏÐ\0161\016;$\210\0161\0267\0169A\211\026)«¯\016)@@§\203Í\001\016)@@\225\034\016)@\211\036,@\211\0360\224\035\0160\225\034Ñ\016,8\036*\016,A@\211\036"..., stack_depth=13, constants_data=0x84e2258) at bytecode.c:746 #29 0x808a37f in funcall_compiled_function (fun=138299276, nargs=3, args=0xbfffe26c) at bytecode.c:515 #30 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe268) at eval.c:3563 #31 0x808a677 in execute_optimized_program (program=0x8771cb8 "Æ Ç\211È É\211\031\030\036\020\036\021\036\022\036\023Ê\216\013«\005Ë\013!\210Ì\r\f\"\210\016\024«\006Í\r\f\"\210\016\025¬\aÎ\r\f\n#\210Ï\r\f\n#.\a\207", stack_depth=6, constants_data=0x84b6670) at bytecode.c:746 #32 0x808a37f in funcall_compiled_function (fun=138298744, nargs=3, args=0xbfffe38c) at bytecode.c:515 #33 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe388) at eval.c:3563 #34 0x808a677 in execute_optimized_program (program=0x880a298 "\013\n\t\b#\207\200\b ", stack_depth=4, constants_data=0x84c1858) at bytecode.c:746 #35 0x808a37f in funcall_compiled_function (fun=138298632, nargs=2, args=0xbfffe4ac) at bytecode.c:515 #36 0x80a8bc1 in Ffuncall (nargs=3, args=0xbfffe4a8) at eval.c:3563 #37 0x808a677 in execute_optimized_program (program=0x880a110 "Â\t\b\"\207¢\200\b ", stack_depth=3, constants_data=0x84b94d8) at bytecode.c:746 #38 0x808a37f in funcall_compiled_function (fun=138298884, nargs=3, args=0xbfffe5e0) at bytecode.c:515 #39 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe5dc) at eval.c:3563 #40 0x8122a93 in Fmap_range_table (function=138298884, range_table=139159952) at rangetab.c:480 #41 0x80a8aca in Ffuncall (nargs=3, args=0xbfffe678) at eval.c:3528 #42 0x808a677 in execute_optimized_program (program=0x8771c08 "Ä\013\b\"\210Å\013!­'Æ\n!\210r\013q\210\212\214~\210\t\031ÇÈÉ\211\211\211\211ÊË&\b\210ÌedÊÉ$\210ÍÎ\n\",\207", stack_depth=9, constants_data=0x84b91d8) at bytecode.c:746 #43 0x808a37f in funcall_compiled_function (fun=138298912, nargs=2, args=0xbfffe7c4) at bytecode.c:515 #44 0x80a8bc1 in Ffuncall (nargs=3, args=0xbfffe7c0) at eval.c:3563 #45 0x80a1a87 in Fmaphash (function=138298912, hash_table=139171896) at elhash.c:1195 #46 0x80a8aca in Ffuncall (nargs=3, args=0xbfffe858) at eval.c:3528 #47 0x808a677 in execute_optimized_program (program=0x8809f88 " \031Ã\216ÄÅ\b\"*\207", stack_depth=3, constants_data=0x84b9928) at bytecode.c:746 #48 0x808a37f in funcall_compiled_function (fun=138298940, nargs=0, args=0xbfffe96c) at bytecode.c:515 #49 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffe968) at eval.c:3563 #50 0x808a677 in execute_optimized_program (program=0xbfffe9b4 "Á\b!ÂV­\003à \207", stack_depth=2, constants_data=0x84bb598) at bytecode.c:746 #51 0x808c8d1 in Fbyte_code (instructions=139621028, constants=139179400, stack_depth=5) at bytecode.c:2403 #52 0x80a85f2 in Feval (form=138707952) at eval.c:3331 #53 0x80a6556 in condition_case_1 (handlers=138715660, bfun=0x80a817c , barg=138707952, hfun=0x80a65ac , harg=139536332) at eval.c:1651 #54 0x80a67df in condition_case_3 (bodyform=138707952, var=139536332, handlers=138715660) at eval.c:1729 #55 0x808af8d in execute_rare_opcode (stack_ptr=0xbfffec80, program_ptr=0x8809e04 "\207\237\200\b ", opcode=Bcondition_case) at bytecode.c:1271 #56 0x808a50b in execute_optimized_program (program=0x8809e00 "ÀÁÂ\217\207\237\200\b ", stack_depth=3, constants_data=0x84b9578) at bytecode.c:656 #57 0x808a37f in funcall_compiled_function (fun=138298800, nargs=0, args=0xbfffee48) at bytecode.c:515 #58 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffee44) at eval.c:3563 #59 0x80a93cf in run_hook_with_args_in_buffer (buf=0x8854f78, nargs=1, args=0xbfffee44, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4020 #60 0x80a943e in run_hook_with_args (nargs=1, args=0xbfffee44, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4033 #61 0x80a919d in Frun_hooks (nargs=1, args=0xbfffee44) at eval.c:3887 #62 0x80a9538 in run_hook (hook=139535876) at eval.c:4134 #63 0x80a9f11 in catch_them_squirmers_run_hook (hook_symbol=136270164) at eval.c:4578 #64 0x80a6556 in condition_case_1 (handlers=136170308, bfun=0x80a9f00 , barg=136270164, hfun=0x80a9d8c , harg=140204160) at eval.c:1651 #65 0x80aa104 in safe_run_hook_trapping_errors (warning_string=0x8187a80 "Error in `pre-idle-hook' (setting hook to nil)", hook_symbol=136270164, allow_quit=1) at eval.c:4639 #66 0x80ccda5 in run_pre_idle_hook () at event-stream.c:2004 #67 0x80cd015 in Fnext_event (event=142729332, prompt=136170212) at event-stream.c:2176 #68 0x8091a47 in Fcommand_loop_1 () at cmdloop.c:574 #69 0x8091905 in command_loop_1 (dummy=136170212) at cmdloop.c:494 #70 0x80a6556 in condition_case_1 (handlers=136170308, bfun=0x80918ec , barg=136170212, hfun=0x8091460 , harg=136170212) at eval.c:1651 #71 0x8091553 in command_loop_3 () at cmdloop.c:256 #72 0x8091577 in command_loop_2 (dummy=136170212) at cmdloop.c:267 #73 0x80a622c in internal_catch (tag=136246308, func=0x809156c , arg=136170212, threw=0x0) at eval.c:1317 #74 0x80916ae in initial_command_loop (load_me=136170212) at cmdloop.c:305 #75 0x80a32e1 in xemacs_21_4_1_i386_debian_linux () at emacs.c:2344 #76 0x80a3a52 in main () at emacs.c:2773 #77 0x4041316b in __libc_start_main () from /lib/libc.so.6 With what looks like the same lisp backtrace: dispatch-non-command-events() # (condition-case ... . ((nil))) progress-feedback-dispatch-non-command-events() # bind (tmsg top frame value message label) append-progress-feedback(font-lock "Fontifying test... " 100 nil) # bind (frame value message label) display-progress-feedback(font-lock "Fontifying test... " 100) # bind (str) # (unwind-protect ...) # bind (args value fmt label) progress-feedback-with-label(font-lock "Fontifying %s... " 100 "test") # bind (loudly loudvar end start) font-lock-fontify-keywords-region(1 11452 nil) # (unwind-protect ...) # bind (modified buffer-undo-list inhibit-read-only old-syntax-table buffer-file-name buffer-file-truename loudly end beg) font-lock-default-fontify-region(1 11452 nil) # bind (loudly end beg) font-lock-fontify-region(1 11452) # bind (val end beg) #(1 11452 t) map-range-table(# #s(range-table data ((1 11452) t))) # bind (zmacs-region-stays) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # bind (dummy buffer) # nil font-lock-pending t put-text-property map-range-table #] 9>(# t) maphash(# nil font-lock-pending t put-text-property map-range-table #] 9> #) # (unwind-protect ...) # bind (match-data) font-lock-fontify-pending-extents() byte-code("..." [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2) # (condition-case ... . ((error (warn "Error caught in `font-lock-pre-idle-hook': %s" font-lock-error)))) font-lock-pre-idle-hook() # (condition-case ... . error) # (condition-case ... . error) # (catch top-level ...) Haven't been able to reproduce with -vanilla yet. After loading my custom.el I am getting lots of X errors like this: xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0xd Serial number of failed request: 31453 Current serial number in output stream: 31471 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 66 (X_PolySegment) Resource id in failed request: 0xd Serial number of failed request: 31454 Current serial number in output stream: 31471 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 66 (X_PolySegment) Resource id in failed request: 0xd Serial number of failed request: 31499 Current serial number in output stream: 31502 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0xd Serial number of failed request: 31500 Current serial number in output stream: 31502 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 66 (X_PolySegment) Resource id in failed request: 0xd Serial number of failed request: 31501 Current serial number in output stream: 31502 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 66 (X_PolySegment) Resource id in failed request: 0xd Serial number of failed request: 31557 Current serial number in output stream: 31560 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0xd Serial number of failed request: 31558 Current serial number in output stream: 31560 xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) Major opcode of failed request: 66 (X_PolySegment) Resource id in failed request: 0xd Serial number of failed request: 31559 Current serial number in output stream: 31560 OK. Got a repeat with -vanilla loading the following: (custom-set-variables '(w3-user-fonts-take-precedence t) '(gnus-junk-complaint-text " Hello, James LewisMoss -- @James LewisMoss | dres@debian.org | Blessed Be! @ http://www.lewismoss.com/~dres | Linux is cool! @\"Argue for your limitations and sure enough, they're yours.\" Bach ") '(irchat-want-traditional t) '(message-generate-headers-first t) '(gnus-junk-original-seperator " --------------------original--message--follows-------------------- ") '(toolbar-news-use-separate-frame t) '(wwi-auto-install-on-startup-flag t nil (where-was-i-db)) '(gnuserv-program (concat exec-directory "/gnuserv")) '(change-log-default-name "ChangeLog") '(icomplete-mode t nil (icomplete)) '(message-default-charset (quote us-ascii)) '(browse-url-browser-function (quote browse-url-netscape)) '(minibuf-frame-pos-y -2) '(minibuf-frame-pos-x 0) '(message-deletable-headers (quote (Message-ID Date Lines Sender))) '(toolbar-news-reader (quote gnus)) '(w3-user-colors-take-precedence t) '(gnus-uu-user-view-rules (quote (("\"\\\\.\\\\(jpe?g\\\\|gif\\\\|tiff?\\\\|p[pgb]m\\\\|xwd\\\\|xbm\\\\|pcx\\\\)$" "eeyes")))) '(toolbar-visible-p nil) '(nnmail-spool-file "/var/spool/mail/$user") '(jde-mode-abbreviations (quote (("ab" "abstract") ("bo" "boolean") ("br" "break") ("by" "byte") ("byv" "byvalue") ("cas" "cast") ("ca" "catch") ("ch" "char") ("cl" "class") ("co" "const") ("con" "continue") ("de" "default") ("dou" "double") ("el" "else") ("ex" "extends") ("fa" "false") ("fi" "final") ("fin" "finally") ("fl" "float") ("fo" "for") ("fu" "future") ("ge" "generic") ("go" "goto") ("impl" "implements") ("impo" "import") ("ins" "instanceof") ("in" "int") ("inte" "interface") ("lo" "long") ("na" "native") ("ne" "new") ("nu" "null") ("pa" "package") ("pri" "private") ("pro" "protected") ("pu" "public") ("re" "return") ("sh" "short") ("St" "String") ("st" "static") ("su" "super") ("sw" "switch") ("sy" "synchronized") ("th" "this") ("thr" "throw") ("throw" "throws") ("tra" "transient") ("tr" "true") ("vo" "void") ("vol" "volatile") ("wh" "while")))) '(Info-button1-follows-hyperlink t) '(frame-background-mode (quote dark)) '(gnus-check-bogus-newsgroups t) '(completion-ignored-extensions (quote (".Sym" ".Lib" ".beam" ".vee" ".jam" ".o" ".elc" "~" ".bin" ".lbin" ".fasl" ".dvi" ".toc" ".log" ".aux" ".a" ".ln" ".lof" ".blg" ".bbl" ".glo" ".idx" ".lot" ".fmt" ".oi" ".class"))) '(gnus-junk-include-body t) '(user-mail-address "jimdres@mindspring.com") '(query-user-mail-address nil)) (custom-set-faces '(info-xref ((t (:bold t :foreground "sienna1")))) '(pointer ((t (:foreground "purple1" :background "blue"))) t) '(info-node ((t (:bold t :foreground "dodgerblue1")))) '(secondary-selection ((t (:foreground "green1"))) t) '(eif-string ((t (:bold nil :foreground "tomato"))) t) '(html-helper-italic-face ((t (:italic t :family "lucida"))) t) '(widget-field-face ((((class grayscale color) (background light)) (:foreground "black" :background "gray85")))) '(gnus-header-subject-face ((((class color) (background dark)) (:bold t :italic t :foreground "pink" :family "lucida")))) '(gnus-header-from-face ((((class color) (background dark)) (:bold t :italic t :foreground "light blue" :family "lucida")))) '(font-lock-string-face ((t (:bold nil :foreground "yellowgreen")))) '(eif-comment ((t (:bold nil :foreground "hot pink"))) t) '(dired-face-permissions ((t (:foreground "red" :background "grey85")))) '(xrdb-option-name-face ((t (:bold nil :foreground "red1"))) t) '(font-lock-reference-face ((t (:foreground "gold")))) '(comint-input-face ((((class color) (background light)) (:foreground "sky blue")))) '(gnus-group-news-low-empty-face ((((class color)) (:foreground "DarkTurquoise")) (((class color) (background light)) (:foreground "DarkGreen")) (t nil))) '(dired-face-setuid ((((class color)) (:foreground "yellow")) (t (:bold t)))) '(shell-prompt-face ((t (:foreground "antique white" :background "dark green"))) t) '(widget-documentation-face ((((class color) (background light)) (:bold nil :foreground "orchid1")))) '(gnus-header-newsgroups-face ((((class color) (background dark)) (:bold t :italic t :foreground "yellow" :family "lucida")))) '(gnus-emphasis-underline-italic ((t (:italic t :underline t :family "lucida")))) '(custom-group-tag-face ((((class color) (background light)) (:underline t :foreground "sky blue")))) '(custom-variable-tag-face ((((class color) (background light)) (:underline t :foreground "light blue")))) '(message-header-subject-face ((((class color) (background dark)) (:foreground "pink")) (((class color) (background light)) (:bold t :foreground "navy blue")) (t (:bold t)))) '(eif-assertion ((t (:bold t :foreground "light blue" :size "10"))) t) '(gnus-summary-low-unread-face ((t (:italic t :family "lucidatypewriter")))) '(font-lock-doc-string-face ((t (:foreground "green")))) '(gnus-summary-low-ticked-face ((((class color) (background dark)) (:italic t :foreground "pink" :family "lucidatypewriter")))) '(modeline-buffer-id ((t (:foreground "blue4" :background "grey80"))) t) '(font-lock-preprocessor-face ((t (:foreground "black" :background "pink")))) '(modeline-mousable ((t (:foreground "firebrick" :background "grey80"))) t) '(gnus-group-news-3-face ((t (:bold t :foreground "steelblue1")))) '(font-lock-variable-name-face ((t (:foreground "navajowhite2")))) '(gnus-group-news-3-empty-face ((t (:foreground "steelblue2")))) '(hyper-apropos-hyperlink ((((class color) (background light)) (:foreground "light blue")))) '(gnus-header-content-face ((t (:italic t :foreground "lawngreen" :family "lucida")))) '(custom-state-face ((((class color) (background light)) (:foreground "light green")))) '(font-lock-other-emphasized-face ((t (:foreground "green" :background "dark blue"))) t) '(font-lock-keyword-face ((((class color) (background light dark)) (:bold nil :foreground "pink")))) '(message-cited-text-face ((((class color) (background dark)) (:foreground "LightBlue")) (((class color) (background light)) (:foreground "red")) (t (:bold t)))) '(documentation ((t (:bold nil :foreground "light pink"))) t) '(eif-hidden-comment ((t (:bold nil :foreground "light green"))) t) '(gnus-signature-face ((((type x)) (:italic t :family "lucidatypewriter")))) '(gnus-emphasis-underline-bold-italic ((t (:bold t :italic t :underline t :family "lucida")))) '(font-lock-type-face ((t (:foreground "light pink")))) '(gnus-group-mail-low-empty-face ((((class color) (background dark)) (:foreground "paleturquoise2")) (((class color) (background light)) (:foreground "DeepPink4")) (t (:bold t)))) '(bold-italic ((t (:italic t :family "lucida"))) t) '(w3-table-hack-x-face ((t (:family "lucidatypewriter" :size "10"))) t) '(gnus-header-name-face ((((class color) (background dark)) (:foreground "cyan")) (((class color) (background light)) (:foreground "maroon")) (t (:bold t)))) '(font-lock-emphasized-face ((t (:foreground "blue" :background "lightyellow2" :size "nil"))) t) '(widget-inactive-face ((((class grayscale color) (background light)) (:foreground "light pink")))) '(blue ((t (:foreground "lightskyblue"))) t) '(gnus-group-mail-low-face ((((class color) (background dark)) (:bold t :foreground "aquamarine2")) (((class color) (background light)) (:bold t :foreground "DeepPink4")) (t (:bold t)))) '(message-header-cc-face ((((class color) (background dark)) (:bold t :foreground "light blue")) (((class color) (background light)) (:foreground "MidnightBlue")) (t (:bold t)))) '(message-header-other-face ((((class color) (background dark)) (:foreground "gray")) (((class color) (background light)) (:foreground "steel blue")) (t (:bold t :italic t)))) '(message-header-newsgroups-face ((((class color) (background dark)) (:bold t :italic t :foreground "yellow" :family "lucidatypewriter")))) '(message-separator-face ((((class color) (background dark)) (:foreground "red")) (((class color) (background light)) (:foreground "brown")) (t (:bold t)))) '(list-mode-item-selected ((t (:background "blue"))) t) '(message-header-contents ((t (:italic t :family "lucidatypewriter")))) '(hyper-apropos-documentation ((((class color) (background light)) (:foreground "lightpink")))) '(italic ((t (:italic t :family "lucida"))) t) '(gnus-summary-low-ancient-face ((((class color) (background dark)) (:italic t :foreground "SkyBlue" :family "lucidatypewriter")))) '(font-lock-comment-face ((t (:foreground "orchid1")))) '(dired-face-executable ((((class color)) (:foreground "yellow")) (t (:bold t)))) '(message-header-name-face ((((class color) (background dark)) (:foreground "cyan")) (((class color) (background light)) (:foreground "cornflower blue")) (t (:bold t)))) '(gnus-emphasis-italic ((t (:italic t :family "lucida")))) '(font-lock-function-name-face ((t (:foreground "lightskyblue")))) '(message-header-xheader-face ((((class color) (background dark)) (:foreground "lightblue")))) '(isearch ((t (:foreground "black" :background "lightblue"))) t) '(gnus-emphasis-bold-italic ((t (:bold t :italic t :family "lucida")))) '(hyperlink ((t (:bold t :foreground "mediumpurple1"))) t) '(message-header-to-face ((((class color) (background dark)) (:bold t :foreground "LightBlue")) (((class color) (background light)) (:bold t :foreground "MidnightBlue")) (t (:bold t :italic t)))) '(zmacs-region ((t (:bold t :foreground "black" :background "pink" :family "lucidatypewriter"))) t) '(gnus-summary-low-read-face ((((class color) (background dark)) (:italic t :foreground "PaleGreen" :family "lucidatypewriter")))) '(message-highlighted-header-contents ((t (:bold t :italic t :family "lucidatypewriter")))) '(dired-face-marked ((((class color)) (:foreground "black" :background "PaleVioletRed")) (t (:underline t))))) and (require 'dired) (setq dired-listing-switches "-laF") (setq list-directory-brief-switches "-FC") (setq-default dired-omit-files-p nil) (setq dired-do-permission-highlighting-too t) (add-hook 'dired-mode-hook 'turn-on-font-lock) (define-key dired-mode-map [r] 'dired-advertised-find-file) (define-key dired-mode-map [(control c) (control c)] 'compile) (setq dired-re-raw-boring (concat ".\\(\\.class\\|\\.oi\\|\\.fmt\\|\\.ln\\|" "\\.a\\|\\.fasl\\|\\.lbin\\|\\.bin\\|\\.elc\\|" "\\.o\\|\\.lo\\|\\.jam\\|\\.vee\\|\\.beam\\|" "\\.Lib\\|\\.Sym\\|~\\|\\.orig\\|\\.rej\\|" "\\.vrs\\|\\.vr\\|\\.tps\\|\\.tp\\|\\.pgs\\|" "\\.pg\\|\\.kys\\|\\.ky\\|\\.fns\\|\\.fn\\|" "\\.cps\\|\\.cp\\|\\.bbl\\|\\.blg\\|\\.glo\\|" "\\.lot\\|\\.lof\\|\\.idx\\|\\.dvi\\|\\.aux\\|" "\\.log\\|\\.toc\\)" "\\'\\|\\`#\\|\\`\\.")) This is opening a particular directory (test) which contains a bunch of junk that I was playing with at one point or another. File list if anyone thinks it'll help. Different issue: Startup time is very long now (in comparison to 21.1.14). Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From alexm@hsys.msk.ru Sun May 6 16:49:10 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA12277 for ; Sun, 6 May 2001 16:49:04 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp132-184.dialup.mtu-net.ru [62.118.132.184]) by mtu.ru (Postfix) with ESMTP id 2ADBB735B for ; Mon, 7 May 2001 00:49:02 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 32610 invoked by uid 1000); 6 May 2001 20:33:15 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15093.46347.584197.171783@gargle.gargle.HOWL> Date: Mon, 7 May 2001 00:33:15 +0400 (MSD) To: Ben Wing Cc: xemacs-beta@xemacs.org Subject: Re: some MULE inconsistencies [with patch] In-Reply-To: <3AF493A2.8C066C71@666.com> References: <15073.32494.95897.42125@gargle.gargle.HOWL> <3AE7D55C.5C4A79BC@666.com> <15088.25178.522083.941106@gargle.gargle.HOWL> <15088.37624.226068.337634@gargle.gargle.HOWL> <3AF0A434.1E633C4A@666.com> <15090.16014.342472.30646@turnbull.sk.tsukuba.ac.jp> <15090.17595.467147.953428@gargle.gargle.HOWL> <15090.25505.706248.891769@turnbull.sk.tsukuba.ac.jp> <3AF34438.F6C56351@666.com> <15091.65388.746603.917972@gargle.gargle.HOWL> <15092.321.925828.134392@gargle.gargle.HOWL> <3AF493A2.8C066C71@666.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "BW" == Ben Wing writes: >> There is a tiny issue which could be considered an academic bug in >> redisplay code: (set-charset-ccl-program) does not redraw >> characters in specified encoding :) BW> try adding this line: face_property_was_changed (Vdefault_face, BW> Qfont, Qglobal); BW> to set-charset-ccl-program and see if it helps. Works. I've added it after XCHARSET_CCL_PROGRAM, sure. Thank you, --alexm From alexm@hsys.msk.ru Sun May 6 17:20:50 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA14373 for ; Sun, 6 May 2001 17:20:45 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.5) with ESMTP id 7724116 for xemacs-beta@xemacs.org; Sun, 06 May 2001 18:20:36 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp135-89.dialup.mtu-net.ru [62.118.135.89]) by mtu.ru (Postfix) with ESMTP id C10EB7332 for ; Mon, 7 May 2001 01:20:40 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 32711 invoked by uid 1000); 6 May 2001 21:01:23 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15093.48035.897197.951054@gargle.gargle.HOWL> Date: Mon, 7 May 2001 01:01:23 +0400 (MSD) To: Ben Wing Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: some MULE inconsistencies [with patch] In-Reply-To: <3AF4917D.7D82D6F4@666.com> References: <15073.32494.95897.42125@gargle.gargle.HOWL> <3AE7D55C.5C4A79BC@666.com> <15088.25178.522083.941106@gargle.gargle.HOWL> <15088.37624.226068.337634@gargle.gargle.HOWL> <3AF0A434.1E633C4A@666.com> <15090.16014.342472.30646@turnbull.sk.tsukuba.ac.jp> <15090.17595.467147.953428@gargle.gargle.HOWL> <15090.25505.706248.891769@turnbull.sk.tsukuba.ac.jp> <3AF34438.F6C56351@666.com> <15091.65388.746603.917972@gargle.gargle.HOWL> <3AF4917D.7D82D6F4@666.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "BW" == Ben Wing writes: BW> alexey, can you create a patch with all of your changes? it seems BW> to me that anyone who does (set-language-environment BW> 'Cyrillic-KOI8) probably wants the other settings too? either BW> that should happen by default when you change your language BW> env. or it should happen when you call BW> `setup-cyrillic-koi8-environment', defined in cyril-util.el. Currently it seems like `setup-cyrillic-koi8-environment' is appropriate place (I am not sure if adding more properties to language-environment (font registry and ccl-program) is more convenient). It needs to be documented. I'll try to write something tomorrow and maybe discuss the issue in some local newsgroup, but for now it seems to me like (defun setup-cyrillic-koi8-environment () "Setup multilingual environment (MULE) for Cyrillic KOI8 users." (interactive) (set-language-environment "Cyrillic-KOI8") (set-charset-registry 'cyrillic-iso8859-5 "koi8-r") (set-charset-registry 'ascii "koi8-r") (set-charset-ccl-program 'cyrillic-iso8859-5 'ccl-encode-koi8-r-font)) is enough. (Yes, it should be really "koi8-r" as standard cyrillic fonts from XFree use that registry. "koi8-1" is just issue of my particular machine). Sorry, no patch for that, as it's only matter of cut-and-paste. Hope it helps :) I think that I'll convince someone who uses other kinds of cyrillic environments (I know of several people using cyrillic-1251, not sure is there anyone working with cp866 (alternativnyj)) to contribute changes needed for them. Please, notify me if any of my patches will appear in main XEmacs, so that I'll not be drowned with my local changes (I haven't imported it into CVS yet). This one is still valid: >> Hope this one to appear in 21.4.2: >> >> --- orig/xemacs-21.4.0/lisp/mule/cyrillic.el Thu Apr 12 22:21:44 >> 2001 +++ xemacs-21.4.0/lisp/mule/cyrillic.el Sat May 5 17:06:06 >> 2001 @@ -137,11 +137,11 @@ ;; `iso-8-1' is not correct, but XEmacs >> doesn't have a `ccl' category (coding-system-put 'koi8-r 'category >> 'iso-8-1) >> >> -;; (define-ccl-program ccl-encode-koi8-font -;; `(0 -;; ((r1 |= >> 128) -;; (r1 = r1 ,cyrillic-koi8-r-encode-table))) -;; "CCL program >> to encode Cyrillic chars to KOI font.") +(define-ccl-program >> ccl-encode-koi8-r-font + `(0 + ((r1 |= 128) + (r1 = r1 >> ,cyrillic-koi8-r-encode-table))) + "CCL program to encode Cyrillic >> chars to koi8-r font.") >> >> ;; (setq font-ccl-encoder-alist ;; (cons (cons "koi8" >> ccl-encode-koi8-font) font-ccl-encoder-alist)) >> Thanks, --alexm From alexm@hsys.msk.ru Sun May 6 17:28:34 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA14827 for ; Sun, 6 May 2001 17:28:33 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp139-2.dialup.mtu-net.ru [62.118.139.2]) by mtu.ru (Postfix) with ESMTP id 323E37345 for ; Mon, 7 May 2001 01:28:29 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 383 invoked by uid 1000); 6 May 2001 21:26:11 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15093.49523.736978.443168@gargle.gargle.HOWL> Date: Mon, 7 May 2001 01:26:11 +0400 (MSD) To: xemacs-beta@xemacs.org Cc: xemacs-patches@xemacs.org Mail-Followup-To: xemacs-beta@xemacs.org Subject: [PATCH] fix for (list-coding-systems) from mule-diag.el X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Salam, I've fixed `list-coding-systems', both with C-u (it simply works now ;) and without it (it now lists only base coding systems, as per documentation). It was broken because interface of appropriate functions changed heavily. It was necessary to change record separator from colon to semicolon because some coding systems have colons in their names. Hope it will go into base XEmacs (notify me in that case, please :) --- mule-diag.el 2001/05/04 06:46:35 1.1 +++ mule-diag.el 2001/05/06 21:18:05 @@ -390,68 +390,69 @@ ;; Print detailed information on CODING-SYSTEM. (defun print-coding-system (coding-system) - (let ((type (coding-system-type coding-system)) - (eol-type (coding-system-eol-type coding-system)) - (flags (coding-system-flags coding-system)) - (aliases (coding-system-get coding-system 'alias-coding-systems))) - (if (not (eq (car aliases) coding-system)) - (princ (format "%s (alias of %s)\n" coding-system (car aliases))) - (princ coding-system) - (setq aliases (cdr aliases)) - (while aliases - (princ ",") - (princ (car aliases)) - (setq aliases (cdr aliases))) - (princ (format ":%s:%c:%d:" + (princ coding-system) + (if (coding-system-alias-p coding-system) + (princ (format " (alias of %s)\n" (coding-system-aliasee coding-system))) + (let ((type (coding-system-type coding-system)) + (eol-type (coding-system-eol-type coding-system))) + (princ (format ";%s;%s;%s;" type (coding-system-mnemonic coding-system) - (if (integerp eol-type) eol-type 3))) - (cond ((eq type 2) ; ISO-2022 - (let ((idx 0) - charset) - (while (< idx 4) - (setq charset (aref flags idx)) - (cond ((null charset) - (princ -1)) - ((eq charset t) - (princ -2)) - ((charsetp charset) - (princ charset)) - ((listp charset) - (princ "(") - (princ (car charset)) - (setq charset (cdr charset)) - (while charset - (princ ",") - (princ (car charset)) - (setq charset (cdr charset))) - (princ ")"))) - (princ ",") - (setq idx (1+ idx))) - (while (< idx 12) - (princ (if (aref flags idx) 1 0)) - (princ ",") - (setq idx (1+ idx))) - (princ (if (aref flags idx) 1 0)))) - ((eq type 4) ; CCL - (let (i len) - (if (symbolp (car flags)) - (princ (format " %s" (car flags))) - (setq i 0 len (length (car flags))) - (while (< i len) - (princ (format " %x" (aref (car flags) i))) - (setq i (1+ i)))) - (princ ",") - (if (symbolp (cdr flags)) - (princ (format "%s" (cdr flags))) - (setq i 0 len (length (cdr flags))) - (while (< i len) - (princ (format " %x" (aref (cdr flags) i))) - (setq i (1+ i)))))) - (t (princ 0))) - (princ ":") + (symbol-name eol-type))) + (let ((flags '())) + (cond ((eq type 'iso2022) ; ISO-2022 + ;; G0, G1, G2, G3 + ;; probably this should be implemented with (defmacro)? + (mapcar* + (lambda (GX charset force-charset) + (let ((charset-name (coding-system-get coding-system (intern charset)))) + (if charset-name + (let (flag) + (if (coding-system-property coding-system (intern force-charset)) + (setq flag (concat GX ":[" (symbol-name charset-name) "]")) + (setq flag (concat GX ":" (symbol-name charset-name)))) + (setq flags (append (list flag) flags)))))) + + '("G0" "G1" "G2" "G3") + '("charset-g0" "charset-g1" "charset-g2" "charset-g3") + '("force-g0-on-output" "force-g1-on-output" + "force-g2-on-output" "force-g3-on-output")) + + ;; various other flags + (if (coding-system-get coding-system 'short) + (setq flags (append '("SHORT-FORM") flags))) + + (unless (coding-system-get coding-system 'no-ascii-eol) + (setq flags (append '("ASCII-EOL") flags))) + + (unless (coding-system-get coding-system 'no-ascii-cntl) + (setq flags (append '("ASCII-CNTL") flags))) + + (if (coding-system-get coding-system 'seven) + (setq flags (append '("SEVEN") flags))) + + (if (coding-system-get coding-system 'lock-shift) + (setq flags (append '("LOCKING-SHIFT") flags))) + + (if (coding-system-get coding-system 'no-iso6429) + (setq flags (append '("NO-ISO6429") flags)))) + + ((eq type 'ccl) ; CCL + (princ (format "%s, %s" + (coding-system-get coding-system 'encode) + (coding-system-get coding-system 'decode) flags)))) + (setq flags (reverse flags)) + (if (car flags) + (progn + (princ (format "%s" (car flags))) + (mapc + (lambda (flag) + (princ (format ", %s" flag))) + (cdr flags)))) + )) + (princ ";") (princ (coding-system-doc-string coding-system)) - (princ "\n")))) + (princ "\n"))) ;;;###autoload (defun list-coding-systems (&optional arg) @@ -480,35 +481,49 @@ ## LIST OF CODING SYSTEMS ## Each line corresponds to one coding system ## Format of a line is: -## NAME[,ALIAS...]:TYPE:MNEMONIC:EOL:FLAGS:POST-READ-CONVERSION -## :PRE-WRITE-CONVERSION:DOC-STRING, +## NAME[,ALIAS...];TYPE;MNEMONIC;EOL;FLAGS;POST-READ-CONVERSION +## ;PRE-WRITE-CONVERSION;DOC-STRING, ## where ## NAME = coding system name ## ALIAS = alias of the coding system ## TYPE = nil (no conversion), t (undecided or automatic detection), ## 0 (EMACS-MULE), 1 (SJIS), 2 (ISO2022), 3 (BIG5), or 4 (CCL) -## EOL = 0 (LF), 1 (CRLF), 2 (CR), or 3 (Automatic detection) +## EOL = lf (LF), crlf (CRLF), cr (CR), or nil (Automatic detection) ## FLAGS = -## if TYPE = 2 then +## if TYPE = 'ISO2022 then ## comma (`,') separated data of the followings: ## G0, G1, G2, G3, SHORT-FORM, ASCII-EOL, ASCII-CNTL, SEVEN, -## LOCKING-SHIFT, SINGLE-SHIFT, USE-ROMAN, USE-OLDJIS, NO-ISO6429 -## else if TYPE = 4 then +## LOCKING-SHIFT, NO-ISO6429 +## else if TYPE = 'CCL then ## comma (`,') separated CCL programs for read and write ## else ## 0 ## POST-READ-CONVERSION, PRE-WRITE-CONVERSION = function name to be called ## ")) - (let ((bases (coding-system-list)) - ;;(coding-system-list 'base-only)) - coding-system) - (while bases - (setq coding-system (car bases)) - (if (null arg) - (print-coding-system-briefly coding-system 'doc-string) + (if (null arg) + ;; print only base coding systems (w/o "-dos", "-unix", "-mac") + (let ((bases (make-hash-table))) + ;; put base coding systems into hash-table + (mapc + (lambda (coding-system) + (let* ((base (coding-system-base coding-system)) + (base-name (coding-system-name base))) + + (unless (gethash base-name bases) + (puthash base-name base bases)))) + (coding-system-list)) + + ;; traverse hash-table and print each coding system + (maphash + (lambda (key value) (print-coding-system-briefly value 'doc-string)) + bases)) + + ;; print all coding systems in details + (mapc + '(lambda (coding-system) (print-coding-system coding-system)) - (setq bases (cdr bases))))) + (coding-system-list)))) ;;;###autoload (defun list-coding-categories () --alexm From ben@666.com Sun May 6 20:27:04 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id UAA25260 for ; Sun, 6 May 2001 20:27:03 -0400 Received: (qmail 75799 invoked by alias); 7 May 2001 00:26:58 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 75757 invoked by uid 0); 7 May 2001 00:26:57 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 7 May 2001 00:26:57 -0000 Message-ID: <3AF5EC2A.D0063822@666.com> Date: Sun, 06 May 2001 17:28:26 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James LewisMoss CC: xemacs-beta@xemacs.org, Andy Piper Subject: Re: Update to last message References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit thanks. this looks like andy's area of expertise. but if you can reproduce this, try running under a debugger, and printing out the values of the variables in the call to XDrawLine in lwlib/xlwgauge.c that's causing the crash. as for the X errors, set a breakpoint on x_error_handler and see what's causing them. James LewisMoss wrote: > > Here's a better backtrace: > #0 0x401a8df0 in XDrawLine () from /usr/X11R6/lib/libX11.so.6 > #1 0x8172cb6 in GaugeExpose (w=0x8760cc8, event=0xbfffd95c, region=0x840cc80) at xlwgauge.c:425 > #2 0x4014f905 in _XtEventInitialize () from /usr/X11R6/lib/libXt.so.6 > #3 0x4014f5eb in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 > #4 0x4014f334 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 > #5 0x4014fcee in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 > #6 0x40150058 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 > #7 0x4015a970 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 > #8 0x8151964 in drain_X_queue () at event-Xt.c:2907 > #9 0x8151a2e in emacs_Xt_event_pending_p (user_p=0) at event-Xt.c:3024 > #10 0x80cb49f in event_stream_event_pending_p (user=0) at event-stream.c:438 > #11 0x80cd426 in Fdispatch_non_command_events () at event-stream.c:2386 > #12 0x80a85c6 in Feval (form=138209552) at eval.c:3331 > #13 0x80a6556 in condition_case_1 (handlers=138209048, bfun=0x80a817c , barg=138209552, hfun=0x80a65ac , harg=136170236) at eval.c:1651 > #14 0x80a67df in condition_case_3 (bodyform=138209552, var=136170236, handlers=138209048) at eval.c:1729 > #15 0x808af8d in execute_rare_opcode (stack_ptr=0xbfffdcc0, program_ptr=0x882a8cc "\207", opcode=Bcondition_case) at bytecode.c:1271 > #16 0x808a50b in execute_optimized_program (program=0x882a8c8 "ÀÁÂ\217\207", stack_depth=3, constants_data=0x83cb880) at bytecode.c:656 > #17 0x808a37f in funcall_compiled_function (fun=138171632, nargs=0, args=0xbfffddcc) at bytecode.c:515 > #18 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffddc8) at eval.c:3563 > #19 0x808a677 in execute_optimized_program (program=0x84e0d98 "\r¬\004Æ \025\n@\211\031A\036\020\b\t@a«%\t\f¡\210\016\020\fk«\020Ç\016\021È\013#\210ÉÊ\r!!\210ª\aË\f\013\r#\210Ì \210ª\r\b\fB\nB\022Ë\f\013\r#\210Í \210\013Îa­\004Ï\b!*\207ÿÿÿÿ\031", stack_depth=5, constants_data=0x83cb8a0) at bytecode.c:746 > #20 0x808a37f in funcall_compiled_function (fun=138171660, nargs=4, args=0xbfffdeec) at bytecode.c:515 > #21 0x80a8bc1 in Ffuncall (nargs=5, args=0xbfffdee8) at eval.c:3563 > #22 0x808a677 in execute_optimized_program (program=0x84e0d50 "\fÅa«\aÆ\n\t\013#\207ÇÈ\013\"«\004\b«\026É\n\t\fÊa«\004˪\aÌ\fÍ¥Î\"P\013#\207Ï\n\t\f\013$\207\001", stack_depth=6, constants_data=0x83cba98) at bytecode.c:746 > #23 0x808a37f in funcall_compiled_function (fun=138171744, nargs=3, args=0xbfffe00c) at bytecode.c:515 > #24 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe008) at eval.c:3563 > #25 0x808a677 in execute_optimized_program (program=0x8856268 "\212\013¬\f\n¬\tÅÆ\tÅ\"\210ª\017ÇÈ\013\n#\034É\t\f\b#\210\f))\207\b8", stack_depth=4, constants_data=0x83cbb30) at bytecode.c:746 > #26 0x808a37f in funcall_compiled_function (fun=138171856, nargs=4, args=0xbfffe12c) at bytecode.c:515 > #27 0x80a8bc1 in Ffuncall (nargs=5, args=0xbfffe128) at eval.c:3563 > #28 0x808a677 in execute_optimized_program (program=0x84e0878 "\016=­\a\f\rZ\016>Y\0366\016?\036@\016:¢Æa«\005\016:ª\003Ç A\036+È \036;É\211\0361\0367Ê\0363\016+G\0368Ë\211\0369\036.Ë\036)\016+\203q\004\016+@\211\0269@\026.\rb\210`\fW\203Q\004\016.;«\tÌ\016.\fÆ#ª\005\016.\f!\203=\004`\rZÍ_\f\rZ\0168_¥\0163Í_\0168¥\\É\\\0261\0166«\021\0161\0167V«\nÎÏÐ\0161\016;$\210\0161\0267\0169A\211\026)«¯\016)@@§\203Í\001\016)@@\225\034\016)@\211\036,@\211\0360\224\035\0160\225\034Ñ\016,8\036*\016,A@\211\036"..., stack_depth=13, constants_data=0x84e2258) at bytecode.c:746 > #29 0x808a37f in funcall_compiled_function (fun=138299276, nargs=3, args=0xbfffe26c) at bytecode.c:515 > #30 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe268) at eval.c:3563 > #31 0x808a677 in execute_optimized_program (program=0x8771cb8 "Æ Ç\211È É\211\031\030\036\020\036\021\036\022\036\023Ê\216\013«\005Ë\013!\210Ì\r\f\"\210\016\024«\006Í\r\f\"\210\016\025¬\aÎ\r\f\n#\210Ï\r\f\n#.\a\207", stack_depth=6, constants_data=0x84b6670) at bytecode.c:746 > #32 0x808a37f in funcall_compiled_function (fun=138298744, nargs=3, args=0xbfffe38c) at bytecode.c:515 > #33 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe388) at eval.c:3563 > #34 0x808a677 in execute_optimized_program (program=0x880a298 "\013\n\t\b#\207\200\b ", stack_depth=4, constants_data=0x84c1858) at bytecode.c:746 > #35 0x808a37f in funcall_compiled_function (fun=138298632, nargs=2, args=0xbfffe4ac) at bytecode.c:515 > #36 0x80a8bc1 in Ffuncall (nargs=3, args=0xbfffe4a8) at eval.c:3563 > #37 0x808a677 in execute_optimized_program (program=0x880a110 "Â\t\b\"\207¢\200\b ", stack_depth=3, constants_data=0x84b94d8) at bytecode.c:746 > #38 0x808a37f in funcall_compiled_function (fun=138298884, nargs=3, args=0xbfffe5e0) at bytecode.c:515 > #39 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe5dc) at eval.c:3563 > #40 0x8122a93 in Fmap_range_table (function=138298884, range_table=139159952) at rangetab.c:480 > #41 0x80a8aca in Ffuncall (nargs=3, args=0xbfffe678) at eval.c:3528 > #42 0x808a677 in execute_optimized_program (program=0x8771c08 "Ä\013\b\"\210Å\013!­'Æ\n!\210r\013q\210\212\214~\210\t\031ÇÈÉ\211\211\211\211ÊË&\b\210ÌedÊÉ$\210ÍÎ\n\",\207", stack_depth=9, constants_data=0x84b91d8) at bytecode.c:746 > #43 0x808a37f in funcall_compiled_function (fun=138298912, nargs=2, args=0xbfffe7c4) at bytecode.c:515 > #44 0x80a8bc1 in Ffuncall (nargs=3, args=0xbfffe7c0) at eval.c:3563 > #45 0x80a1a87 in Fmaphash (function=138298912, hash_table=139171896) at elhash.c:1195 > #46 0x80a8aca in Ffuncall (nargs=3, args=0xbfffe858) at eval.c:3528 > #47 0x808a677 in execute_optimized_program (program=0x8809f88 " \031Ã\216ÄÅ\b\"*\207", stack_depth=3, constants_data=0x84b9928) at bytecode.c:746 > #48 0x808a37f in funcall_compiled_function (fun=138298940, nargs=0, args=0xbfffe96c) at bytecode.c:515 > #49 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffe968) at eval.c:3563 > #50 0x808a677 in execute_optimized_program (program=0xbfffe9b4 "Á\b!ÂV­\003à \207", stack_depth=2, constants_data=0x84bb598) at bytecode.c:746 > #51 0x808c8d1 in Fbyte_code (instructions=139621028, constants=139179400, stack_depth=5) at bytecode.c:2403 > #52 0x80a85f2 in Feval (form=138707952) at eval.c:3331 > #53 0x80a6556 in condition_case_1 (handlers=138715660, bfun=0x80a817c , barg=138707952, hfun=0x80a65ac , harg=139536332) at eval.c:1651 > #54 0x80a67df in condition_case_3 (bodyform=138707952, var=139536332, handlers=138715660) at eval.c:1729 > #55 0x808af8d in execute_rare_opcode (stack_ptr=0xbfffec80, program_ptr=0x8809e04 "\207\237\200\b ", opcode=Bcondition_case) at bytecode.c:1271 > #56 0x808a50b in execute_optimized_program (program=0x8809e00 "ÀÁÂ\217\207\237\200\b ", stack_depth=3, constants_data=0x84b9578) at bytecode.c:656 > #57 0x808a37f in funcall_compiled_function (fun=138298800, nargs=0, args=0xbfffee48) at bytecode.c:515 > #58 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffee44) at eval.c:3563 > #59 0x80a93cf in run_hook_with_args_in_buffer (buf=0x8854f78, nargs=1, args=0xbfffee44, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4020 > #60 0x80a943e in run_hook_with_args (nargs=1, args=0xbfffee44, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4033 > #61 0x80a919d in Frun_hooks (nargs=1, args=0xbfffee44) at eval.c:3887 > #62 0x80a9538 in run_hook (hook=139535876) at eval.c:4134 > #63 0x80a9f11 in catch_them_squirmers_run_hook (hook_symbol=136270164) at eval.c:4578 > #64 0x80a6556 in condition_case_1 (handlers=136170308, bfun=0x80a9f00 , barg=136270164, hfun=0x80a9d8c , harg=140204160) at eval.c:1651 > #65 0x80aa104 in safe_run_hook_trapping_errors (warning_string=0x8187a80 "Error in `pre-idle-hook' (setting hook to nil)", hook_symbol=136270164, allow_quit=1) at eval.c:4639 > #66 0x80ccda5 in run_pre_idle_hook () at event-stream.c:2004 > #67 0x80cd015 in Fnext_event (event=142729332, prompt=136170212) at event-stream.c:2176 > #68 0x8091a47 in Fcommand_loop_1 () at cmdloop.c:574 > #69 0x8091905 in command_loop_1 (dummy=136170212) at cmdloop.c:494 > #70 0x80a6556 in condition_case_1 (handlers=136170308, bfun=0x80918ec , barg=136170212, hfun=0x8091460 , harg=136170212) at eval.c:1651 > #71 0x8091553 in command_loop_3 () at cmdloop.c:256 > #72 0x8091577 in command_loop_2 (dummy=136170212) at cmdloop.c:267 > #73 0x80a622c in internal_catch (tag=136246308, func=0x809156c , arg=136170212, threw=0x0) at eval.c:1317 > #74 0x80916ae in initial_command_loop (load_me=136170212) at cmdloop.c:305 > #75 0x80a32e1 in xemacs_21_4_1_i386_debian_linux () at emacs.c:2344 > #76 0x80a3a52 in main () at emacs.c:2773 > #77 0x4041316b in __libc_start_main () from /lib/libc.so.6 > > With what looks like the same lisp backtrace: > dispatch-non-command-events() > # (condition-case ... . ((nil))) > progress-feedback-dispatch-non-command-events() > # bind (tmsg top frame value message label) > append-progress-feedback(font-lock "Fontifying test... " 100 nil) > # bind (frame value message label) > display-progress-feedback(font-lock "Fontifying test... " 100) > # bind (str) > # (unwind-protect ...) > # bind (args value fmt label) > progress-feedback-with-label(font-lock "Fontifying %s... " 100 "test") > # bind (loudly loudvar end start) > font-lock-fontify-keywords-region(1 11452 nil) > # (unwind-protect ...) > # bind (modified buffer-undo-list inhibit-read-only old-syntax-table buffer-file-name buffer-file-truename loudly end beg) > font-lock-default-fontify-region(1 11452 nil) > # bind (loudly end beg) > font-lock-fontify-region(1 11452) > # bind (val end beg) > #(1 11452 t) > map-range-table(# #s(range-table data ((1 11452) t))) > # bind (zmacs-region-stays) > # (unwind-protect ...) > # (unwind-protect ...) > # (unwind-protect ...) > # bind (dummy buffer) > # nil font-lock-pending t put-text-property map-range-table #] 9>(# t) > maphash(# nil font-lock-pending t put-text-property map-range-table #] 9> #) > # (unwind-protect ...) > # bind (match-data) > font-lock-fontify-pending-extents() > byte-code("..." [font-lock-pending-buffer-table hash-table-count 0 font-lock-fontify-pending-extents] 2) > # (condition-case ... . ((error (warn "Error caught in `font-lock-pre-idle-hook': %s" font-lock-error)))) > font-lock-pre-idle-hook() > # (condition-case ... . error) > # (condition-case ... . error) > # (catch top-level ...) > > Haven't been able to reproduce with -vanilla yet. > > After loading my custom.el I am getting lots of X errors like this: > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 70 (X_PolyFillRectangle) > Resource id in failed request: 0xd > Serial number of failed request: 31453 > Current serial number in output stream: 31471 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 66 (X_PolySegment) > Resource id in failed request: 0xd > Serial number of failed request: 31454 > Current serial number in output stream: 31471 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 66 (X_PolySegment) > Resource id in failed request: 0xd > Serial number of failed request: 31499 > Current serial number in output stream: 31502 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 70 (X_PolyFillRectangle) > Resource id in failed request: 0xd > Serial number of failed request: 31500 > Current serial number in output stream: 31502 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 66 (X_PolySegment) > Resource id in failed request: 0xd > Serial number of failed request: 31501 > Current serial number in output stream: 31502 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 66 (X_PolySegment) > Resource id in failed request: 0xd > Serial number of failed request: 31557 > Current serial number in output stream: 31560 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 70 (X_PolyFillRectangle) > Resource id in failed request: 0xd > Serial number of failed request: 31558 > Current serial number in output stream: 31560 > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC parameter) > Major opcode of failed request: 66 (X_PolySegment) > Resource id in failed request: 0xd > Serial number of failed request: 31559 > Current serial number in output stream: 31560 > > OK. Got a repeat with -vanilla loading the following: > (custom-set-variables > '(w3-user-fonts-take-precedence t) > '(gnus-junk-complaint-text " Hello, > > James LewisMoss > > -- > @James LewisMoss | dres@debian.org | Blessed Be! > @ http://www.lewismoss.com/~dres | Linux is cool! > @\"Argue for your limitations and sure enough, they're yours.\" Bach > ") > '(irchat-want-traditional t) > '(message-generate-headers-first t) > '(gnus-junk-original-seperator " > --------------------original--message--follows-------------------- > ") > '(toolbar-news-use-separate-frame t) > '(wwi-auto-install-on-startup-flag t nil (where-was-i-db)) > '(gnuserv-program (concat exec-directory "/gnuserv")) > '(change-log-default-name "ChangeLog") > '(icomplete-mode t nil (icomplete)) > '(message-default-charset (quote us-ascii)) > '(browse-url-browser-function (quote browse-url-netscape)) > '(minibuf-frame-pos-y -2) > '(minibuf-frame-pos-x 0) > '(message-deletable-headers (quote (Message-ID Date Lines Sender))) > '(toolbar-news-reader (quote gnus)) > '(w3-user-colors-take-precedence t) > '(gnus-uu-user-view-rules (quote (("\"\\\\.\\\\(jpe?g\\\\|gif\\\\|tiff?\\\\|p[pgb]m\\\\|xwd\\\\|xbm\\\\|pcx\\\\)$" "eeyes")))) > '(toolbar-visible-p nil) > '(nnmail-spool-file "/var/spool/mail/$user") > '(jde-mode-abbreviations (quote (("ab" "abstract") ("bo" "boolean") ("br" "break") ("by" "byte") ("byv" "byvalue") ("cas" "cast") ("ca" "catch") ("ch" "char") ("cl" "class") ("co" "const") ("con" "continue") ("de" "default") ("dou" "double") ("el" "else") ("ex" "extends") ("fa" "false") ("fi" "final") ("fin" "finally") ("fl" "float") ("fo" "for") ("fu" "future") ("ge" "generic") ("go" "goto") ("impl" "implements") ("impo" "import") ("ins" "instanceof") ("in" "int") ("inte" "interface") ("lo" "long") ("na" "native") ("ne" "new") ("nu" "null") ("pa" "package") ("pri" "private") ("pro" "protected") ("pu" "public") ("re" "return") ("sh" "short") ("St" "String") ("st" "static") ("su" "super") ("sw" "switch") ("sy" "synchronized") ("th" "this") ("thr" "throw") ("throw" "throws") ("tra" "transient") ("tr" "true") ("vo" "void") ("vol" "volatile") ("wh" "while")))) > '(Info-button1-follows-hyperlink t) > '(frame-background-mode (quote dark)) > '(gnus-check-bogus-newsgroups t) > '(completion-ignored-extensions (quote (".Sym" ".Lib" ".beam" ".vee" ".jam" ".o" ".elc" "~" ".bin" ".lbin" ".fasl" ".dvi" ".toc" ".log" ".aux" ".a" ".ln" ".lof" ".blg" ".bbl" ".glo" ".idx" ".lot" ".fmt" ".oi" ".class"))) > '(gnus-junk-include-body t) > '(user-mail-address "jimdres@mindspring.com") > '(query-user-mail-address nil)) > (custom-set-faces > '(info-xref ((t (:bold t :foreground "sienna1")))) > '(pointer ((t (:foreground "purple1" :background "blue"))) t) > '(info-node ((t (:bold t :foreground "dodgerblue1")))) > '(secondary-selection ((t (:foreground "green1"))) t) > '(eif-string ((t (:bold nil :foreground "tomato"))) t) > '(html-helper-italic-face ((t (:italic t :family "lucida"))) t) > '(widget-field-face ((((class grayscale color) (background light)) (:foreground "black" :background "gray85")))) > '(gnus-header-subject-face ((((class color) (background dark)) (:bold t :italic t :foreground "pink" :family "lucida")))) > '(gnus-header-from-face ((((class color) (background dark)) (:bold t :italic t :foreground "light blue" :family "lucida")))) > '(font-lock-string-face ((t (:bold nil :foreground "yellowgreen")))) > '(eif-comment ((t (:bold nil :foreground "hot pink"))) t) > '(dired-face-permissions ((t (:foreground "red" :background "grey85")))) > '(xrdb-option-name-face ((t (:bold nil :foreground "red1"))) t) > '(font-lock-reference-face ((t (:foreground "gold")))) > '(comint-input-face ((((class color) (background light)) (:foreground "sky blue")))) > '(gnus-group-news-low-empty-face ((((class color)) (:foreground "DarkTurquoise")) (((class color) (background light)) (:foreground "DarkGreen")) (t nil))) > '(dired-face-setuid ((((class color)) (:foreground "yellow")) (t (:bold t)))) > '(shell-prompt-face ((t (:foreground "antique white" :background "dark green"))) t) > '(widget-documentation-face ((((class color) (background light)) (:bold nil :foreground "orchid1")))) > '(gnus-header-newsgroups-face ((((class color) (background dark)) (:bold t :italic t :foreground "yellow" :family "lucida")))) > '(gnus-emphasis-underline-italic ((t (:italic t :underline t :family "lucida")))) > '(custom-group-tag-face ((((class color) (background light)) (:underline t :foreground "sky blue")))) > '(custom-variable-tag-face ((((class color) (background light)) (:underline t :foreground "light blue")))) > '(message-header-subject-face ((((class color) (background dark)) (:foreground "pink")) (((class color) (background light)) (:bold t :foreground "navy blue")) (t (:bold t)))) > '(eif-assertion ((t (:bold t :foreground "light blue" :size "10"))) t) > '(gnus-summary-low-unread-face ((t (:italic t :family "lucidatypewriter")))) > '(font-lock-doc-string-face ((t (:foreground "green")))) > '(gnus-summary-low-ticked-face ((((class color) (background dark)) (:italic t :foreground "pink" :family "lucidatypewriter")))) > '(modeline-buffer-id ((t (:foreground "blue4" :background "grey80"))) t) > '(font-lock-preprocessor-face ((t (:foreground "black" :background "pink")))) > '(modeline-mousable ((t (:foreground "firebrick" :background "grey80"))) t) > '(gnus-group-news-3-face ((t (:bold t :foreground "steelblue1")))) > '(font-lock-variable-name-face ((t (:foreground "navajowhite2")))) > '(gnus-group-news-3-empty-face ((t (:foreground "steelblue2")))) > '(hyper-apropos-hyperlink ((((class color) (background light)) (:foreground "light blue")))) > '(gnus-header-content-face ((t (:italic t :foreground "lawngreen" :family "lucida")))) > '(custom-state-face ((((class color) (background light)) (:foreground "light green")))) > '(font-lock-other-emphasized-face ((t (:foreground "green" :background "dark blue"))) t) > '(font-lock-keyword-face ((((class color) (background light dark)) (:bold nil :foreground "pink")))) > '(message-cited-text-face ((((class color) (background dark)) (:foreground "LightBlue")) (((class color) (background light)) (:foreground "red")) (t (:bold t)))) > '(documentation ((t (:bold nil :foreground "light pink"))) t) > '(eif-hidden-comment ((t (:bold nil :foreground "light green"))) t) > '(gnus-signature-face ((((type x)) (:italic t :family "lucidatypewriter")))) > '(gnus-emphasis-underline-bold-italic ((t (:bold t :italic t :underline t :family "lucida")))) > '(font-lock-type-face ((t (:foreground "light pink")))) > '(gnus-group-mail-low-empty-face ((((class color) (background dark)) (:foreground "paleturquoise2")) (((class color) (background light)) (:foreground "DeepPink4")) (t (:bold t)))) > '(bold-italic ((t (:italic t :family "lucida"))) t) > '(w3-table-hack-x-face ((t (:family "lucidatypewriter" :size "10"))) t) > '(gnus-header-name-face ((((class color) (background dark)) (:foreground "cyan")) (((class color) (background light)) (:foreground "maroon")) (t (:bold t)))) > '(font-lock-emphasized-face ((t (:foreground "blue" :background "lightyellow2" :size "nil"))) t) > '(widget-inactive-face ((((class grayscale color) (background light)) (:foreground "light pink")))) > '(blue ((t (:foreground "lightskyblue"))) t) > '(gnus-group-mail-low-face ((((class color) (background dark)) (:bold t :foreground "aquamarine2")) (((class color) (background light)) (:bold t :foreground "DeepPink4")) (t (:bold t)))) > '(message-header-cc-face ((((class color) (background dark)) (:bold t :foreground "light blue")) (((class color) (background light)) (:foreground "MidnightBlue")) (t (:bold t)))) > '(message-header-other-face ((((class color) (background dark)) (:foreground "gray")) (((class color) (background light)) (:foreground "steel blue")) (t (:bold t :italic t)))) > '(message-header-newsgroups-face ((((class color) (background dark)) (:bold t :italic t :foreground "yellow" :family "lucidatypewriter")))) > '(message-separator-face ((((class color) (background dark)) (:foreground "red")) (((class color) (background light)) (:foreground "brown")) (t (:bold t)))) > '(list-mode-item-selected ((t (:background "blue"))) t) > '(message-header-contents ((t (:italic t :family "lucidatypewriter")))) > '(hyper-apropos-documentation ((((class color) (background light)) (:foreground "lightpink")))) > '(italic ((t (:italic t :family "lucida"))) t) > '(gnus-summary-low-ancient-face ((((class color) (background dark)) (:italic t :foreground "SkyBlue" :family "lucidatypewriter")))) > '(font-lock-comment-face ((t (:foreground "orchid1")))) > '(dired-face-executable ((((class color)) (:foreground "yellow")) (t (:bold t)))) > '(message-header-name-face ((((class color) (background dark)) (:foreground "cyan")) (((class color) (background light)) (:foreground "cornflower blue")) (t (:bold t)))) > '(gnus-emphasis-italic ((t (:italic t :family "lucida")))) > '(font-lock-function-name-face ((t (:foreground "lightskyblue")))) > '(message-header-xheader-face ((((class color) (background dark)) (:foreground "lightblue")))) > '(isearch ((t (:foreground "black" :background "lightblue"))) t) > '(gnus-emphasis-bold-italic ((t (:bold t :italic t :family "lucida")))) > '(hyperlink ((t (:bold t :foreground "mediumpurple1"))) t) > '(message-header-to-face ((((class color) (background dark)) (:bold t :foreground "LightBlue")) (((class color) (background light)) (:bold t :foreground "MidnightBlue")) (t (:bold t :italic t)))) > '(zmacs-region ((t (:bold t :foreground "black" :background "pink" :family "lucidatypewriter"))) t) > '(gnus-summary-low-read-face ((((class color) (background dark)) (:italic t :foreground "PaleGreen" :family "lucidatypewriter")))) > '(message-highlighted-header-contents ((t (:bold t :italic t :family "lucidatypewriter")))) > '(dired-face-marked ((((class color)) (:foreground "black" :background "PaleVioletRed")) (t (:underline t))))) > and > (require 'dired) > (setq dired-listing-switches "-laF") > (setq list-directory-brief-switches "-FC") > (setq-default dired-omit-files-p nil) > (setq dired-do-permission-highlighting-too t) > (add-hook 'dired-mode-hook 'turn-on-font-lock) > > (define-key dired-mode-map [r] 'dired-advertised-find-file) > (define-key dired-mode-map [(control c) (control c)] 'compile) > > (setq dired-re-raw-boring > (concat ".\\(\\.class\\|\\.oi\\|\\.fmt\\|\\.ln\\|" > "\\.a\\|\\.fasl\\|\\.lbin\\|\\.bin\\|\\.elc\\|" > "\\.o\\|\\.lo\\|\\.jam\\|\\.vee\\|\\.beam\\|" > "\\.Lib\\|\\.Sym\\|~\\|\\.orig\\|\\.rej\\|" > "\\.vrs\\|\\.vr\\|\\.tps\\|\\.tp\\|\\.pgs\\|" > "\\.pg\\|\\.kys\\|\\.ky\\|\\.fns\\|\\.fn\\|" > "\\.cps\\|\\.cp\\|\\.bbl\\|\\.blg\\|\\.glo\\|" > "\\.lot\\|\\.lof\\|\\.idx\\|\\.dvi\\|\\.aux\\|" > "\\.log\\|\\.toc\\)" > "\\'\\|\\`#\\|\\`\\.")) > > This is opening a particular directory (test) which contains a bunch > of junk that I was playing with at one point or another. File list if > anyone thinks it'll help. > > Different issue: > Startup time is very long now (in comparison to 21.1.14). > > Jim > > -- > @James LewisMoss | Blessed Be! > @ http://jimdres.home.mindspring.com | Linux is kewl! > @"Argue for your limitations and sure enough, they're yours." Bach -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From max@kuku.melbourne.sgi.com Sun May 6 20:35:02 2001 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA25652 for ; Sun, 6 May 2001 20:34:38 -0400 Received: from nodin.corp.sgi.com ([192.26.51.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA09995 for ; Sun, 6 May 2001 17:34:33 -0700 (PDT) mail_from (max@kuku.melbourne.sgi.com) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.2/8.11.2/nodin-1.0) with SMTP id f470YV114688555 for <@relay.sgi.com:xemacs-beta@xemacs.org>; Sun, 6 May 2001 17:34:32 -0700 (PDT) Received: from kuku.melbourne.sgi.com (kuku.melbourne.sgi.com [134.14.55.163]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14782 for ; Mon, 7 May 2001 10:34:30 +1000 Received: (from max@localhost) by kuku.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA84430; Mon, 7 May 2001 10:34:30 +1000 (EST) Sender: max@melbourne.sgi.com To: xemacs-beta@xemacs.org Subject: Re: [21.4.1] png.h errors on mips-sgi-irix6.5 References: <3AF3332F.D4D65685@sgrail.com> From: Max Matveev In-Reply-To: Gabe Foster's message of "Fri, 04 May 2001 17:54:39 -0500" Date: 07 May 2001 10:34:29 +1000 Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "GF" == Gabe Foster writes: GF> I've seen this problem as well. SGI install an old version of png in GF> /usr/include and /usr/lib{n32,64,}. What I did was to point to versions GF> I had installed from from SGI's freeware base (and other libraries I GF> installed myself in /usr/include.) GF> ./configure --site-includes=/usr/local/include:/usr/freeware/include GF> --site-libraries=/usr/local/lib32:/usr/freeware/lib32 GF> --libdir=/usr/local/lib32 Setting CFLAGS to explicit '-nostdinc -I/usr/freeware/include -I/usr/include' should help. Same for the libraries with -nostdlib. GF> As I recall this did not help completely, so I moved the png.h and GF> pngconf.h files in /usr/include to png.h.bak and pngconf.h.bak and GF> things worked much better. Moving files should be avoided if possible. If you sure you don't need that old version of png.h, remove ifl_dev.sw.c++ using inst of swmgr. max From ben@666.com Sun May 6 22:15:46 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id WAA32053 for ; Sun, 6 May 2001 22:15:42 -0400 Received: (qmail 62693 invoked by alias); 7 May 2001 02:15:41 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 62681 invoked by uid 0); 7 May 2001 02:15:41 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 7 May 2001 02:15:41 -0000 Message-ID: <3AF605A6.9F29BC67@666.com> Date: Sun, 06 May 2001 19:17:10 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Andreas Jaeger , XEmacs Beta Testers Subject: Re: Warning: XtRemoveGrab asked to remove a widget not on thelist References: <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> <4.3.2.7.2.20010501092408.02e929f0@san-francisco.beasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Piper wrote: > > At 12:06 PM 5/1/01 +0200, Andreas Jaeger wrote: > >Andy Piper writes: > > > > > I've seen this at frame deletion and never been able to track it > > > down. I believe its widget related becuase it came and went while I > > > was hacking on them. > > > >Do you have any idea how to track it down? I can easily reproduce it > >but don't know anything about the widget stuff. > > Absolutely no idea - it seems to be in the guts of the X code. I read all > the manuals and put breakpoints everywhere, but I just don't know what the > error is indicating. what you need to do is recompile the Xt sources with debug info, and find the place in the sources where this error is being issued, and set a breakpoint there. this shouldn't be hard, although perhaps a bit time-consuming if the Xt sources don't recompile easily. the message indicates that XtRemoveGrab was called on a widget without an associated earlier XtAddGrab call. those calls are used to create menus and modal dialog boxes -- anything that temporarily locks out input to all other widgets. andy, what state is the focus-handling in your code in? > > andy -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From jimdres@mindspring.com Sun May 6 22:21:17 2001 Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA32195 for ; Sun, 6 May 2001 22:18:47 -0400 Received: from eeyore.lewismoss.org (user-2ivf1uc.dialup.mindspring.com [165.247.135.204]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA03611 for ; Sun, 6 May 2001 22:18:37 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14wab8-0001Fa-00 for ; Sun, 06 May 2001 22:18:06 -0400 To: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> From: James LewisMoss In-Reply-To: Ben Wing's message of "Sun, 06 May 2001 17:28:26 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 06 May 2001 22:17:45 -0400 Message-ID: Lines: 102 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss Here's the args in the GaugeExpose call: Program received signal SIGSEGV, Segmentation fault. 0x401a8df0 in XDrawLine () from /usr/X11R6/lib/libX11.so.6 (gdb) up #1 0x8172cb6 in GaugeExpose (w=0x863a570, event=0xbfffd91c, region=0x84314c8) at xlwgauge.c:425 425 XDrawLine(dpy,win,gctop, e0+1,y, e1-1,y) ; (gdb) info args w = 0x863a570 event = (XEvent *) 0xbfffd91c region = 0x84314c8 (gdb) info locals gw = 0x863a570 dpy = (Display *) 0x84451a0 win = 20971736 gc = 0x8 gctop = 0x8 gcbot = 0x8 len = 20971736 e0 = 5768 e1 = -5519 x = 135736196 y = 64481 i = 0 v0 = 0 v1 = 100 value = 0 And it's very reproducible. This seems to be a font locking issue because every time it happens (I couldn't include the previous email in this one because it was causing a crash) the two boxes which look like font lock progress bars (but I haven't seen much of them because they go quickly or crash). I forgot this info last time: uname -a: Linux eeyore 2.4.4-pre7 #1 Thu Apr 26 23:45:07 EDT 2001 i686 unknown ./configure '--with-sound=native' '--with_menubars=lucid' '--with_scrollbars=lucid' '--with_dialogs=athena' '--cflags=-O2 -g -Wall' '--with-x11' '--extra-verbose' '--with-site-lisp' '--statedir=/var/lib' '--infodir=/usr/share/info/xemacs-21.4.1' '--prefix=/usr' '--statedir=/var/lib/xemacs' '--error-checking=none' '--debug=no' '--const-is-losing=no' '--dynamic' '--with-gpm=no' '--docdir=/usr/lib/xemacs-21.4.1/i386-debian-linux/nomule/' '--package-path=~/.xemacs::/usr/share/xemacs21/packages:/usr/share/xemacs21/site-packages' 'i386-debian-linux' XEmacs 21.4.1 "Copyleft" configured for `i386-debian-linux'. Compilation / Installation: Source code location: /home/dres/project/debian/xemacs21/xemacs-21.4.1 Installation prefix: /usr Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -O2 -g -Wall Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: postgresql/libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Thanks Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From philipa@mail.com Mon May 7 07:34:16 2001 Received: from scrabble.freeuk.net (scrabble.freeuk.net [212.126.144.6]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA31141 for ; Mon, 7 May 2001 07:34:07 -0400 Received: from du-002-0104.freeuk.com ([212.126.156.104] helo=paston.beasys.com.freeuk.net) by scrabble.freeuk.net with esmtp (Exim 3.12 #1) id 14wjGu-0002G4-00; Mon, 07 May 2001 12:33:48 +0100 X-Mailer: 21.5 (beta0) "alfalfa" XEmacs Lucid (via feedmail 8 I); VM 6.92 under 21.5 (beta0) "alfalfa" XEmacs Lucid From: "Philip Aston" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15093.13630.362000.647144@paston.beasys.com> Date: Sun, 6 May 2001 12:27:58 +0100 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: assertion failed, file event-stream.c, line 1037, tm In-Reply-To: <4.3.2.7.2.20010504093201.0223bd70@san-francisco.beasys.com> References: <9442-Fri04May2001143815+0100-paston@bea.com> <4.3.2.7.2.20010504093201.0223bd70@san-francisco.beasys.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id HAA31141 The assertion stacktrace doesn't seem that useful (at least to me): #0 assert_failed (file=0x4d7d71 "event-stream.c", line=1037, expr= 0x4d8ebc "tm") at emacs.c:3258 #1 0x004e1268 in pop_low_level_timeout (timeout_list=0x9971e0, time_ out=0x0) at event-stream.c:1037 #2 0x005b5c2a in check_what_happened () at signal.c:317 #3 0x00454ec5 in Ffuncall (nargs=1, args=0x2e4af54) at eval.c:3474 #4 0x00418907 in execute_optimized_program (program=0xa747c10 "À\t !«\006Â\t!ª\002\t\211\e­\004Ä\013!\035Æ\036\a\r¬\013ÈÉ ÊË\t\"\"\210ª=\212\rq\210ÌÍÎ\"\210\016\017«\"~\210\t¬ \004\r«\tÐ «\005Ñ \026\a\016\022¬\016ÓÔ\016\025ÖH!!®\ 002×\026\022)\016\aض¬\b\016\031Ú\r!!\210+ÛÜ !q\207", sta ck_depth=6, constants_data=0xa37eb10) at bytecode.c:746 #5 0x004181ce in funcall_compiled_function (fun=169383348, nargs=2 , args=0x2e4b0d4) at bytecode.c:518 #6 0x004552c7 in Ffuncall (nargs=3, args=0x2e4b0d0) at eval.c:3563 #7 0x00418907 in execute_optimized_program (program=0xa746410 "À\t !\032\013®\004ÄÅ!\036\006Ç \210\nÈH\036\t\nÊH®\016\nËH­ \tÌ\nÍH\016\016\"£\036\017\016\020®\036\n\211\036\021ÒH«\02 1\016\021ÓHÔÕÖ\016\021ÒHÔ#Qª\005\016\021ÓH)\036\027\nØ H\036\031Ú\036\e\016\017Ük«\004Ý\026\017\016\027Ük«\004Þ\ 026\027\016\t¬\bßà\t\"\202½", stack_depth=7, constants_data= 0xa288410) at bytecode.c:746 #8 0x004181ce in funcall_compiled_function (fun=172328540, nargs=1 , args=0x2e4b254) at bytecode.c:518 #9 0x004552c7 in Ffuncall (nargs=2, args=0x2e4b250) at eval.c:3563 Setting a breakpoint in alarm_signal(), it appears that some cygwin (?) code is raising SIGALRM. Here are three partial stacktraces from different runs (all of which resulted in the assertion): #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices@OSinterface@@2HA () #2 0x005a9256 in re_match_2_internal (bufp 96924, string1, size1 46d5b8 ":/images/ejbbook_anim.gif", size2%, pos!, regs 97160, stop%) at regex.c:5463 #3 0x005a59dd in re_search_2 (bufp 96924, str1, size1 46d5b8 ":/images/ejbbook_anim.gif", size2%, startpos!, range%, regs 97160, stop%) at regex.c:4162 #4 0x005aaec2 in re_search (bufp 96924, string 46d5b8 ":/images/ejbbook_anim.gif", size%, startpos nge%, regs 97160) at regex.c:3924 #5 0x005abd31 in string_match_1 (regexp1379396, string0653492, startq94628, buf 747c00, posix t search.c:411 #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices@OSinterface@@2HA () #2 0x005d18a9 in xemacs_stat (path 801fb4 "/this/is/a/highly/unlikely/directory/name/cache/philipa/http//www/a1a56668f2a4bc987ac64aaed898f3ec", bufe4aca4) at sysdep.c:3110 #3 0x004fd14f in Ffile_exists_p (filename0940356) at fileio.c:2257 #4 0x0045510c in Ffuncall (nargs*rgse4ada0) at eval.c:3528 #5 0x00418907 in execute_optimized_program (program 47e510 "À\t!\032Ã\n!\034\n­\020Å\n!­\013\f@Æa?­\004Ç\f8*\207\200'\021\n`4\013\n\200*\021\nkk", stack_depth,onstants_data 47e590) at bytecode.c:746 #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices@OSinterface@@2HA () #2 0x00451a25 in call_with_suspended_errors_1 (opaque_arg7864512) at opaque.h:63 #3 0x00451eeb in call_with_suspended_errors (fun766a8 , retval`64412, classs33964, errb #4 0x005bed26 in specifier_instance_from_inst_list (specifier“62496, matchspec`64412, domain0209792, inst_list’93604, errb #5 0x005bf106 in specifier_instance (specifier“62496, matchspec`64412, domain0209792, errb When the signal handler kicks in, async_timer_queue BTW, I have to be dialed in to see this behaviour. My guess is that the SIGALRM is raised by some timeout in cygwin socket handling code. - Phil Andy Piper writes: > Hey Phil, > > You need to produce a C stacktrace. > > Thanks > > andy > > At 02:38 PM 5/4/01 +0100, Philip Aston wrote: > >This bug report will be sent to the XEmacs Development Team, > > not to your local site managers!! > >Please write in English, because the XEmacs maintainers do not have > >translators to read other languages for them. > > > >In XEmacs 21.5 (beta0) "alfalfa" [Lucid] (i686-pc-cygwin) of Wed Apr 18 > >2001 on PASTON > >configured using `configure --with-dragndrop > >--site-includes=/usr/include/w32api' > > > >Please describe exactly what actions triggered the bug > >and the precise symptoms of the bug: > > > >For a whlie now I've been getting occasional assertions: > > > > Fatal error: assertion failed, file event-stream.c, line 1037, tm > > > >Until now, I did not have a repeatable test case. > > > >With the latest source from CVS I've managed to repeat this when > >rendering an HTML rich VM message. I have a VM folder containing said > >message with which ... > > > > $ xemacs -q > > M-x vm-visit-folder bug > > (Spinning, messages about contacting www:80 etc) > > Assertion failure > > > >This happens under cygwin/native NT UI. It does not happen with -nw. > > > >The e-mail is private, but I'll forward it if anyone wants to > >investigate. > > > >- Phil > > > > > >Recent keystrokes: > > > >M-button1 M-button1up misc-user misc-user > > > > > >Recent messages (most recent first): > > > >Parsing /home/philipa/.mailrc... > >Loading mail-abbrevs...done > >Loading mail-abbrevs... > >M-Sh-insert not defined. > >M-Sh-insert not defined. > >M-Sh-insert not defined. > >Loading emacsbug...done > >Loading emacsbug... > >5 messages, 0 new, 0 unread, 0 deleted > >Loading smiley...done > > (gdb) break assert_failed Breakpoint 1 at 0x44dfe4: file emacs.c, line 3258. (gdb) run Breakpoint 1, assert_failed (file=0x4d7d71 "event-stream.c", line=1037, expr=0x4d8ebc "tm") at emacs.c:3258 Starting program: /usr/local/src/xemacs-21.5/./src/xemacs.exe -q (gdb) where #0 assert_failed (file=0x4d7d71 "event-stream.c", line=1037, expr=0x4d8ebc "tm") at emacs.c:3258 #1 0x004e1268 in pop_low_level_timeout (timeout_list=0x9971e0, time_out=0x0) at event-stream.c:1037 #2 0x005b5c2a in check_what_happened () at signal.c:317 #3 0x00454ec5 in Ffuncall (nargs=1, args=0x2e4af54) at eval.c:3474 #4 0x00418907 in execute_optimized_program (program=0xa747c10 "À\t!«\006Â\t!ª\002\t\211\e­\004Ä\013!\035Æ\036\a\r¬\013ÈÉÊË\t\"\"\210ª=\212\rq\210ÌÍÎ\"\210\016\017«\"~\210\t¬\004\r«\tÐ «\005Ñ \026\a\016\022¬\016ÓÔ\016\025ÖH!!®\002×\026\022)\016\aض¬\b\016\031Ú\r!!\210+ÛÜ !q\207", stack_depth=6, constants_data=0xa37eb10) at bytecode.c:746 #5 0x004181ce in funcall_compiled_function (fun=169383348, nargs=2, args=0x2e4b0d4) at bytecode.c:518 #6 0x004552c7 in Ffuncall (nargs=3, args=0x2e4b0d0) at eval.c:3563 #7 0x00418907 in execute_optimized_program (program=0xa746410 "À\t!\032\013®\004ÄÅ!\036\006Ç \210\nÈH\036\t\nÊH®\016\nËH­\tÌ\nÍH\016\016\"£\036\017\016\020®\036\n\211\036\021ÒH«\021\016\021ÓHÔÕÖ\016\021ÒHÔ#Qª\005\016\021ÓH)\036\027\nØH\036\031Ú\036\e\016\017Ük«\004Ý\026\017\016\027Ük«\004Þ\026\027\016\t¬\bßà\t\"\202½", stack_depth=7, constants_data=0xa288410) at bytecode.c:746 #8 0x004181ce in funcall_compiled_function (fun=172328540, nargs=1, args=0x2e4b254) at bytecode.c:518 #9 0x004552c7 in Ffuncall (nargs=2, args=0x2e4b250) at eval.c:3563 #10 0x00418907 in execute_optimized_program (program=0xa27a610 "\b«\024Á\n!«\006Ã\n!ª\002\n\f\230«\005Å ª\002\n\032Æ\016\a!\211\036\bÉH\036\n\016\bËH­\bÌ\016\b\211ËH\"\036\rÎ\036\017\016\a\036\020Î\036\021\016\r«\004Ò\026\nÓ\016\a!\211\026\021­\bÔ\016\a\016\021\"?\211\026\021«\004Õª\fÖ\016\n®\002×\016\030\"£¢\026\017\016\021«\aÙ\016\a!ª\003\016\a\026\a\212Ú\n!q\210ÛÜ!\210ÝÞ!«\004Î\026\036\016\037?\026 \016\b\026!)\016\017«\017â\016\017!«\t\016\017\016\a!\210ª!Ú\n!q\210ã \210ä\026%æçèé\016\n\"êëì\016-îïð\016-ñ±\f\210\0162«\013"..., stack_depth=13, constants_data=0xa22ce10) at bytecode.c:746 #11 0x004181ce in funcall_compiled_function (fun=171499720, nargs=2, args=0x2e4b3f4) at bytecode.c:518 #12 0x004552c7 in Ffuncall (nargs=3, args=0x2e4b3f0) at eval.c:3563 #13 0x00418907 in execute_optimized_program (program=0xa305790 "À \210ÁÂ!«\017ÃÂK!«\tÂÄ\rGÆ\r$\210\r«\rÇÈ\r\"«\a\rÄ\225ÆO\025É\r\016\n\"\207", stack_depth=6, constants_data=0xa386390) at bytecode.c:746 #14 0x004181ce in funcall_compiled_function (fun=171499748, nargs=1, args=0x2e4b574) at bytecode.c:518 #15 0x004552c7 in Ffuncall (nargs=2, args=0x2e4b570) at eval.c:3563 #16 0x00418907 in execute_optimized_program (program=0xa747f90 "\bÁ\032\e\013«!\n¬\036\013@@Ķ¬\021ÅÆ\013@@ÇQ\016\b\"«\005É\022ªä\013A\211\023¬á\n«\fÊ\013@@Ë\016\bQ!ª4ÅÌ\016\b\"«\tÊÍ\016\bP!ª%ÅÎ\016\b\"«\tÊÍ\016\bP!ª\026ÏÐ\016\b\"\211\023«\006Ê\013!ª\bÊÑ\016\bÒQ!*\207", stack_depth=5, constants_data=0xa336390) at bytecode.c:746 #17 0x004181ce in funcall_compiled_function (fun=169382620, nargs=1, args=0x2e4b6f4) at bytecode.c:518 #18 0x004552c7 in Ffuncall (nargs=2, args=0x2e4b6f0) at eval.c:3563 #19 0x00418907 in execute_optimized_program (program=0xa27a610 "\b«\024Á\n!«\006Ã\n!ª\002\n\f\230«\005Å ª\002\n\032Æ\016\a!\211\036\bÉH\036\n\016\bËH­\bÌ\016\b\211ËH\"\036\rÎ\036\017\016\a\036\020Î\036\021\016\r«\004Ò\026\nÓ\016\a!\211\026\021­\bÔ\016\a\016\021\"?\211\026\021«\004Õª\fÖ\016\n®\002×\016\030\"£¢\026\017\016\021«\aÙ\016\a!ª\003\016\a\026\a\212Ú\n!q\210ÛÜ!\210ÝÞ!«\004Î\026\036\016\037?\026 \016\b\026!)\016\017«\017â\016\017!«\t\016\017\016\a!\210ª!Ú\n!q\210ã \210ä\026%æçèé\016\n\"êëì\016-îïð\016-ñ±\f\210\0162«\013"..., stack_depth=13, constants_data=0xa22ce10) at bytecode.c:746 #20 0x004181ce in funcall_compiled_function (fun=171499720, nargs=2, args=0x2e4b894) at bytecode.c:518 #21 0x004552c7 in Ffuncall (nargs=3, args=0x2e4b890) at eval.c:3563 #22 0x00418907 in execute_optimized_program (program=0xa305790 "À \210ÁÂ!«\017ÃÂK!«\tÂÄ\rGÆ\r$\210\r«\rÇÈ\r\"«\a\rÄ\225ÆO\025É\r\016\n\"\207", stack_depth=6, constants_data=0xa386390) at bytecode.c:746 #23 0x004181ce in funcall_compiled_function (fun=171499748, nargs=1, args=0x2e4ba14) at bytecode.c:518 #24 0x004552c7 in Ffuncall (nargs=2, args=0x2e4ba10) at eval.c:3563 #25 0x00418907 in execute_optimized_program (program=0xa4f9710 "À\tÂ\"\eÄ\013\r\"£\211\036\006«\030Ç\016\006!«\022ÈÉÊ\217Ëa¬\n\t\016\fB\211\026\fªw\016\r¬\021ÎÏ!¬\006ÐÑ!«\aÒ Óa«\006Ô\t!ª^Õ\013È\"¬\016Ö×Ø\013Ù\"\"\210Ô\t!ªKÚÛÜ!È\211ÙÝÞ\016\037à#áâOãä!\036%\036&\036'\036(\036)\036*\036+ì\216íÜÙ\"\210\013î B\rB\025\212ï\016%!q\210\013À\tð\"\tE\0261Ù\026\034ò\0263ô\013!.\t*\20734\n 87 87 87 \t\tgrey34\n 89 89 89 \t\tgray"..., stack_depth=10, constants_data=0xa2b7310) at bytecode.c:746 #26 0x004181ce in funcall_compiled_function (fun=171361800, nargs=1, args=0x2e4bba4) at bytecode.c:518 #27 0x004552c7 in Ffuncall (nargs=2, args=0x2e4bba0) at eval.c:3563 #28 0x00418907 in execute_optimized_program (program=0xa746e10 "eÀÁ\211\211\211\211\032\e\034\035\036\006\036\a\211\036\b\203ô", stack_depth=8, constants_data=0xa369810) at bytecode.c:746 #29 0x004181ce in funcall_compiled_function (fun=170420480, nargs=0, args=0x2e4bd34) at bytecode.c:518 #30 0x004552c7 in Ffuncall (nargs=1, args=0x2e4bd30) at eval.c:3563 #31 0x00418907 in execute_optimized_program (program=0xa4de450 "\b\021\n«\fÃ\n@!\210\nA\211\022¬öÄ \210Å\036\006Ç \210È \210É )\207¸Ö\005\n", stack_depth=3, constants_data=0xa3250d0) at bytecode.c:746 #32 0x004181ce in funcall_compiled_function (fun=170420900, nargs=1, args=0x2e4bea4) at bytecode.c:518 #33 0x004552c7 in Ffuncall (nargs=2, args=0x2e4bea0) at eval.c:3563 #34 0x00418907 in execute_optimized_program (program=0x2e4bf0c "\212ÀÁ!q\210 \210\013c\210Äp!\025)\016\006\016\a}\210ed|\210È\r!\210É\211\211\036\n\036\013\036\f\016\r«\"\016\r@\026\n\016\rA\026\rÎ\016\nÏ\"\026\fÐ\016\f\016\021\"£\026\013ÉÒÓ\217\210ªÜ+\016\024«\025\016\024ÕH«\017Ö`×\"\210Ø\016\024ÕH!\210ª\004eb\210\016\031¬\nÚ Ûa¬\004Ü \210ÝÞ!\210~\207K", stack_depth=3, constants_data=0xa369610) at bytecode.c:746 #35 0x0041c228 in Fbyte_code (instructions=170944644, constants=171349504, stack_depth=7) at bytecode.c:2405 #36 0x00454685 in Feval (form=170808800) at eval.c:3331 #37 0x0045b0b9 in Fprogn (args=170802488) at eval.c:775 #38 0x004194b8 in execute_rare_opcode (stack_ptr=0x2e4c220, program_ptr=0xa2ebf22 "+\207\200&\021\n\004P\t\n", opcode=Bsave_window_excursion) at bytecode.c:1239 #39 0x004186fe in execute_optimized_program (program=0xa2ebf10 "\b¬\004Á \210\n\013{\034Å\036\006Ç\036\bÉ\213+\207\200&\021\n\004P\t\n", stack_depth=2, constants_data=0xa2ebfd0) at bytecode.c:656 #40 0x004181ce in funcall_compiled_function (fun=170421012, nargs=2, args=0x2e4c394) at bytecode.c:518 #41 0x004552c7 in Ffuncall (nargs=3, args=0x2e4c390) at eval.c:3563 #42 0x00418907 in execute_optimized_program (program=0x2e4c40c "Æ`Ç\013È\"®\002ÉÆ\211\031\035\032\034\030ÊË!\210Ì\013!\210Í \025Î\013\f\r#\210Ï\n\f\r#\210\rb\210ÐÑ!\210Ò\f\rS\"\210\rb\210ÓÔ!\210Õ\036\031Ö\f\r×#\210)\rb\210ÊØ!\210-Õ\207\n.Ü", stack_depth=5, constants_data=0xa251c10) at bytecode.c:746 #43 0x0041c228 in Fbyte_code (instructions=169836548, constants=170204160, stack_depth=11) at bytecode.c:2405 #44 0x00454685 in Feval (form=170332356) at eval.c:3331 #45 0x00450ce7 in condition_case_1 (handlers=169989204, bfun=0x453d50 , barg=170332356, hfun=0x450d60 , harg=8772524) at eval.c:1651 #46 0x0045121e in condition_case_3 (bodyform=170332356, var=8772524, handlers=169989204) at eval.c:1729 #47 0x0041954f in execute_rare_opcode (stack_ptr=0x2e4c848, program_ptr=0xa2fdb59 "\207Æ\bÇ\"\210ÈÉÊ\b!\"\210ËÌ!\210Í\207", opcode=Bcondition_case) at bytecode.c:1271 #48 0x004186fe in execute_optimized_program (program=0xa2fdb50 "ÁÂ!«\006ÃÄÅ\217\207Æ\bÇ\"\210ÈÉÊ\b!\"\210ËÌ!\210Í\207", stack_depth=4, constants_data=0xa251b90) at bytecode.c:656 #49 0x004181ce in funcall_compiled_function (fun=170030348, nargs=1, args=0x2e4c9c4) at bytecode.c:518 #50 0x004552c7 in Ffuncall (nargs=2, args=0x2e4c9c0) at eval.c:3563 #51 0x00418907 in execute_optimized_program (program=0x2e4ca2c "ÂÃ\tP!\b!\207", stack_depth=3, constants_data=0xa282e70) at bytecode.c:746 #52 0x0041c228 in Fbyte_code (instructions=169839316, constants=170405472, stack_depth=7) at bytecode.c:2405 #53 0x00454685 in Feval (form=170317280) at eval.c:3331 #54 0x00450ce7 in condition_case_1 (handlers=169363688, bfun=0x453d50 , barg=170317280, hfun=0x450d60 , harg=7194628) at eval.c:1651 #55 0x0045121e in condition_case_3 (bodyform=170317280, var=7194628, handlers=169363688) at eval.c:1729 #56 0x0041954f in execute_rare_opcode (stack_ptr=0x2e4cde8, program_ptr=0xa12d89b "¬cÇâã\217¬]Ðä\013\"«\rÇåæ\217¬Qç\r!\210ªKè\013!«\021é\r!«\f\f«>ê\fëÇ#\210ª6ì\013!«\tíî\r!!\210ª)\f«\013ï\fð\r!®\002ñ\"\210Ð\013ò\"«\017\f¬\bó\rô\"\210ª\fÇ\024ª\bõ\f®\002\r!\210\f«\005ö\f!\210.\aô\207­Þ\034Èm", opcode=Bcondition_case) at bytecode.c:1271 #57 0x004186fe in execute_optimized_program (program=0xa12d810 "Æ Ç\211\211\211\211\034\031\032\e\030\0368È\216É\r!¬\r\r\024Ê\fË\"\025Ì\f!b\210Í\r!@\227\023Î\013Ï\"@\021\0169«=ÐÑ\013\"«7Ò\rÓ\"®\005Ô\rÕ\"\211\020«)Ö\b!\211\022«\"Ð\013\n\"¬\034×\r\nC\"\210Ø\rÙ\nÙQC\"\210Í\r!@\227\023Î\013Ï\"@\021Ú\r\0167\"«\rÇÛÜ\217¬vÇÝÞ\217¬pß\r\0167\"«\rÇàá\217¬cÇâã\217¬]Ðä\013\"«\rÇåæ\217¬Qç\r!\210ªKè\013!«\021é\r!«\f\f«>ê\fëÇ#\210ª6ì\013!«\tíî\r!!\210ª)\f"..., stack_depth=6, constants_data=0xa294f10) at bytecode.c:656 #58 0x004181ce in funcall_compiled_function (fun=170030264, nargs=1, args=0x2e4cf64) at bytecode.c:518 #59 0x004552c7 in Ffuncall (nargs=2, args=0x2e4cf60) at eval.c:3563 #60 0x00418907 in execute_optimized_program (program=0xa30d810 "Æ\031\016\021Ã=«BÆ\211\211\211\034\035\e\032Ç\b!\025È\r!\237\025\r«#\n¬ É\r@!@\024Ê\r@Ë\"¬\006Ì\f!«\b\r@\023Ë\022ªâ\rA\211\025¬ß\013®\005Ç\b!@\021,ª\\\016\021Í=«VÆ\211\211\211\211\034\035\036\020\e\032Ç\b!\025È\r!\237\211\025«2\n¬/É\r@!@\024Ê\r@Ë\"«\017Î\r@Æ\"«\b\r@\023Ë\022ª\016\016\020¬\nÌ\f!«\005\r@\026\020\rA\211\025¬Ð\013®\t\016\020®\005Ç\b!@\021-Ï\t!)\207", stack_depth=6, constants_data=0xa251a10) at bytecode.c:746 #61 0x004181ce in funcall_compiled_function (fun=170030712, nargs=1, args=0x2e4d0e4) at bytecode.c:518 #62 0x004552c7 in Ffuncall (nargs=2, args=0x2e4d0e0) at eval.c:3563 #63 0x00418907 in execute_optimized_program (program=0x2e4d14c "ÂÃ\tP!\b!\207", stack_depth=3, constants_data=0xa282e70) at bytecode.c:746 #64 0x0041c228 in Fbyte_code (instructions=169839316, constants=170405472, stack_depth=7) at bytecode.c:2405 #65 0x00454685 in Feval (form=170317280) at eval.c:3331 #66 0x00450ce7 in condition_case_1 (handlers=169363688, bfun=0x453d50 , barg=170317280, hfun=0x450d60 , harg=7194628) at eval.c:1651 #67 0x0045121e in condition_case_3 (bodyform=170317280, var=7194628, handlers=169363688) at eval.c:1729 #68 0x0041954f in execute_rare_opcode (stack_ptr=0x2e4d508, program_ptr=0xa12d89b "¬cÇâã\217¬]Ðä\013\"«\rÇåæ\217¬Qç\r!\210ªKè\013!«\021é\r!«\f\f«>ê\fëÇ#\210ª6ì\013!«\tíî\r!!\210ª)\f«\013ï\fð\r!®\002ñ\"\210Ð\013ò\"«\017\f¬\bó\rô\"\210ª\fÇ\024ª\bõ\f®\002\r!\210\f«\005ö\f!\210.\aô\207­Þ\034Èm", opcode=Bcondition_case) at bytecode.c:1271 #69 0x004186fe in execute_optimized_program (program=0xa12d810 "Æ Ç\211\211\211\211\034\031\032\e\030\0368È\216É\r!¬\r\r\024Ê\fË\"\025Ì\f!b\210Í\r!@\227\023Î\013Ï\"@\021\0169«=ÐÑ\013\"«7Ò\rÓ\"®\005Ô\rÕ\"\211\020«)Ö\b!\211\022«\"Ð\013\n\"¬\034×\r\nC\"\210Ø\rÙ\nÙQC\"\210Í\r!@\227\023Î\013Ï\"@\021Ú\r\0167\"«\rÇÛÜ\217¬vÇÝÞ\217¬pß\r\0167\"«\rÇàá\217¬cÇâã\217¬]Ðä\013\"«\rÇåæ\217¬Qç\r!\210ªKè\013!«\021é\r!«\f\f«>ê\fëÇ#\210ª6ì\013!«\tíî\r!!\210ª)\f"..., stack_depth=6, constants_data=0xa294f10) at bytecode.c:656 #70 0x004181ce in funcall_compiled_function (fun=170030264, nargs=1, args=0x2e4d684) at bytecode.c:518 #71 0x004552c7 in Ffuncall (nargs=2, args=0x2e4d680) at eval.c:3563 #72 0x00418907 in execute_optimized_program (program=0xa2fdbd0 "Â\b!\211\031«\fÃ\t@!\210\tA\211\021¬ö)Ä\207&\021\n\004P\t\n", stack_depth=3, constants_data=0xa250d50) at bytecode.c:746 #73 0x004181ce in funcall_compiled_function (fun=170030684, nargs=1, args=0x2e4d7f4) at bytecode.c:518 #74 0x004552c7 in Ffuncall (nargs=2, args=0x2e4d7f0) at eval.c:3563 #75 0x00418907 in execute_optimized_program (program=0x2e4d85c "ÂÃ\tP!\b!\207", stack_depth=3, constants_data=0xa282e70) at bytecode.c:746 #76 0x0041c228 in Fbyte_code (instructions=169839316, constants=170405472, stack_depth=7) at bytecode.c:2405 #77 0x00454685 in Feval (form=170317280) at eval.c:3331 #78 0x00450ce7 in condition_case_1 (handlers=169363688, bfun=0x453d50 , barg=170317280, hfun=0x450d60 , harg=7194628) at eval.c:1651 #79 0x0045121e in condition_case_3 (bodyform=170317280, var=7194628, handlers=169363688) at eval.c:1729 #80 0x0041954f in execute_rare_opcode (stack_ptr=0x2e4dc18, program_ptr=0xa12d89b "¬cÇâã\217¬]Ðä\013\"«\rÇåæ\217¬Qç\r!\210ªKè\013!«\021é\r!«\f\f«>ê\fëÇ#\210ª6ì\013!«\tíî\r!!\210ª)\f«\013ï\fð\r!®\002ñ\"\210Ð\013ò\"«\017\f¬\bó\rô\"\210ª\fÇ\024ª\bõ\f®\002\r!\210\f«\005ö\f!\210.\aô\207­Þ\034Èm", opcode=Bcondition_case) at bytecode.c:1271 #81 0x004186fe in execute_optimized_program (program=0xa12d810 "Æ Ç\211\211\211\211\034\031\032\e\030\0368È\216É\r!¬\r\r\024Ê\fË\"\025Ì\f!b\210Í\r!@\227\023Î\013Ï\"@\021\0169«=ÐÑ\013\"«7Ò\rÓ\"®\005Ô\rÕ\"\211\020«)Ö\b!\211\022«\"Ð\013\n\"¬\034×\r\nC\"\210Ø\rÙ\nÙQC\"\210Í\r!@\227\023Î\013Ï\"@\021Ú\r\0167\"«\rÇÛÜ\217¬vÇÝÞ\217¬pß\r\0167\"«\rÇàá\217¬cÇâã\217¬]Ðä\013\"«\rÇåæ\217¬Qç\r!\210ªKè\013!«\021é\r!«\f\f«>ê\fëÇ#\210ª6ì\013!«\tíî\r!!\210ª)\f"..., stack_depth=6, constants_data=0xa294f10) at bytecode.c:656 #82 0x004181ce in funcall_compiled_function (fun=170030264, nargs=1, args=0x2e4dd94) at bytecode.c:518 #83 0x004552c7 in Ffuncall (nargs=2, args=0x2e4dd90) at eval.c:3563 #84 0x00418907 in execute_optimized_program (program=0xa16e010 "Æ \210\f«\017Ç\f!¬\005ÈÉ!\210\fq\210ª\013\016;Ê>¬\005ÈË!\210Ì \210Í \210Î \210\0166¬\b\b¬\005ÈÏ!\210\b«\020Ð\t@!\210\0164q\210\b \210\202í", stack_depth=6, constants_data=0xa28e610) at bytecode.c:746 #85 0x004181ce in funcall_compiled_function (fun=170030236, nargs=0, args=0x2e4de6c) at bytecode.c:518 #86 0x004549bb in Feval (form=169843376) at eval.c:3388 #87 0x00450ce7 in condition_case_1 (handlers=170426016, bfun=0x453d50 , barg=169843376, hfun=0x450d60 , harg=7319044) at eval.c:1651 #88 0x0045121e in condition_case_3 (bodyform=169843376, var=7319044, handlers=170426016) at eval.c:1729 #89 0x0041954f in execute_rare_opcode (stack_ptr=0x2e4e1c8, program_ptr=0xa30db2f "\210Ì\013!«2È\r@!«,\r@ÍHÎHÏ\r@!ZÐV\211\032«\005ÑÒ!\210Ã\013Ï\r@!\r@ÍHÎH#\210\n«\005ÑÓ!\210)p\036(Ô\216\212\212eb\210~\210`\r@ÍHÎH}\210)\016)«\016Õ\016*!«\005Ö×!\210Ø \210)Ùp!«M\212Ú\026\034\f«\aÛ\fÜÚ#\210\f«\017Ý\f!¬\005Þß!\210\fq\210ª\013\016+à>¬\005Þá!\210\r@âHÍH«\aã\r@ä\"\210\r@âH×H«\aå\r@ä\"\210)æ \210ç ª\003æ *\207", opcode=Bcondition_case) at bytecode.c:1271 #90 0x004186fe in execute_optimized_program (program=0xa30db10 "\t«\036\b«\e\f«\bÆ\fÇ\"?ª\004\016\a?«\fÈ\r@!¬\006ÉÊË\217\210Ì\013!«2È\r@!«,\r@ÍHÎHÏ\r@!ZÐV\211\032«\005ÑÒ!\210Ã\013Ï\r@!\r@ÍHÎH#\210\n«\005ÑÓ!\210)p\036(Ô\216\212\212eb\210~\210`\r@ÍHÎH}\210)\016)«\016Õ\016*!«\005Ö×!\210Ø \210)Ùp!«M\212Ú\026\034\f«\aÛ\fÜÚ#\210\f«\017Ý\f!¬\005Þß!\210\fq\210ª\013\016+à>¬\005Þá!\210\r@âHÍH«\aã\r@ä\"\210\r@âH×H«\aå\r@ä\"\210)"..., stack_depth=6, constants_data=0xa2bdd10) at bytecode.c:656 #91 0x004181ce in funcall_compiled_function (fun=169366488, nargs=0, args=0x2e4e344) at bytecode.c:518 #92 0x004552c7 in Ffuncall (nargs=1, args=0x2e4e340) at eval.c:3563 #93 0x00418907 in execute_optimized_program (program=0xa2b2010 "p\031Æ\216Ç\020È\026\037\0162«\006É\r@!\210\212\f«\017Ê\f!¬\005ËÌ!\210\fq\210ª\013\0163Í>¬\005ËÎ!\210Ï\r@Ð\"\210\016\023«\017\r@ÑHÒH«\aÏ\r@Ó\"\210\016\025«\017\r@ÑHÔH«\aÏ\r@Õ\"\210)Ö \210\0164¬\021×\0165!¬\013\016.«'Ø\r@!¬!Ù\r@!\0366Ú\r@!\210p\031Û\216Üp\013\"\210*\013q\210Ç\020Ö \210)ª\rÈ\023\016/«\aÜ\016/p\"\210Ýp!\210\016.«6\0167«2\0168«.\0160«*\f«\bÞ\fß\"?ª\004\016\037?«\eØ\r@!¬\025à\0161"..., stack_depth=5, constants_data=0xa2bde10) at bytecode.c:746 #94 0x004181ce in funcall_compiled_function (fun=169366460, nargs=0, args=0x2e4e4c4) at bytecode.c:518 #95 0x004552c7 in Ffuncall (nargs=1, args=0x2e4e4c0) at eval.c:3563 #96 0x00418907 in execute_optimized_program (program=0x2e4e53c "Æ\n!?Ç\211\211\211\211\031\030\036@\036I\036C\034Æ\n!«\004\nªh\n®\aÈ\016J\016D\"\eÉ\013!«\aÊË\013\"ªRÌ\013!®M\016D«\aÈ\016D!®\003\016KÍÇ\211\016L«\004Ϊ\t\016M«\004Ϊ\002Ï\036S\036T\036U\036V\036KÐÑ\013\"\210Ò\013!\n®\003\016J\211\036N\016E@\232¬\b\016N\016EB\026E)ÐÓ\013\"\210-)\211\026Iq\210\016F«\t\016W«\005ÔÇ!\210\016L¬\005\016M«@Õ\r!ÕÖ!=¬7Õ\r!Õ×!=¬.Õ\r!ÕØ!=¬%Õ\r!ÕÙ!=¬\034ÇÚ \036O\036GÛ\216Ü"..., stack_depth=7, constants_data=0xa180410) at bytecode.c:746 #97 0x0041c228 in Fbyte_code (instructions=168515972, constants=169346048, stack_depth=15) at bytecode.c:2405 #98 0x00454685 in Feval (form=168161476) at eval.c:3331 #99 0x0045ae10 in internal_catch (tag=7960140, func=0x453d50 , arg=168161476, threw=0x0) at eval.c:1317 #100 0x004194fd in execute_rare_opcode (stack_ptr=0x2e4ee74, program_ptr=0xa1651f6 "\207\n`\220\r\n", opcode=Bcatch) at bytecode.c:1252 #101 0x004186fe in execute_optimized_program (program=0xa1651f0 "À \210ÁÂ\215\207\n`\220\r\n", stack_depth=2, constants_data=0xa17cab0) at bytecode.c:656 #102 0x004181ce in funcall_compiled_function (fun=9529796, nargs=2, args=0x2e4efe4) at bytecode.c:518 #103 0x004552c7 in Ffuncall (nargs=3, args=0x2e4efe0) at eval.c:3563 #104 0x00418907 in execute_optimized_program (program=0xa1693d0 "Æ \210Ç \210\f«\004\fq\210È \210\r\022\t®\002\013\eÉ\r!\025)Ê\r\b\"\207¸Ö\005\n", stack_depth=3, constants_data=0xa17da10) at bytecode.c:746 #105 0x004181ce in funcall_compiled_function (fun=9529908, nargs=2, args=0x2e4f150) at bytecode.c:518 #106 0x004552c7 in Ffuncall (nargs=3, args=0x2e4f14c) at eval.c:3563 #107 0x00455dc0 in Fapply (nargs=2, args=0x2e4f1cc) at eval.c:3804 #108 0x0045a38c in apply1 (fn=9529908, arg=169774500) at eval.c:4157 #109 0x0041d754 in Fcall_interactively (function=168546980, record_flag=7194652, keys=7194628) at callint.c:397 #110 0x004537f7 in Fcommand_execute (cmd=168546980, record_flag=7194652, keys=7194628) at eval.c:2970 #111 0x00455138 in Ffuncall (nargs=3, args=0x2e4f4b0) at eval.c:3528 #112 0x00418907 in execute_optimized_program (program=0xa158110 "\r\035Æ\rÇa«\004Ȫ$\rÉk«\004ʪ\034\r¨«\aËÌ\r\"ª\022\r:«\r\r@¨«\bËÌ\r@\"ª\002Í!\024)\t«Kt«HÎ\f!\f\032\eÏ\fÐ\"\210\013­8\b¬\023Ñ Ò a«\aÓ pa«\006Ô \210ª\004Õ \210Ö×!­\eØÙË\013A«\004Úª\002Û\nÜ\013!#\"\210Ö\016\036!\210ÝÙ!*\207Ï\fÐ\"\207", stack_depth=7, constants_data=0x7ad810) at bytecode.c:746 #113 0x004181ce in funcall_compiled_function (fun=8048612, nargs=1, args=0x2e4f640) at bytecode.c:518 #114 0x004552c7 in Ffuncall (nargs=2, args=0x2e4f63c) at eval.c:3563 #115 0x0041f2c4 in Fcall_interactively (function=8078348, record_flag=7194628, keys=7194628) at callint.c:940 #116 0x004537f7 in Fcommand_execute (cmd=8078348, record_flag=7194628, keys=7194628) at eval.c:2970 #117 0x004de181 in execute_command_event (command_builder=0xa09abc0, event=168887784) at event-stream.c:3911 #118 0x004dee86 in Fdispatch_event (event=168887784) at event-stream.c:4243 #119 0x004282d4 in Fcommand_loop_1 () at cmdloop.c:583 #120 0x0042865e in command_loop_1 (dummy=7194628) at cmdloop.c:494 #121 0x00450ce7 in condition_case_1 (handlers=7194724, bfun=0x428620 , barg=7194628, hfun=0x4286f8 , harg=7194628) at eval.c:1651 #122 0x004287eb in command_loop_2 (dummy=7194628) at cmdloop.c:256 #123 0x0045ae10 in internal_catch (tag=7274740, func=0x4287b0 , arg=7194628, threw=0x0) at eval.c:1317 #124 0x00427b1e in initial_command_loop (load_me=7194628) at cmdloop.c:305 #125 0x0044acd3 in xemacs_21_5_b0_i686_pc_cygwin () at emacs.c:2344 #126 0x0044e359 in main () at emacs.c:2773 #127 0x61003c02 in ?numDevices@OSinterface@@2HA () #128 0x61003ddd in ?numDevices@OSinterface@@2HA () #129 0x61003e1c in ?numDevices@OSinterface@@2HA () #130 0x006c990b in cygwin_crt0 () ;; This buffer is for notes you don't want to save, and for Lisp evaluation. ;; If you want to create a file, first visit that file with C-x C-f, ;; then enter the text in that file's own buffer. (gdb) where 10 #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices@OSinterface@@2HA () #2 0x005a9256 in re_match_2_internal (bufp 96924, string1, size1 46d5b8 ":/images/ejbbook_anim.gif", size2%, pos!, regs 97160, stop%) at regex.c:5463 #3 0x005a59dd in re_search_2 (bufp 96924, str1, size1 46d5b8 ":/images/ejbbook_anim.gif", size2%, startpos!, range%, regs 97160, stop%) at regex.c:4162 #4 0x005aaec2 in re_search (bufp 96924, string 46d5b8 ":/images/ejbbook_anim.gif", size%, startpos nge%, regs 97160) at regex.c:3924 #5 0x005abd31 in string_match_1 (regexp1379396, string0653492, startq94628, buf 747c00, posix t search.c:411 #6 0x005b11f5 in Fstring_match (regexp1379396, string0653492, startq94628, bufferq94628) at search.c:434 #7 0x00455151 in Ffuncall (nargs:rgse4b570) at eval.c:3528 #8 0x00418907 in execute_optimized_program (program 734f90 "\bÁ\032\e\013«!\n¬\036\013@@Ķ¬\021ÅÆ\013@@ÇQ\016\b\"«\005É\022ªä\013A\211\023¬á\n«\fÊ\013@@Ë\016\bQ!ª4ÅÌ\016\b\"«\tÊÍ\016\bP!ª%ÅÎ\016\b\"«\tÊÍ\016\bP!ª\026ÏÐ\016\b\"\211\023«\006Ê\013!ª\bÊÑ\016\bÒQ!*\207", stack_depth\onstants_data 2f2b90) at bytecode.c:746 #9 0x004181ce in funcall_compiled_function (fun1328220, nargsrgse4b6f4) at bytecode.c:518 (More stack frames follow...) (gdb) where 10 #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices@OSinterface@@2HA () #2 0x005d18a9 in xemacs_stat (path 801fb4 "/this/is/a/highly/unlikely/directory/name/cache/philipa/http//www/a1a56668f2a4bc987ac64aaed898f3ec", bufe4aca4) at sysdep.c:3110 #3 0x004fd14f in Ffile_exists_p (filename0940356) at fileio.c:2257 #4 0x0045510c in Ffuncall (nargs*rgse4ada0) at eval.c:3528 #5 0x00418907 in execute_optimized_program (program 47e510 "À\t!\032Ã\n!\034\n­\020Å\n!­\013\f@Æa?­\004Ç\f8*\207\200'\021\n`4\013\n\200*\021\nkk", stack_depth,onstants_data 47e590) at bytecode.c:746 #6 0x004181ce in funcall_compiled_function (fun0896764, nargsrgse4af50) at bytecode.c:518 #7 0x004552c7 in Ffuncall (nargs*rgse4af4c) at eval.c:3563 #8 0x00418907 in execute_optimized_program (program 7f9810 "À\031À\032ÃÄ!\035ÆÇ\016\b\"£\036\tÆÊ\016\b\"£®\nËÌ!?®\004\016\r??­\r\016\016\036\017Ð\016\rÀÑÀ$)\036\022ËÌ!­\t\016\f­\005Ó\016\f!\211\036\024«\a\016\024ÕHª\003\016\026\036\027\016\024«\a\016\024ØH®\005\016\031ØH\036\032ÆÛ\016\b\"£?­\020ÐËÌ!«\005\016\f®\002\rÀÑÀ$\036\034\016\t­\006ÝÞ\016\t\"\026\t\016\034«\bß\016\034àQ\026\034\016\022«\bá\016\022àQ\026\022\016\"«\025\016\";«\020\016\"ã\230¬\a\016\"ä\230«\004À\026\"\016%æs¬\f\016%<«\nç\016%s«\004À\026\"èé\016"..., stack_depth#, constants_data 282e10) at bytecode.c:746 #9 0x004181ce in funcall_compiled_function (fun2305732, nargs*rgse4b0d4) at bytecode.c:518 (More stack frames follow...) (gdb) where 10 #0 alarm_signal (signo) at signal.c:167 #1 0x6100e5df in ?numDevices@OSinterface@@2HA () #2 0x00451a25 in call_with_suspended_errors_1 (opaque_arg7864512) at opaque.h:63 #3 0x00451eeb in call_with_suspended_errors (fun766a8 , retval`64412, classs33964, errb#4 0x005bed26 in specifier_instance_from_inst_list (specifier“62496, matchspec`64412, domain0209792, inst_list’93604, errb#5 0x005bf106 in specifier_instance (specifier“62496, matchspec`64412, domain0209792, errb#6 0x004f5156 in update_face_cachel_data (cachele4a454, domain0209792, face’70656) at faces.c:1318 #7 0x00525ee3 in query_string_geometry (stringu18596, face’70656, widthe4a4fc, heighte4a500, descent, domain9424896) at glyphs.c:2285 #8 0x005378bd in tab_control_query_geometry (image_instance0467072, widthe4a5a0, heighte4a59c, disp#9 0x00536bad in widget_query_geometry (image_instance0467072, widthe4a5a0, heighte4a59c, disp(More stack frames follow...) From npak@ispras.ru Mon May 7 09:11:12 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id JAA04437 for ; Mon, 7 May 2001 09:10:59 -0400 Received: (qmail 34879 invoked from network); 7 May 2001 13:10:47 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 7 May 2001 13:10:47 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f47DAUU24300; Mon, 7 May 2001 17:10:31 +0400 (MSK) Received: tid RAA05692; Tue, 7 May 1996 17:11:00 +0300 Received: from dallas.kazbek.ispras.ru (dallas.kazbek.ispras.ru [194.186.94.155]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f47DB7g55669; Mon, 7 May 2001 17:11:07 +0400 (MSD) (envelope-from npak@ispras.ru) Received: (from npak@localhost) by dallas.kazbek.ispras.ru (8.9.3/8.9.3) id RAA31894; Mon, 7 May 2001 17:12:52 +0400 X-Authentication-Warning: dallas.kazbek.ispras.ru: npak set sender to npak@ispras.ru using -f Sender: npak@kazbek.ispras.ru To: Steve Youngs Cc: XEmacs Beta Subject: Re: find-function & load-history References: <15091.58000.258819.143117@turnbull.sk.tsukuba.ac.jp> From: npak@ispras.ru (Nick V. Pakoulin) Date: 07 May 2001 17:12:52 +0400 In-Reply-To: Steve Youngs's message of "06 May 2001 05:30:49 +1000" Message-ID: Lines: 18 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Urania) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii intro: "SY" == Steve Youngs writes: SY> |--==> "SJT" == Stephen J Turnbull writes: >>>>>>> "SY" == Steve Youngs writes: SY> How can I make [find-function] show me [...] the installed version? SJT> (setq find-function-source-path nil) should work. SY> Nope, tried that. It doesn't work, sorry. Any other ideas? Replace in `load-history' filenames for dumped filee. Make an evil hack: (dolist (entry load-history) (when (string-match "/build/directory/" (car entry)) (setcar entry (replace-match "/installation/directory/" t t (car entry))))) Nick. From kasahara@nc.kyushu-u.ac.jp Mon May 7 09:27:48 2001 Received: from elvenbow.nc.kyushu-u.ac.jp (elvenbow.nc.kyushu-u.ac.jp [133.5.6.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA05837 for ; Mon, 7 May 2001 09:27:45 -0400 Received: from localhost (kasahara@elvenbow.nc.kyushu-u.ac.jp [127.0.0.1]) by elvenbow.nc.kyushu-u.ac.jp (8.11.3/8.11.1) with ESMTP id f47DReP93834 for ; Mon, 7 May 2001 22:27:41 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Mon, 07 May 2001 22:27:40 +0900 (JST) Message-Id: <20010507.222740.749333612.kasahara@nc.kyushu-u.ac.jp> To: xemacs-beta@xemacs.org Subject: Re: make-charset doesn't handle 'short-name' properly From: Yoshiaki Kasahara In-Reply-To: <20010425.171837.884091679.kasahara@nc.kyushu-u.ac.jp> References: <20010425.171837.884091679.kasahara@nc.kyushu-u.ac.jp> X-Mailer: Mew version 1.95b121 on XEmacs 21.5-b0 (alfalfa) X-Fingerprint: 31 DC 9F DF C2 B9 8E 00 3A 7C 4F 0C 03 D8 AC 16 X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Excuse me, would someone please respond ? Is this patch pointless?? On Wed, 25 Apr 2001 17:18:37 +0900 (JST), Yoshiaki Kasahara said: > Accidentally I noticed that 'make-charset' doesn't handle a property > 'short-name' correctly. > > Here is a patch for that. > > Index: mule-charset.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-charset.c,v > retrieving revision 1.19 > diff -u -r1.19 mule-charset.c > --- mule-charset.c 2001/04/12 18:24:03 1.19 > +++ mule-charset.c 2001/04/25 08:03:28 > @@ -693,7 +693,7 @@ > short_name = value; > } > > - if (EQ (keyword, Qlong_name)) > + else if (EQ (keyword, Qlong_name)) > { > CHECK_STRING (value); > long_name = value; > > -- > Yoshiaki Kasahara > Computing and Communications Center, Kyushu University > kasahara@nc.kyushu-u.ac.jp > From steve@turnbull.sk.tsukuba.ac.jp Mon May 7 09:43:47 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA07307 for ; Mon, 7 May 2001 09:43:46 -0400 Received: by localhost id m14wlAN-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 7 May 2001 22:35:11 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.42127.500272.825010@turnbull.sk.tsukuba.ac.jp> Date: Mon, 7 May 2001 22:35:11 +0900 To: rendhalver@users.sourceforge.net Cc: xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: <15092.19426.99706.609676@ulthwe.dyndns.org> References: <15092.4694.989469.685700@ulthwe.dyndns.org> <15092.16726.63690.956636@ulthwe.dyndns.org> <15092.19426.99706.609676@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Peter" == Peter Brown writes: Peter> just thought could it be a problem with my packages tree ?? Peter> should i create it again and give it another go could have Peter> gotten stuffed up while i was playing with cvs versions of Peter> the packages Well, take a look at "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/dired/" which _is_ in your load-path, and should contain dired.el and dired.elc. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Mon May 7 09:49:12 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA07918 for ; Mon, 7 May 2001 09:49:09 -0400 Received: by localhost id m14wlFm-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 7 May 2001 22:40:46 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> Date: Mon, 7 May 2001 22:40:46 +0900 To: Norbert Koch Cc: xemacs-beta@xemacs.org Subject: Byte-compiler tests fail In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "NK" == Norbert Koch writes: NK> Unexpected error (void-function defadvice) while executing NK> interpreted code. These are functions defined in packages. Are you perhaps using --with-prefix=no? That has caused this problem in the past. (With that setting, installed packages cannot be found from a run-in-place xemacs -- including during the build process.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From nk@lamia.lf.net Mon May 7 09:57:46 2001 Received: from lamia.lf.net (lamia.LF.net [212.9.160.192]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA08966 for ; Mon, 7 May 2001 09:57:45 -0400 Received: by lamia.lf.net (Smail3.2.0.111/lamia.lf.net) via LF.net GmbH Internet Services for mail.xemacs.org id m14wlVY-001Sq4C; Mon, 7 May 2001 15:57:04 +0200 (CEST) Sender: nk@lamia.lf.net (Norbert Koch) To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Byte-compiler tests fail References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> Organization: LF.net GmbH X-Attribution: viteno X-NCC-RegID: de.lfnet X-URL: http://www.LF.net/ X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R: lt{Y/s1g[=5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 07 May 2001 15:57:02 +0200 In-Reply-To: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Mon, 7 May 2001 22:40:46 +0900") Message-ID: Lines: 29 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: Hi Stephen. >>>>>> "NK" == Norbert Koch writes: > > NK> Unexpected error (void-function defadvice) while executing > NK> interpreted code. > > These are functions defined in packages. > > Are you perhaps using --with-prefix=no? That has caused this problem > in the past. (With that setting, installed packages cannot be found > from a run-in-place xemacs -- including during the build process.) No, I've got a prefix defined. Could it be a problem that I build xemacs-packages out of CVS using a make install, ie I've got a symlinked package tree? The call to configure is ./configure --prefix=/sw/i386_fbsd4/xemacs-21.5 \ '--site-includes=/client/include /usr/local/include' \ '--site-libraries=/client/lib /usr/local/lib' \ --use-union-type --with-mule --pdump norbert. From steve@turnbull.sk.tsukuba.ac.jp Mon May 7 10:21:59 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA11206 for ; Mon, 7 May 2001 10:21:58 -0400 Received: by localhost id m14wllL-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 7 May 2001 23:13:23 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> Date: Mon, 7 May 2001 23:13:23 +0900 To: Norbert Koch Cc: xemacs-beta@xemacs.org, sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Subject: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] In-Reply-To: References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "NK" == Norbert Koch writes: NK> The byte-compiler-test fail at the moment: NK> Testing NK> /usr/local/users/support/nk/cvs/xemacs/tests/automated/byte-compiler-tests.el NK> Unexpected error (void-function defadvice) while executing interpreted code. >> Are you perhaps using --with-prefix=no? That has caused this >> problem in the past. (With that setting, installed packages >> cannot be found from a run-in-place xemacs -- including during >> the build process.) NK> No, I've got a prefix defined. --with-prefix=no is compatible with --prefix=..., it says "don't build $prefix into the executable". NK> Could it be a problem that I build xemacs-packages out of CVS NK> using a make install, ie I've got a symlinked package tree? Don't think so. Where exactly are your packages? What does `src/xemacs --debug-paths' say? We're looking for /sw/i386_fbsd4/xemacs-21.5 in emacs-roots, and the package directories relative to that in load-path. Two more tries: If they are relative to (eg) /sw/i386_fbsd4/xemacs/, they won't be found. If this has suddenly stopped working with the move to 21.5, is it possible that you've started a new source tree, and the old one had a symlink $srcdir/xemacs-packages -> /path/to/xemacs-packages? AFAIK, although XEmacs doesn't like to keep symlinks around, it achieve that goal by chasing them until they hit a real target, not by discarding them. So they should end up in load-path and be found, if they're rooted in ~/.xemacs, $executable/../, $prefix/, or relative to something in a --package-path directive to configure. That's all the package-root candidates AFAIK. Michael? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From rendhalver@users.sourceforge.net Mon May 7 10:34:46 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA12226 for ; Mon, 7 May 2001 10:34:44 -0400 Received: from ulthwe.dyndns.org (p169-tnt1.brs.ihug.com.au [203.173.188.169]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id AAA04272; Tue, 8 May 2001 00:34:32 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p169-tnt1.brs.ihug.com.au [203.173.188.169] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15094.45553.399900.271343@ulthwe.dyndns.org> Date: Tue, 8 May 2001 00:32:17 +1000 To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: promblem with xemacs 21.5 In-Reply-To: <15094.42127.500272.825010@turnbull.sk.tsukuba.ac.jp> References: <15092.4694.989469.685700@ulthwe.dyndns.org> <15092.16726.63690.956636@ulthwe.dyndns.org> <15092.19426.99706.609676@ulthwe.dyndns.org> <15094.42127.500272.825010@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Stephen J. Turnbull writes: > >>>>> "Peter" == Peter Brown writes: > > Peter> just thought could it be a problem with my packages tree ?? > Peter> should i create it again and give it another go could have > Peter> gotten stuffed up while i was playing with cvs versions of > Peter> the packages > > Well, take a look at > > "/usr/local/xemacs-beta/lib/xemacs/xemacs-packages/lisp/dired/" > > which _is_ in your load-path, and should contain dired.el and > dired.elc. thanks stephen got this fixed, it looks like i had stuffed my packages tree reinstalled it and all was fine -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From youngs@xemacs.org Mon May 7 10:54:10 2001 Received: from mail003.syd.optusnet.com.au (mail003.syd.optusnet.com.au [203.2.75.251]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA13892 for ; Mon, 7 May 2001 10:54:08 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail003.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f47ErxO01042 for ; Tue, 8 May 2001 00:53:59 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f47Epph0008191; Tue, 8 May 2001 00:51:51 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Byte-compiler tests fail References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 08 May 2001 00:51:51 +1000 In-Reply-To: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Mon, 7 May 2001 22:40:46 +0900") Message-ID: Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "SJT" == Stephen J Turnbull writes: >>>>>>"NK" == Norbert Koch writes: NK> Unexpected error (void-function defadvice) while executing NK> interpreted code. SJT> These are functions defined in packages. SJT> Are you perhaps using --with-prefix=no? That has caused this problem SJT> in the past. (With that setting, installed packages cannot be found SJT> from a run-in-place xemacs -- including during the build process.) XEmacs should build fine without _any_ packages installed. I haven't done it for a while, so I'll test and let you know if it still works. And if all the tests pass. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From jason-dated-989941936.4fe02f@mastaler.com Mon May 7 11:52:22 2001 Received: from sclp3.sclp.com (sclp3.sclp.com [209.196.61.66]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id LAA19937 for ; Mon, 7 May 2001 11:52:21 -0400 Received: (qmail 15439 invoked from network); 7 May 2001 15:52:19 -0000 Received: from localhost (HELO nightshade.la.mastaler.com) (jason@127.0.0.1) by localhost with SMTP; 7 May 2001 15:52:19 -0000 Received: (qmail 9514 invoked by uid 500); 7 May 2001 15:52:16 -0000 From: "Jason R. Mastaler" To: Gabe Foster Cc: xemacs-beta@xemacs.org Subject: Re: [21.4.1] png.h errors on mips-sgi-irix6.5 References: <3AF3332F.D4D65685@sgrail.com> X-Face: "Whz7py/hGVg+:}u&Q$/5z>j)gy%qNRX{j]0xGF&?Z"^b3`[6dY'^jSDlZDHh$m1~YX6U3J 1gOce%&je3)lVMOa/P,=9Kj:lmZb6]1hMmam*SW$GrVPa>b05y9/svb[uX.i><]^; iE1^(p_*=eLQJ6g$[aOX9I#`DCP\^O=RR:7|95hZ Date: 07 May 2001 09:52:15 -0600 In-Reply-To: <3AF3332F.D4D65685@sgrail.com> (Gabe Foster's message of "Fri, 04 May 2001 17:54:39 -0500") Message-ID: Lines: 13 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Delivery-Agent: TMDA v0.12/Python 2.1 Gabe Foster writes: > I've seen this problem as well. SGI install an old version of png > in /usr/include and /usr/lib{n32,64,}. What I did was to point to > versions I had installed from from SGI's freeware base (and other > libraries I installed myself in /usr/include.) The problem went away after I installed the libpng package from SGI freeware. Thanks. -- (TMDA - http://tmda.sourceforge.net/) (OSI-certified SPAM reduction system) From andyp@bea.com Mon May 7 12:39:32 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA24750; Mon, 7 May 2001 12:39:31 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA05940; Mon, 7 May 2001 09:39:31 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001380wss.beasys.com [192.168.6.211]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA05184; Mon, 7 May 2001 09:40:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507093606.00b0a2b0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 09:37:23 -0700 To: Ben Wing , James LewisMoss From: Andy Piper Subject: Re: Update to last message Cc: xemacs-beta@xemacs.org, Andy Piper In-Reply-To: <3AF5EC2A.D0063822@666.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id MAA24750 At 05:28 PM 5/6/01 -0700, Ben Wing wrote: >thanks. this looks like andy's area of expertise. Given the number of bugs in the Tab widget, this is very likely to be a bug in the progress gauge widget. If you can find out the contents of the arguments to GaugeExpose it might indicate why its blowing up. andy >but if you can reproduce this, try running under a debugger, and printing out >the values of the variables in the call to XDrawLine in lwlib/xlwgauge.c >that's >causing the crash. > >as for the X errors, set a breakpoint on x_error_handler and see what's >causing >them. > > >James LewisMoss wrote: > > > > Here's a better backtrace: > > #0 0x401a8df0 in XDrawLine () from /usr/X11R6/lib/libX11.so.6 > > #1 0x8172cb6 in GaugeExpose (w=0x8760cc8, event=0xbfffd95c, > region=0x840cc80) at xlwgauge.c:425 > > #2 0x4014f905 in _XtEventInitialize () from /usr/X11R6/lib/libXt.so.6 > > #3 0x4014f5eb in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 > > #4 0x4014f334 in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 > > #5 0x4014fcee in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 > > #6 0x40150058 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 > > #7 0x4015a970 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 > > #8 0x8151964 in drain_X_queue () at event-Xt.c:2907 > > #9 0x8151a2e in emacs_Xt_event_pending_p (user_p=0) at event-Xt.c:3024 > > #10 0x80cb49f in event_stream_event_pending_p (user=0) at > event-stream.c:438 > > #11 0x80cd426 in Fdispatch_non_command_events () at event-stream.c:2386 > > #12 0x80a85c6 in Feval (form=138209552) at eval.c:3331 > > #13 0x80a6556 in condition_case_1 (handlers=138209048, bfun=0x80a817c > , barg=138209552, hfun=0x80a65ac , > harg=136170236) at eval.c:1651 > > #14 0x80a67df in condition_case_3 (bodyform=138209552, var=136170236, > handlers=138209048) at eval.c:1729 > > #15 0x808af8d in execute_rare_opcode (stack_ptr=0xbfffdcc0, > program_ptr=0x882a8cc "\207", opcode=Bcondition_case) at bytecode.c:1271 > > #16 0x808a50b in execute_optimized_program (program=0x882a8c8 > "ÀÁÂ\217\207", stack_depth=3, constants_data=0x83cb880) at bytecode.c:656 > > #17 0x808a37f in funcall_compiled_function (fun=138171632, nargs=0, > args=0xbfffddcc) at bytecode.c:515 > > #18 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffddc8) at eval.c:3563 > > #19 0x808a677 in execute_optimized_program (program=0x84e0d98 "\r¬\004Æ > \025\n@\211\031A\036\020\b\t@a«%\t\f¡\210\016\020\fk«\020Ç\016\021È\013#\210ÉÊ\r!!\210ª\aË\f\013\r#\210Ì > \210ª\r\b\fB\nB\022Ë\f\013\r#\210Í \210\013Îa­\004Ï\b!*\207ÿÿÿÿ\031", > stack_depth=5, constants_data=0x83cb8a0) at bytecode.c:746 > > #20 0x808a37f in funcall_compiled_function (fun=138171660, nargs=4, > args=0xbfffdeec) at bytecode.c:515 > > #21 0x80a8bc1 in Ffuncall (nargs=5, args=0xbfffdee8) at eval.c:3563 > > #22 0x808a677 in execute_optimized_program (program=0x84e0d50 > "\fÅa«\aÆ\n\t\013#\207ÇÈ\013\"«\004\b«\026É\n\t\fÊa«\004˪\aÌ\fÍ¥Î\"P\013#\207Ï\n\t\f\013$\207\001", > stack_depth=6, constants_data=0x83cba98) at bytecode.c:746 > > #23 0x808a37f in funcall_compiled_function (fun=138171744, nargs=3, > args=0xbfffe00c) at bytecode.c:515 > > #24 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe008) at eval.c:3563 > > #25 0x808a677 in execute_optimized_program (program=0x8856268 > "\212\013¬\f\n¬\tÅÆ\tÅ\"\210ª\017ÇÈ\013\n#\034É\t\f\b#\210\f))\207\b8", > stack_depth=4, constants_data=0x83cbb30) at bytecode.c:746 > > #26 0x808a37f in funcall_compiled_function (fun=138171856, nargs=4, > args=0xbfffe12c) at bytecode.c:515 > > #27 0x80a8bc1 in Ffuncall (nargs=5, args=0xbfffe128) at eval.c:3563 > > #28 0x808a677 in execute_optimized_program (program=0x84e0878 > "\016=­\a\f\rZ\016>Y\0366\016?\036@\016:¢Æa«\005\016:ª\003Ç A\036+È > \036;É\211\0361\0367Ê\0363\016+G\0368Ë\211\0369\036.Ë\036)\016+\203q\004\016+@\211\0269@\026.\rb\210`\fW\203Q\004\016.;«\tÌ\016.\fÆ#ª\005\016.\f!\203=\004`\rZÍ_\f\rZ\0168_¥\0163Í_\0168¥\\É\\\0261\0166«\021\0161\0167V«\nÎÏÐ\0161\016;$\210\0161\0267\0169A\211\026)«¯\016)@@§\203Í\001\016)@@\225\034\016)@\211\036,@\211\0360\224\035\0160\225\034Ñ\016,8\036*\016,A@\211\036"..., > stack_depth=13, constants_data=0x84e2258) at bytecode.c:746 > > #29 0x808a37f in funcall_compiled_function (fun=138299276, nargs=3, > args=0xbfffe26c) at bytecode.c:515 > > #30 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe268) at eval.c:3563 > > #31 0x808a677 in execute_optimized_program (program=0x8771cb8 "Æ Ç\211È > É\211\031\030\036\020\036\021\036\022\036\023Ê\216\013«\005Ë\013!\210Ì\r\f\"\210\016\024«\006Í\r\f\"\210\016\025¬\aÎ\r\f\n#\210Ï\r\f\n#.\a\207", > stack_depth=6, constants_data=0x84b6670) at bytecode.c:746 > > #32 0x808a37f in funcall_compiled_function (fun=138298744, nargs=3, > args=0xbfffe38c) at bytecode.c:515 > > #33 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe388) at eval.c:3563 > > #34 0x808a677 in execute_optimized_program (program=0x880a298 > "\013\n\t\b#\207\200\b ", stack_depth=4, constants_data=0x84c1858) at > bytecode.c:746 > > #35 0x808a37f in funcall_compiled_function (fun=138298632, nargs=2, > args=0xbfffe4ac) at bytecode.c:515 > > #36 0x80a8bc1 in Ffuncall (nargs=3, args=0xbfffe4a8) at eval.c:3563 > > #37 0x808a677 in execute_optimized_program (program=0x880a110 > "Â\t\b\"\207¢\200\b ", stack_depth=3, constants_data=0x84b94d8) at > bytecode.c:746 > > #38 0x808a37f in funcall_compiled_function (fun=138298884, nargs=3, > args=0xbfffe5e0) at bytecode.c:515 > > #39 0x80a8bc1 in Ffuncall (nargs=4, args=0xbfffe5dc) at eval.c:3563 > > #40 0x8122a93 in Fmap_range_table (function=138298884, > range_table=139159952) at rangetab.c:480 > > #41 0x80a8aca in Ffuncall (nargs=3, args=0xbfffe678) at eval.c:3528 > > #42 0x808a677 in execute_optimized_program (program=0x8771c08 > "Ä\013\b\"\210Å\013!­'Æ\n!\210r\013q\210\212\214~\210\t\031ÇÈÉ\211\211\211\211ÊË&\b\210ÌedÊÉ$\210ÍÎ\n\",\207", > stack_depth=9, constants_data=0x84b91d8) at bytecode.c:746 > > #43 0x808a37f in funcall_compiled_function (fun=138298912, nargs=2, > args=0xbfffe7c4) at bytecode.c:515 > > #44 0x80a8bc1 in Ffuncall (nargs=3, args=0xbfffe7c0) at eval.c:3563 > > #45 0x80a1a87 in Fmaphash (function=138298912, hash_table=139171896) at > elhash.c:1195 > > #46 0x80a8aca in Ffuncall (nargs=3, args=0xbfffe858) at eval.c:3528 > > #47 0x808a677 in execute_optimized_program (program=0x8809f88 " > \031Ã\216ÄÅ\b\"*\207", stack_depth=3, constants_data=0x84b9928) at > bytecode.c:746 > > #48 0x808a37f in funcall_compiled_function (fun=138298940, nargs=0, > args=0xbfffe96c) at bytecode.c:515 > > #49 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffe968) at eval.c:3563 > > #50 0x808a677 in execute_optimized_program (program=0xbfffe9b4 > "Á\b!ÂV­\003à \207", stack_depth=2, constants_data=0x84bb598) at bytecode.c:746 > > #51 0x808c8d1 in Fbyte_code (instructions=139621028, > constants=139179400, stack_depth=5) at bytecode.c:2403 > > #52 0x80a85f2 in Feval (form=138707952) at eval.c:3331 > > #53 0x80a6556 in condition_case_1 (handlers=138715660, bfun=0x80a817c > , barg=138707952, hfun=0x80a65ac , > harg=139536332) at eval.c:1651 > > #54 0x80a67df in condition_case_3 (bodyform=138707952, var=139536332, > handlers=138715660) at eval.c:1729 > > #55 0x808af8d in execute_rare_opcode (stack_ptr=0xbfffec80, > program_ptr=0x8809e04 "\207\237\200\b ", opcode=Bcondition_case) at > bytecode.c:1271 > > #56 0x808a50b in execute_optimized_program (program=0x8809e00 > "ÀÁÂ\217\207\237\200\b ", stack_depth=3, constants_data=0x84b9578) at > bytecode.c:656 > > #57 0x808a37f in funcall_compiled_function (fun=138298800, nargs=0, > args=0xbfffee48) at bytecode.c:515 > > #58 0x80a8bc1 in Ffuncall (nargs=1, args=0xbfffee44) at eval.c:3563 > > #59 0x80a93cf in run_hook_with_args_in_buffer (buf=0x8854f78, nargs=1, > args=0xbfffee44, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4020 > > #60 0x80a943e in run_hook_with_args (nargs=1, args=0xbfffee44, > cond=RUN_HOOKS_TO_COMPLETION) at eval.c:4033 > > #61 0x80a919d in Frun_hooks (nargs=1, args=0xbfffee44) at eval.c:3887 > > #62 0x80a9538 in run_hook (hook=139535876) at eval.c:4134 > > #63 0x80a9f11 in catch_them_squirmers_run_hook (hook_symbol=136270164) > at eval.c:4578 > > #64 0x80a6556 in condition_case_1 (handlers=136170308, bfun=0x80a9f00 > , barg=136270164, hfun=0x80a9d8c > , harg=140204160) at eval.c:1651 > > #65 0x80aa104 in safe_run_hook_trapping_errors > (warning_string=0x8187a80 "Error in `pre-idle-hook' (setting hook to > nil)", hook_symbol=136270164, allow_quit=1) at eval.c:4639 > > #66 0x80ccda5 in run_pre_idle_hook () at event-stream.c:2004 > > #67 0x80cd015 in Fnext_event (event=142729332, prompt=136170212) at > event-stream.c:2176 > > #68 0x8091a47 in Fcommand_loop_1 () at cmdloop.c:574 > > #69 0x8091905 in command_loop_1 (dummy=136170212) at cmdloop.c:494 > > #70 0x80a6556 in condition_case_1 (handlers=136170308, bfun=0x80918ec > , barg=136170212, hfun=0x8091460 , > harg=136170212) at eval.c:1651 > > #71 0x8091553 in command_loop_3 () at cmdloop.c:256 > > #72 0x8091577 in command_loop_2 (dummy=136170212) at cmdloop.c:267 > > #73 0x80a622c in internal_catch (tag=136246308, func=0x809156c > , arg=136170212, threw=0x0) at eval.c:1317 > > #74 0x80916ae in initial_command_loop (load_me=136170212) at cmdloop.c:305 > > #75 0x80a32e1 in xemacs_21_4_1_i386_debian_linux () at emacs.c:2344 > > #76 0x80a3a52 in main () at emacs.c:2773 > > #77 0x4041316b in __libc_start_main () from /lib/libc.so.6 > > > > With what looks like the same lisp backtrace: > > dispatch-non-command-events() > > # (condition-case ... . ((nil))) > > progress-feedback-dispatch-non-command-events() > > # bind (tmsg top frame value message label) > > append-progress-feedback(font-lock "Fontifying test... " 100 nil) > > # bind (frame value message label) > > display-progress-feedback(font-lock "Fontifying test... " 100) > > # bind (str) > > # (unwind-protect ...) > > # bind (args value fmt label) > > progress-feedback-with-label(font-lock "Fontifying %s... " 100 "test") > > # bind (loudly loudvar end start) > > font-lock-fontify-keywords-region(1 11452 nil) > > # (unwind-protect ...) > > # bind (modified buffer-undo-list inhibit-read-only old-syntax-table > buffer-file-name buffer-file-truename loudly end beg) > > font-lock-default-fontify-region(1 11452 nil) > > # bind (loudly end beg) > > font-lock-fontify-region(1 11452) > > # bind (val end beg) > > # font-lock-fontify-region] 3>(1 11452 t) > > map-range-table(# font-lock-fontify-region] 3> #s(range-table data ((1 11452) t))) > > # bind (zmacs-region-stays) > > # (unwind-protect ...) > > # (unwind-protect ...) > > # (unwind-protect ...) > > # bind (dummy buffer) > > # [font-lock-pending-buffer-table zmacs-region-stays font-lock-range-table > buffer remhash buffer-live-p clear-range-table map-extents > # nil font-lock-pending t > put-text-property map-range-table # 3>] 9>(# t) > > maphash(# [font-lock-pending-buffer-table zmacs-region-stays font-lock-range-table > buffer remhash buffer-live-p clear-range-table map-extents > # nil font-lock-pending t > put-text-property map-range-table # 3>] 9> #) > > # (unwind-protect ...) > > # bind (match-data) > > font-lock-fontify-pending-extents() > > byte-code("..." [font-lock-pending-buffer-table hash-table-count 0 > font-lock-fontify-pending-extents] 2) > > # (condition-case ... . ((error (warn "Error caught in > `font-lock-pre-idle-hook': %s" font-lock-error)))) > > font-lock-pre-idle-hook() > > # (condition-case ... . error) > > # (condition-case ... . error) > > # (catch top-level ...) > > > > Haven't been able to reproduce with -vanilla yet. > > > > After loading my custom.el I am getting lots of X errors like this: > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 70 (X_PolyFillRectangle) > > Resource id in failed request: 0xd > > Serial number of failed request: 31453 > > Current serial number in output stream: 31471 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 66 (X_PolySegment) > > Resource id in failed request: 0xd > > Serial number of failed request: 31454 > > Current serial number in output stream: 31471 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 66 (X_PolySegment) > > Resource id in failed request: 0xd > > Serial number of failed request: 31499 > > Current serial number in output stream: 31502 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 70 (X_PolyFillRectangle) > > Resource id in failed request: 0xd > > Serial number of failed request: 31500 > > Current serial number in output stream: 31502 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 66 (X_PolySegment) > > Resource id in failed request: 0xd > > Serial number of failed request: 31501 > > Current serial number in output stream: 31502 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 66 (X_PolySegment) > > Resource id in failed request: 0xd > > Serial number of failed request: 31557 > > Current serial number in output stream: 31560 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 70 (X_PolyFillRectangle) > > Resource id in failed request: 0xd > > Serial number of failed request: 31558 > > Current serial number in output stream: 31560 > > > > xemacs-21.4.1-nomule: X Error of failed request: BadGC (invalid GC > parameter) > > Major opcode of failed request: 66 (X_PolySegment) > > Resource id in failed request: 0xd > > Serial number of failed request: 31559 > > Current serial number in output stream: 31560 > > > > OK. Got a repeat with -vanilla loading the following: > > (custom-set-variables > > '(w3-user-fonts-take-precedence t) > > '(gnus-junk-complaint-text " Hello, > > > > James LewisMoss > > > > -- > > @James LewisMoss | dres@debian.org | Blessed Be! > > @ http://www.lewismoss.com/~dres | Linux is cool! > > @\"Argue for your limitations and sure enough, they're yours.\" Bach > > ") > > '(irchat-want-traditional t) > > '(message-generate-headers-first t) > > '(gnus-junk-original-seperator " > > --------------------original--message--follows-------------------- > > ") > > '(toolbar-news-use-separate-frame t) > > '(wwi-auto-install-on-startup-flag t nil (where-was-i-db)) > > '(gnuserv-program (concat exec-directory "/gnuserv")) > > '(change-log-default-name "ChangeLog") > > '(icomplete-mode t nil (icomplete)) > > '(message-default-charset (quote us-ascii)) > > '(browse-url-browser-function (quote browse-url-netscape)) > > '(minibuf-frame-pos-y -2) > > '(minibuf-frame-pos-x 0) > > '(message-deletable-headers (quote (Message-ID Date Lines Sender))) > > '(toolbar-news-reader (quote gnus)) > > '(w3-user-colors-take-precedence t) > > '(gnus-uu-user-view-rules (quote > (("\"\\\\.\\\\(jpe?g\\\\|gif\\\\|tiff?\\\\|p[pgb]m\\\\|xwd\\\\|xbm\\\\|pcx\\\\)$" > "eeyes")))) > > '(toolbar-visible-p nil) > > '(nnmail-spool-file "/var/spool/mail/$user") > > '(jde-mode-abbreviations (quote (("ab" "abstract") ("bo" "boolean") > ("br" "break") ("by" "byte") ("byv" "byvalue") ("cas" "cast") ("ca" > "catch") ("ch" "char") ("cl" "class") ("co" "const") ("con" "continue") > ("de" "default") ("dou" "double") ("el" "else") ("ex" "extends") ("fa" > "false") ("fi" "final") ("fin" "finally") ("fl" "float") ("fo" "for") > ("fu" "future") ("ge" "generic") ("go" "goto") ("impl" "implements") > ("impo" "import") ("ins" "instanceof") ("in" "int") ("inte" "interface") > ("lo" "long") ("na" "native") ("ne" "new") ("nu" "null") ("pa" "package") > ("pri" "private") ("pro" "protected") ("pu" "public") ("re" "return") > ("sh" "short") ("St" "String") ("st" "static") ("su" "super") ("sw" > "switch") ("sy" "synchronized") ("th" "this") ("thr" "throw") ("throw" > "throws") ("tra" "transient") ("tr" "true") ("vo" "void") ("vol" > "volatile") ("wh" "while")))) > > '(Info-button1-follows-hyperlink t) > > '(frame-background-mode (quote dark)) > > '(gnus-check-bogus-newsgroups t) > > '(completion-ignored-extensions (quote (".Sym" ".Lib" ".beam" ".vee" > ".jam" ".o" ".elc" "~" ".bin" ".lbin" ".fasl" ".dvi" ".toc" ".log" ".aux" > ".a" ".ln" ".lof" ".blg" ".bbl" ".glo" ".idx" ".lot" ".fmt" ".oi" ".class"))) > > '(gnus-junk-include-body t) > > '(user-mail-address "jimdres@mindspring.com") > > '(query-user-mail-address nil)) > > (custom-set-faces > > '(info-xref ((t (:bold t :foreground "sienna1")))) > > '(pointer ((t (:foreground "purple1" :background "blue"))) t) > > '(info-node ((t (:bold t :foreground "dodgerblue1")))) > > '(secondary-selection ((t (:foreground "green1"))) t) > > '(eif-string ((t (:bold nil :foreground "tomato"))) t) > > '(html-helper-italic-face ((t (:italic t :family "lucida"))) t) > > '(widget-field-face ((((class grayscale color) (background light)) > (:foreground "black" :background "gray85")))) > > '(gnus-header-subject-face ((((class color) (background dark)) (:bold > t :italic t :foreground "pink" :family "lucida")))) > > '(gnus-header-from-face ((((class color) (background dark)) (:bold t > :italic t :foreground "light blue" :family "lucida")))) > > '(font-lock-string-face ((t (:bold nil :foreground "yellowgreen")))) > > '(eif-comment ((t (:bold nil :foreground "hot pink"))) t) > > '(dired-face-permissions ((t (:foreground "red" :background "grey85")))) > > '(xrdb-option-name-face ((t (:bold nil :foreground "red1"))) t) > > '(font-lock-reference-face ((t (:foreground "gold")))) > > '(comint-input-face ((((class color) (background light)) (:foreground > "sky blue")))) > > '(gnus-group-news-low-empty-face ((((class color)) (:foreground > "DarkTurquoise")) (((class color) (background light)) (:foreground > "DarkGreen")) (t nil))) > > '(dired-face-setuid ((((class color)) (:foreground "yellow")) (t > (:bold t)))) > > '(shell-prompt-face ((t (:foreground "antique white" :background "dark > green"))) t) > > '(widget-documentation-face ((((class color) (background light)) > (:bold nil :foreground "orchid1")))) > > '(gnus-header-newsgroups-face ((((class color) (background dark)) > (:bold t :italic t :foreground "yellow" :family "lucida")))) > > '(gnus-emphasis-underline-italic ((t (:italic t :underline t :family > "lucida")))) > > '(custom-group-tag-face ((((class color) (background light)) > (:underline t :foreground "sky blue")))) > > '(custom-variable-tag-face ((((class color) (background light)) > (:underline t :foreground "light blue")))) > > '(message-header-subject-face ((((class color) (background dark)) > (:foreground "pink")) (((class color) (background light)) (:bold t > :foreground "navy blue")) (t (:bold t)))) > > '(eif-assertion ((t (:bold t :foreground "light blue" :size "10"))) t) > > '(gnus-summary-low-unread-face ((t (:italic t :family > "lucidatypewriter")))) > > '(font-lock-doc-string-face ((t (:foreground "green")))) > > '(gnus-summary-low-ticked-face ((((class color) (background dark)) > (:italic t :foreground "pink" :family "lucidatypewriter")))) > > '(modeline-buffer-id ((t (:foreground "blue4" :background "grey80"))) t) > > '(font-lock-preprocessor-face ((t (:foreground "black" :background > "pink")))) > > '(modeline-mousable ((t (:foreground "firebrick" :background > "grey80"))) t) > > '(gnus-group-news-3-face ((t (:bold t :foreground "steelblue1")))) > > '(font-lock-variable-name-face ((t (:foreground "navajowhite2")))) > > '(gnus-group-news-3-empty-face ((t (:foreground "steelblue2")))) > > '(hyper-apropos-hyperlink ((((class color) (background light)) > (:foreground "light blue")))) > > '(gnus-header-content-face ((t (:italic t :foreground "lawngreen" > :family "lucida")))) > > '(custom-state-face ((((class color) (background light)) (:foreground > "light green")))) > > '(font-lock-other-emphasized-face ((t (:foreground "green" :background > "dark blue"))) t) > > '(font-lock-keyword-face ((((class color) (background light dark)) > (:bold nil :foreground "pink")))) > > '(message-cited-text-face ((((class color) (background dark)) > (:foreground "LightBlue")) (((class color) (background light)) > (:foreground "red")) (t (:bold t)))) > > '(documentation ((t (:bold nil :foreground "light pink"))) t) > > '(eif-hidden-comment ((t (:bold nil :foreground "light green"))) t) > > '(gnus-signature-face ((((type x)) (:italic t :family > "lucidatypewriter")))) > > '(gnus-emphasis-underline-bold-italic ((t (:bold t :italic t > :underline t :family "lucida")))) > > '(font-lock-type-face ((t (:foreground "light pink")))) > > '(gnus-group-mail-low-empty-face ((((class color) (background dark)) > (:foreground "paleturquoise2")) (((class color) (background light)) > (:foreground "DeepPink4")) (t (:bold t)))) > > '(bold-italic ((t (:italic t :family "lucida"))) t) > > '(w3-table-hack-x-face ((t (:family "lucidatypewriter" :size "10"))) t) > > '(gnus-header-name-face ((((class color) (background dark)) > (:foreground "cyan")) (((class color) (background light)) (:foreground > "maroon")) (t (:bold t)))) > > '(font-lock-emphasized-face ((t (:foreground "blue" :background > "lightyellow2" :size "nil"))) t) > > '(widget-inactive-face ((((class grayscale color) (background light)) > (:foreground "light pink")))) > > '(blue ((t (:foreground "lightskyblue"))) t) > > '(gnus-group-mail-low-face ((((class color) (background dark)) (:bold > t :foreground "aquamarine2")) (((class color) (background light)) (:bold > t :foreground "DeepPink4")) (t (:bold t)))) > > '(message-header-cc-face ((((class color) (background dark)) (:bold t > :foreground "light blue")) (((class color) (background light)) > (:foreground "MidnightBlue")) (t (:bold t)))) > > '(message-header-other-face ((((class color) (background dark)) > (:foreground "gray")) (((class color) (background light)) (:foreground > "steel blue")) (t (:bold t :italic t)))) > > '(message-header-newsgroups-face ((((class color) (background dark)) > (:bold t :italic t :foreground "yellow" :family "lucidatypewriter")))) > > '(message-separator-face ((((class color) (background dark)) > (:foreground "red")) (((class color) (background light)) (:foreground > "brown")) (t (:bold t)))) > > '(list-mode-item-selected ((t (:background "blue"))) t) > > '(message-header-contents ((t (:italic t :family "lucidatypewriter")))) > > '(hyper-apropos-documentation ((((class color) (background light)) > (:foreground "lightpink")))) > > '(italic ((t (:italic t :family "lucida"))) t) > > '(gnus-summary-low-ancient-face ((((class color) (background dark)) > (:italic t :foreground "SkyBlue" :family "lucidatypewriter")))) > > '(font-lock-comment-face ((t (:foreground "orchid1")))) > > '(dired-face-executable ((((class color)) (:foreground "yellow")) (t > (:bold t)))) > > '(message-header-name-face ((((class color) (background dark)) > (:foreground "cyan")) (((class color) (background light)) (:foreground > "cornflower blue")) (t (:bold t)))) > > '(gnus-emphasis-italic ((t (:italic t :family "lucida")))) > > '(font-lock-function-name-face ((t (:foreground "lightskyblue")))) > > '(message-header-xheader-face ((((class color) (background dark)) > (:foreground "lightblue")))) > > '(isearch ((t (:foreground "black" :background "lightblue"))) t) > > '(gnus-emphasis-bold-italic ((t (:bold t :italic t :family "lucida")))) > > '(hyperlink ((t (:bold t :foreground "mediumpurple1"))) t) > > '(message-header-to-face ((((class color) (background dark)) (:bold t > :foreground "LightBlue")) (((class color) (background light)) (:bold t > :foreground "MidnightBlue")) (t (:bold t :italic t)))) > > '(zmacs-region ((t (:bold t :foreground "black" :background "pink" > :family "lucidatypewriter"))) t) > > '(gnus-summary-low-read-face ((((class color) (background dark)) > (:italic t :foreground "PaleGreen" :family "lucidatypewriter")))) > > '(message-highlighted-header-contents ((t (:bold t :italic t :family > "lucidatypewriter")))) > > '(dired-face-marked ((((class color)) (:foreground "black" :background > "PaleVioletRed")) (t (:underline t))))) > > and > > (require 'dired) > > (setq dired-listing-switches "-laF") > > (setq list-directory-brief-switches "-FC") > > (setq-default dired-omit-files-p nil) > > (setq dired-do-permission-highlighting-too t) > > (add-hook 'dired-mode-hook 'turn-on-font-lock) > > > > (define-key dired-mode-map [r] 'dired-advertised-find-file) > > (define-key dired-mode-map [(control c) (control c)] 'compile) > > > > (setq dired-re-raw-boring > > (concat ".\\(\\.class\\|\\.oi\\|\\.fmt\\|\\.ln\\|" > > "\\.a\\|\\.fasl\\|\\.lbin\\|\\.bin\\|\\.elc\\|" > > "\\.o\\|\\.lo\\|\\.jam\\|\\.vee\\|\\.beam\\|" > > "\\.Lib\\|\\.Sym\\|~\\|\\.orig\\|\\.rej\\|" > > "\\.vrs\\|\\.vr\\|\\.tps\\|\\.tp\\|\\.pgs\\|" > > "\\.pg\\|\\.kys\\|\\.ky\\|\\.fns\\|\\.fn\\|" > > "\\.cps\\|\\.cp\\|\\.bbl\\|\\.blg\\|\\.glo\\|" > > "\\.lot\\|\\.lof\\|\\.idx\\|\\.dvi\\|\\.aux\\|" > > "\\.log\\|\\.toc\\)" > > "\\'\\|\\`#\\|\\`\\.")) > > > > This is opening a particular directory (test) which contains a bunch > > of junk that I was playing with at one point or another. File list if > > anyone thinks it'll help. > > > > Different issue: > > Startup time is very long now (in comparison to 21.1.14). > > > > Jim > > > > -- > > @James LewisMoss | Blessed Be! > > @ http://jimdres.home.mindspring.com | Linux is kewl! > > @"Argue for your limitations and sure enough, they're yours." Bach > >-- >ben > >I'm sometimes slow in getting around to reading my mail, so if you >want to reach me faster, call 520-661-6661. > >See http://www.666.com/ben/chronic-pain/ for the hell I've been >through. From andyp@bea.com Mon May 7 12:41:44 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA25013 for ; Mon, 7 May 2001 12:41:43 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA06481; Mon, 7 May 2001 09:41:48 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001380wss.beasys.com [192.168.6.211]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA05653; Mon, 7 May 2001 09:42:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507093808.00afa340@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 09:39:41 -0700 To: Ben Wing From: Andy Piper Subject: Re: Warning: XtRemoveGrab asked to remove a widget not on thelist Cc: Andreas Jaeger , XEmacs Beta Testers In-Reply-To: <3AF605A6.9F29BC67@666.com> References: <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> <4.3.2.7.2.20010428083300.00aecd40@san-francisco.beasys.com> <4.3.2.7.2.20010501092408.02e929f0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:17 PM 5/6/01 -0700, Ben Wing wrote: >Andy Piper wrote: > > > > At 12:06 PM 5/1/01 +0200, Andreas Jaeger wrote: > > >Andy Piper writes: > > > > > > > I've seen this at frame deletion and never been able to track it > > > > down. I believe its widget related becuase it came and went while I > > > > was hacking on them. > > > > > >Do you have any idea how to track it down? I can easily reproduce it > > >but don't know anything about the widget stuff. > > > > Absolutely no idea - it seems to be in the guts of the X code. I read all > > the manuals and put breakpoints everywhere, but I just don't know what the > > error is indicating. > >what you need to do is recompile the Xt sources with debug info, and find the >place in the sources where this error is being issued, and set a breakpoint >there. this shouldn't be hard, although perhaps a bit time-consuming if >the Xt >sources don't recompile easily. > >the message indicates that XtRemoveGrab was called on a widget without an >associated earlier XtAddGrab call. those calls are used to create menus and >modal dialog boxes -- anything that temporarily locks out input to all other >widgets. > >andy, what state is the focus-handling in your code in? It depends what you mean :) Its handled after a fashion for widgets (you can focus in and out) but I suspect there is more esoteric X trickery needed. andy From andyp@bea.com Mon May 7 12:43:26 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA25180 for ; Mon, 7 May 2001 12:43:26 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA06895; Mon, 7 May 2001 09:43:30 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001380wss.beasys.com [192.168.6.211]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA05972; Mon, 7 May 2001 09:44:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 09:41:23 -0700 To: James LewisMoss , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Update to last message In-Reply-To: References: <3AF5EC2A.D0063822@666.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed If you can send me a file that crashes XEmacs when font-locked that would be swell. I should be able to nail it then. Can you also print the contents of w. andy At 10:17 PM 5/6/01 -0400, James LewisMoss wrote: >Here's the args in the GaugeExpose call: > >Program received signal SIGSEGV, Segmentation fault. >0x401a8df0 in XDrawLine () from /usr/X11R6/lib/libX11.so.6 >(gdb) up >#1 0x8172cb6 in GaugeExpose (w=0x863a570, event=0xbfffd91c, >region=0x84314c8) at xlwgauge.c:425 >425 XDrawLine(dpy,win,gctop, e0+1,y, e1-1,y) ; >(gdb) info args >w = 0x863a570 >event = (XEvent *) 0xbfffd91c >region = 0x84314c8 >(gdb) info locals >gw = 0x863a570 >dpy = (Display *) 0x84451a0 >win = 20971736 >gc = 0x8 >gctop = 0x8 >gcbot = 0x8 >len = 20971736 >e0 = 5768 >e1 = -5519 >x = 135736196 >y = 64481 >i = 0 >v0 = 0 >v1 = 100 >value = 0 > >And it's very reproducible. This seems to be a font locking issue >because every time it happens (I couldn't include the previous email >in this one because it was causing a crash) the two boxes which look >like font lock progress bars (but I haven't seen much of them because >they go quickly or crash). > >I forgot this info last time: >uname -a: Linux eeyore 2.4.4-pre7 #1 Thu Apr 26 23:45:07 EDT 2001 i686 unknown > >./configure '--with-sound=native' '--with_menubars=lucid' >'--with_scrollbars=lucid' '--with_dialogs=athena' '--cflags=-O2 -g -Wall' >'--with-x11' '--extra-verbose' '--with-site-lisp' '--statedir=/var/lib' >'--infodir=/usr/share/info/xemacs-21.4.1' '--prefix=/usr' >'--statedir=/var/lib/xemacs' '--error-checking=none' '--debug=no' >'--const-is-losing=no' '--dynamic' '--with-gpm=no' >'--docdir=/usr/lib/xemacs-21.4.1/i386-debian-linux/nomule/' >'--package-path=~/.xemacs::/usr/share/xemacs21/packages:/usr/share/xemacs21/site-packages' >'i386-debian-linux' > > >XEmacs 21.4.1 "Copyleft" configured for `i386-debian-linux'. > > >Compilation / Installation: > Source code > location: /home/dres/project/debian/xemacs21/xemacs-21.4.1 > Installation prefix: /usr > Operating system description file: `s/linux.h' > Machine description file: `m/intel386.h' > Compiler: gcc -O2 -g -Wall > Relocating allocator for buffers: no > GNU version of malloc: yes > - Using Doug Lea's new malloc from the GNU C Library. > >Window System: > Compiling in support for the X window system: > - X Windows headers location: /usr/X11R6/include > - X Windows libraries location: /usr/X11R6/lib > - Handling WM_COMMAND properly. > Compiling in support for the Athena widget set: > - Athena headers location: X11/Xaw > - Athena library to link: Xaw > Using Lucid menubars. > Using Lucid scrollbars. > Using Athena dialog boxes. > Using Athena native widgets. > >TTY: > Compiling in support for ncurses. > >Images: > Compiling in support for GIF images (builtin). > Compiling in support for XPM images. > Compiling in support for PNG images. > Compiling in support for JPEG images. > Compiling in support for TIFF images. > Compiling in support for X-Face message headers. > >Sound: > Compiling in support for sound (native). > Compiling in support for ESD (Enlightened Sound Daemon). > >Databases: > Compiling in support for Berkeley database. > Compiling in support for LDAP. > Compiling in support for PostgreSQL. > - Using PostgreSQL header file: postgresql/libpq-fe.h > - Using PostgreSQL V7 bindings. > >Internationalization: > >Mail: > Compiling in support for "dot-locking" mail spool file locking method. > >Other Features: > Compiling in support for dynamic shared object modules. > >Thanks >Jim >-- >@James LewisMoss | Blessed Be! >@ http://jimdres.home.mindspring.com | Linux is kewl! >@"Argue for your limitations and sure enough, they're yours." Bach From amitp@google.com Mon May 7 15:10:11 2001 Received: from corp.google.com (216-239-45-7.google.com [216.239.45.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA07281 for ; Mon, 7 May 2001 15:10:10 -0400 Received: from moma.corp.google.com (mail.corp.google.com [10.3.0.12]) by corp.google.com (8.9.3/8.9.3) with ESMTP id LAA10583 for ; Mon, 7 May 2001 11:56:31 -0700 Received: from ant.corp.google.com (ant.corp.google.com [10.3.4.9]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id LAA27924 for ; Mon, 7 May 2001 11:56:31 -0700 Received: (from amitp@localhost) by ant.corp.google.com (8.10.2/8.10.2) id f47IuVu19281; Mon, 7 May 2001 11:56:31 -0700 Date: Mon, 7 May 2001 11:56:31 -0700 Message-Id: <200105071856.f47IuVu19281@ant.corp.google.com> From: Amit Patel To: xemacs-beta@xemacs.org Subject: Font locking bug - infinite loop This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.5 (beta0) "alfalfa" [Lucid] (i686-pc-linux, Mule) of Mon May 7 2001 on ant.corp.google.com configured using `configure --with-mule --prefix=/red/xemacs' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Hi, I've been whittling away my ~/.vm file until I could get this bug to occur reliably. I've also run xemacs -q to avoid loading my own ~/.emacs file. So I think after many weeks of trying to pin this down, I've come down to a small bit of ~/.vm code that triggers the bug on my system. Symptoms: I run M-x vm and the font locking progress bar starts flickering a whole lot, and it never completes. So I suspect there's a bug in the font locking code. However ... while removing things from ~/.vm, I found that the font locking alone wasn't enough to trigger the bug. I also had to set the frame properties on my VM frame. So here's my ~/.vm file: ====================================================================== ;;; TEMPORARY FILE ONLY FOR BETA TESTING XEMACS 21.5 (setq font-lock-auto-fontify t) (setq vm-folder-directory "~/Mail/") ;; Allow ~/Mail/*.spool to be used to fill the corresponding ~/Mail/* folder (setq vm-spool-file-suffixes '(".spool")) (setq vm-crash-box-suffix ".CRASH") (setq vm-primary-inbox "~/Mail/INBOX") (setq vm-crash-box "~/Mail/INBOX.CRASH") ;; Font locking for the summary buffer (defun my-vm-font-lock () (interactive) (make-variable-buffer-local 'font-lock-keywords-only) (setq font-lock-keywords-only t) (turn-on-font-lock) ) (add-hook 'vm-summary-mode-hook 'my-vm-font-lock) (setq vm-summary-font-lock-keywords '( ("Re:" 1 yellow t) )) ;; Frame/Window configuration (setq vm-frame-parameter-alist '((primary-folder ( (name . "vm") (height . 60) (width . 80) (toolbar-shadow-thickness . 1) (border-width . 3) (border-color . "#f0f0e0") (left . 1) (top . 1) )))) ====================================================================== At times my entire XEmacs will crash; at other times it takes a few Ctrl-G's *and* Q (to quit VM) to restore sanity. (And I still can't get to my email.) I'm using 21.1.14 in the meantime .. Anyway, I'd really like to hear if anyone else can reproduce it. If not, I'll try harder to look for anything else that might be involved. - Amit Recent keystrokes: M-x v m RET q misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Quitting... Loading vm-virtual...done Loading vm-virtual... Quit Loading vm-sort...done Loading vm-sort... Loading font-lock...done From jmincy@muniversal.com Mon May 7 15:58:06 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA12972 for ; Mon, 7 May 2001 15:58:06 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14wr8p-0006tb-00 ; Mon, 07 May 2001 15:57:59 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.64595.590000.271958@antarres.muniversal.com> Date: Mon, 7 May 2001 15:49:39 -0400 To: Amit Patel Cc: xemacs-beta@xemacs.org Subject: Font locking bug - infinite loop In-Reply-To: <200105071856.f47IuVu19281@ant.corp.google.com> References: <200105071856.f47IuVu19281@ant.corp.google.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid I've been whittling away my ~/.vm file until I could get this bug to occur reliably. I've also run xemacs -q to avoid loading my own ~/.emacs file. So I think after many weeks of trying to pin this down, I've come down to a small bit of ~/.vm code that triggers the bug on my system. Your pattern (setq vm-summary-font-lock-keywords '(("Re:" 1 yellow t))) Matches the first paren expression. (You don't have any) maybe you meant something like: (setq vm-summary-font-lock-keywords '(("Re:\\(.*\\)" 1 yellow t))) I think you want: ;; Font locking for the summary buffer (defun my-vm-font-lock () (interactive) (make-variable-buffer-local 'font-lock-keywords) ;;(setq font-lock-keywords-only t) (setq font-lock-keywords vm-summary-font-lock-keywords) (turn-on-font-lock)) (add-hook 'vm-summary-mode-hook 'my-vm-font-lock) (setq vm-summary-font-lock-keywords '(("Re:" 0 yellow t))) -jeff From jimdres@mindspring.com Mon May 7 16:01:38 2001 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA13838 for ; Mon, 7 May 2001 16:01:36 -0400 Received: from eeyore.lewismoss.org (user-2ivf0rc.dialup.mindspring.com [165.247.131.108]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA10604; Mon, 7 May 2001 15:58:45 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14wr8r-0000Eu-00; Mon, 07 May 2001 15:58:01 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> From: James LewisMoss In-Reply-To: Andy Piper's message of "Mon, 07 May 2001 09:41:23 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 07 May 2001 15:57:39 -0400 Message-ID: Lines: 64 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On Mon, 07 May 2001 09:41:23 -0700, Andy Piper said: Andy> If you can send me a file that crashes XEmacs when font-locked Andy> that would be swell. I should be able to nail it then. So far it's been a directory listing that I've found to crash it. I'll try to find a file as well. Kewl. Just found one. Between the ----s ----------------------------------------------------------------- #include #include int main (void) { unsigned long msize = 64; if (msize != 0 && ((msize - 1) > (2147483647L * 2UL + 1))) fprintf (stderr, "test FAILED\n"); exit (0); } ----------------------------------------------------------------- Andy> Can you also print the contents of w. (gdb) up #1 0x8172886 in GaugeExpose (w=0x8642480, event=0xbfffddec, region=0x8428208) at xlwgauge.c:425 425 XDrawLine(dpy,win,gctop, e0+1,y, e1-1,y) ; (gdb) print *w $1 = {core = {self = 0x8642480, widget_class = 0x81a7fe0, parent = 0x8642138, xrm_name = 1131, being_destroyed = 0 '\000', destroy_callbacks = 0x8647260, constraints = 0x0, x = 0, y = 0, width = 250, height = 24, border_width = 1, managed = 1 '\001', sensitive = 1 '\001', ancestor_sensitive = 1 '\001', event_table = 0x0, tm = {translations = 0x8642468, proc_table = 0x84e9038, current_state = 0x0, lastEventTime = 0}, accelerators = 0x0, border_pixel = 0, border_pixmap = 2, popup_list = 0x0, num_popups = 0, name = 0x83f38d7 "Progress", screen = 0x845ef08, colormap = 32, window = 20971708, depth = 16, background_pixel = 25388, background_pixmap = 2, visible = 1 '\001', mapped_when_managed = 1 '\001'}} (gdb) info locals gw = 0x8642480 dpy = (Display *) 0x83e43c0 win = 20971708 gc = 0x66200008 gctop = 0x66200008 gcbot = 0x66200008 len = 20971708 e0 = 9848 e1 = -9599 x = 135735124 y = 64469 i = 0 v0 = 0 v1 = 100 value = 0 (gdb) info args w = 0x8642480 event = (XEvent *) 0xbfffddec region = 0x8428208 (gdb) Again I just loaded the elisp from the last message (actually missing the last few related to dired). Then I opened the file. and did M-x font-lock-mode and it crashed. I an still see the two boxes in the box at the bottom of the screen. It says "Fontifying ulong-test.c...". Thanks Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From andyp@bea.com Mon May 7 18:12:34 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA24337 for ; Mon, 7 May 2001 18:12:29 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA17099; Mon, 7 May 2001 15:12:19 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001380wss.beasys.com [192.168.6.211]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id PAA28653; Mon, 7 May 2001 15:13:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507150953.00b04ee0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 15:10:11 -0700 To: James LewisMoss From: Andy Piper Subject: Re: Update to last message Cc: xemacs-beta@xemacs.org In-Reply-To: References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Doesn't crash in my pseudo-X environment - I'll have to try X. andy At 03:57 PM 5/7/01 -0400, James LewisMoss wrote: >#include >#include >int main (void) >{ > unsigned long msize = 64; > if (msize != 0 && ((msize - 1) > (2147483647L * 2UL + 1))) > fprintf (stderr, "test FAILED\n"); > exit (0); >} From karlheg@hegbloom.net Mon May 7 23:32:25 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA16199 for ; Mon, 7 May 2001 23:32:23 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f483WHEH022375 for ; Mon, 7 May 2001 20:32:17 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f483WHA6022372; Mon, 7 May 2001 20:32:17 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: Found on comp.emacs.sources: ibuffer.el From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 07 May 2001 20:32:17 -0700 Message-ID: <87k83sms72.fsf@bittersweet.intra.hegbloom.net> Lines: 28 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii This is a really neat mode! We've got to have it. (define-key ctl-x-map [(control ?b)] #'ibuffer) ;;; ibuffer.el --- operate on buffers like dired ;; Copyright (C) 2000 Free Software Foundation, Inc. ;; Emacs Lisp Archive Entry ;; Author: Colin Walters ;; Created: 8 Sep 2000 ;; Version: 1.9 ;; X-RCS: $Id: ibuffer.el,v 1.115 2001/04/18 04:56:23 walters Exp $ ;; URL: http://www.cis.ohio-state.edu/~walters ;; Keywords: buffer, convenience ;; This file is not currently part of GNU Emacs. ;; This program is free software; [... GPL ...] ;;; Commentary: ;; ibuffer.el is an advanced replacement for the `buffer-menu' which ;; is normally distributed with Emacs. Its interface is intended to ;; be analogous to that of Dired. From yoshiki@xemacs.org Tue May 8 00:38:02 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA20056 for ; Tue, 8 May 2001 00:37:59 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f484bfE06180; Tue, 8 May 2001 13:37:41 +0900 To: Yoshiaki Kasahara Cc: xemacs-beta@xemacs.org Subject: Re: make-charset doesn't handle 'short-name' properly References: <20010425.171837.884091679.kasahara@nc.kyushu-u.ac.jp> <20010507.222740.749333612.kasahara@nc.kyushu-u.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 08 May 2001 13:37:41 +0900 In-Reply-To: <20010507.222740.749333612.kasahara@nc.kyushu-u.ac.jp> (Yoshiaki Kasahara's message of "Mon, 07 May 2001 22:27:40 +0900 (JST)") Message-ID: <87d79kpiay.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 34 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Yoshiaki Kasahara writes: > Excuse me, would someone please respond ? Is this patch pointless?? Sorry, I've been away for a while. > > Index: mule-charset.c > > =================================================================== > > RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-charset.c,v > > retrieving revision 1.19 > > diff -u -r1.19 mule-charset.c > > --- mule-charset.c 2001/04/12 18:24:03 1.19 > > +++ mule-charset.c 2001/04/25 08:03:28 > > @@ -693,7 +693,7 @@ > > short_name = value; > > } > > > > - if (EQ (keyword, Qlong_name)) > > + else if (EQ (keyword, Qlong_name)) > > { > > CHECK_STRING (value); > > long_name = value; > > This patch is correct. Please send it to xemacs-patches with ChangeLog entry. However, I think XEmacs handles sort-name properly since both (EQ (keyword, Qshort_name)) and (EQ (keyword, Qlong_name)) will never be true at the same time. It's just a little bit of performance loss if a compiler is not smart enough. But it's definitely a good thing to improve the readability of source code. -- Yoshiki Hayashi From xemacs-announce-admin@xemacs.org Tue May 8 01:15:22 2001 Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA21365; Tue, 8 May 2001 01:15:20 -0400 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14wzn1-0000Vp-00; Mon, 07 May 2001 22:12:03 -0700 Received: from gwyn.tux.org ([207.96.122.8] ident=ident-user) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14wzml-0000U6-00 for ; Mon, 07 May 2001 22:11:47 -0700 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA21250 for ; Tue, 8 May 2001 01:11:38 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f485BWl20910 for ; Tue, 8 May 2001 15:11:33 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f485BCZf014881; Tue, 8 May 2001 15:11:12 +1000 To: XEmacs Announce Subject: [ANNOUNCE] Updated Packages Released. - May 8. From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 08 May 2001 15:11:12 +1000 Message-ID: Lines: 243 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: xemacs-announce-admin@xemacs.org Errors-To: xemacs-announce-admin@xemacs.org X-BeenThere: xemacs-announce@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Announcements List-Unsubscribe: , Hey there Folks. The following XEmacs Packages have been released, which you can grab from ftp.xemacs.org/pub/xemacs/packages/ (or from any of its mirror sites). There are installation instructions at the end of this message. Enjoy. build-1.01-pkg.tar.gz *** New Package *** ===================== The `build' command generates a widget-based interface to configure and build XEmacs either using GNU Tools (`configure', `make') or Microsoft Tools (`nmake' with command-line options (<= 21.2-b32) or `config.inc' configuration file (> 21.2-b32)). calc-1.15-pkg.tar.gz ==================== 2001-04-16 Felicia Neff * calc.texinfo: Fix up @direntry. 2001-04-11 Nick V. Pakoulin * calc.el (calc-init-base): Added support for numeric keypad. dired-1.10-pkg.tar.gz ===================== 2001-03-31 Michael Sperber [Mr. Preprocessor] * Makefile.dired: Added IGNORE_CUSTOM variable to control inclusion of cust-stub.el. * cust-stub.el: Added, courtesy of Noah Friedman . * dired.el (dired-recursive-delete-directory): Hopefully make it less Unix-dependent. * Makefile (REQUIRES): Add prog-modes dependency. * diff.el: Remove diff parsing code, now uses Stefan Monnier's diff-mode which is far more robust. (diff): Properly support `diff-do-narrow'. edit-utils-1.59-pkg.tar.gz ========================== 2001-04-20 Karl M. Hegbloom * id-select.el (id-select-thing-with-mouse): Use `own-selection' in newest XEmacs. 2001-04-21 Ben Wing * func-menu.el: * func-menu.el (fume-add-menubar-entry): * func-menu.el (fume-do-add-menubar-entry): New. * func-menu.el (fume-update-menubar-entry): When invoked from find-file-hooks, delay creation of menubar entry until XEmacs becomes idle. This way, func-menu will not intrude when files are loaded temporarily (e.g. as part of patch-to-change-log). 2001-04-06 Glynn Clements * man.el (manual-entry): limit search to current line when trying to find a default. fsf-compat-1.09-pkg.tar.gz ========================== 2001-04-28 Steve Youngs * goto-addr.el: Added. mail-lib-1.37-pkg.tar.gz ======================== 2001-03-30 David M. Karr * smtpmail.el (smtpmail-send-it): Use (user-mail-address). pcl-cvs-1.54-pkg.tar.gz ======================= 2001-04-12 Mike Sperber * pcl-cvs.el (cvs-mode-diff): Remove call to `cvs-prepare-diff-mode'. Use diff-mode again. * cvs-compat.el (cvs-prepare-diff-mode): Remove again. * Makefile (REQUIRES): Add prog-modes. prog-modes-1.37-pkg.tar.gz ========================== 2001-04-23 Karl M. Hegbloom * cperl-mode.el (cperl-pod2man-build-command): Man-filter-list is not always bound, depending on which man viewer you are using. Only set flist when boundp Man-filter-list. 2001-04-20 Trey Belew * cperl-mode.el (pod-spell): New. (make-pod-list): New. 2001-04-14 Alex Schroeder * sql.el (sql-escape-newlines-and-send): New function. (sql-db2): Set comint-input-sender to sql-escape-newlines-and-send. 2001-04-13 Alex Schroeder * sql.el (sql-db2-program): New option. (sql-db2-options): New option. (sql-db2): New function. text-modes-1.30-pkg.tar.gz ========================== 2001-04-02 Glynn Clements * hexl.el (hexl-find-file): force use of 'binary coding-system tm-1.27-pkg.tar.gz ================== Nothing updated in this package, it was just re-released because of a problem in the package-index file. vc-1.27-pkg.tar.gz ================== 2001-04-26 Albert L. Ting * vc.el (vc-do-command): (vc-revert-buffer): Fix a bug that could cause files to be moved to another directory. 2001-04-26 Albert L. Ting * vc-hooks.el (vc-mode-face): New. (vc-mode-ext): New. (vc-mode-line): Use them. xemacs-base-1.53-pkg.tar.gz =========================== 2001-04-23 Ben Wing * compile.el (compilation-shell-minor-mode): Remember to localize the menubar before adding to it. 2001-04-21 Ben Wing * sort.el: need autoload for sort-regexp-fields-numerically. 2001-04-21 Ben Wing * add-log.el (change-log-mode): Fix paragraph filling to correctly handle descriptor lines (those beginning with e.g. * add-log.el (change-log-mode):). * add-log.el (patch-to-change-log): Don't error if patch blank. 2001-04-20 Ben Wing * sort.el: * sort.el (sort): New. * sort.el (sort-subr): * sort.el (sort-fields): * sort.el (sort-regexp-fields): * sort.el (sort-regexp-fields-numerically): New. * sort.el (sort-columns): Synch with FSF 20.7. Add new arg for compare fun to `sort-subr', `sort-regexp-fields'. New command `sort-regexp-fields-numerically'. 2001-04-10 Ben Wing * add-log.el (patch-to-change-log): Fix warnings. Make sure font-lock-auto-fontify is not turned off when visiting ChangeLogs, so that they end up font-locked when all is done. Anchor file-re1 at begline to avoid problems when the diff itself contains `Index:'. xemacs-devel-1.33-pkg.tar.gz ============================ 2001-05-07 Didier Verna * Patcher 2.2 is released. 2001-04-26 Steve Youngs * Makefile (REQUIRES): Add mail-lib. 2001-04-25 Didier Verna * Patcher 2.1 is released. 2001-04-12 Steve Youngs * patcher.el: New 2001-04-10 Ben Wing * docref.el: Use correct name for hook. xslt-process-1.03-tar.gz ======================== 2001-04-30 Ovidiu Predescu * Makefile: Define the proper paths where the files should go. * lisp/xslt-process.el (xslt-process-find-xslt-directory): Modified to take into account the XEmacs packaging scheme. Installation Instructions: ========================= Manual: ------ Simply download the package files to your hard disk and then unpack them to '/usr/local/lib/xemacs/xemacs-packages/' Automatic (XEmacs 21.1.x): ------------------------- 1) Options -> Manage Packages -> Add Download Site -> choose site. 2) Options -> Manage Packages -> List and Install 3) Choose the packages you wish to install/upgrade (there are brief instructions at the bottom of the 'Packages' buffer). 4) Packages -> Add Required 5) Packages -> Install/Remove Selected 6) Re-start XEmacs. Automatic (XEmacs 21.2.x and above): ----------------------------------- 1) Tools -> Packages -> Add Download Site -> choose site. 2) Tools -> Packages -> List and Install 3 - 6) Same as for XEmacs 21.1. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From kasahara@nc.kyushu-u.ac.jp Tue May 8 01:35:41 2001 Received: from elvenbow.nc.kyushu-u.ac.jp (elvenbow.nc.kyushu-u.ac.jp [133.5.6.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA22683; Tue, 8 May 2001 01:35:39 -0400 Received: from localhost (kasahara@elvenbow.nc.kyushu-u.ac.jp [127.0.0.1]) by elvenbow.nc.kyushu-u.ac.jp (8.11.3/8.11.1) with ESMTP id f485ZbP25255; Tue, 8 May 2001 14:35:37 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Tue, 08 May 2001 14:35:37 +0900 (JST) Message-Id: <20010508.143537.1010766513.kasahara@nc.kyushu-u.ac.jp> To: yoshiki@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: make-charset doesn't handle 'short-name' properly From: Yoshiaki Kasahara In-Reply-To: <87d79kpiay.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <20010425.171837.884091679.kasahara@nc.kyushu-u.ac.jp> <20010507.222740.749333612.kasahara@nc.kyushu-u.ac.jp> <87d79kpiay.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: Mew version 1.95b121 on XEmacs 21.5-b0 (alfalfa) X-Fingerprint: 31 DC 9F DF C2 B9 8E 00 3A 7C 4F 0C 03 D8 AC 16 X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 08 May 2001 13:37:41 +0900, Yoshiki Hayashi said: > This patch is correct. Please send it to xemacs-patches > with ChangeLog entry. Ok, I'll try... > However, I think XEmacs handles > sort-name properly since both (EQ (keyword, Qshort_name)) > and (EQ (keyword, Qlong_name)) will never be true at the > same time. Well, I believe that if keyword is 'short_name', the control flow will go through to final 'else' phrase and cause signal_simple_error(). -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University kasahara@nc.kyushu-u.ac.jp From yoshiki@xemacs.org Tue May 8 02:02:56 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA23621 for ; Tue, 8 May 2001 02:02:51 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4862oE07247; Tue, 8 May 2001 15:02:50 +0900 To: Yoshiaki Kasahara Cc: xemacs-beta@xemacs.org Subject: Re: make-charset doesn't handle 'short-name' properly References: <20010425.171837.884091679.kasahara@nc.kyushu-u.ac.jp> <20010507.222740.749333612.kasahara@nc.kyushu-u.ac.jp> <87d79kpiay.fsf@u.sanpo.t.u-tokyo.ac.jp> <20010508.143537.1010766513.kasahara@nc.kyushu-u.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 08 May 2001 15:02:49 +0900 In-Reply-To: <20010508.143537.1010766513.kasahara@nc.kyushu-u.ac.jp> (Yoshiaki Kasahara's message of "Tue, 08 May 2001 14:35:37 +0900 (JST)") Message-ID: <873dagped2.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 14 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Yoshiaki Kasahara writes: > > However, I think XEmacs handles > > sort-name properly since both (EQ (keyword, Qshort_name)) > > and (EQ (keyword, Qlong_name)) will never be true at the > > same time. > > Well, I believe that if keyword is 'short_name', the control flow will > go through to final 'else' phrase and cause signal_simple_error(). Doh! Thanks for explanation. -- Yoshiki Hayashi From nk@lamia.lf.net Tue May 8 02:38:42 2001 Received: from lamia.lf.net (lamia.LF.net [212.9.160.192]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA24742 for ; Tue, 8 May 2001 02:38:41 -0400 Received: by lamia.lf.net (Smail3.2.0.111/lamia.lf.net) via LF.net GmbH Internet Services for mail.xemacs.org id m14x18E-001Sq4C; Tue, 8 May 2001 08:38:02 +0200 (CEST) Sender: nk@lamia.lf.net (Norbert Koch) To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org, sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> Organization: LF.net GmbH X-Attribution: viteno X-NCC-RegID: de.lfnet X-URL: http://www.LF.net/ X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R: lt{Y/s1g[=5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 08 May 2001 08:38:02 +0200 Message-ID: Lines: 76 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: Hi! > --with-prefix=no is compatible with --prefix=..., it says "don't build > $prefix into the executable". Ah, haven't known that. > NK> Could it be a problem that I build xemacs-packages out of CVS > NK> using a make install, ie I've got a symlinked package tree? > > Don't think so. > > Where exactly are your packages? What does `src/xemacs --debug-paths' > say? Thanks for the pointer. It looks strange..... I've got /sw/i386_fbsd4/xemacs-21.5/lib/xemacs as product of a make install out of xemacs-packages Local.rules define XEMACS_STAGING = /sw/i386_fbsd3/xemacs-21.5/lib/xemacs/xemacs-packages MULE_STAGING = /sw/i386_fbsd3/xemacs-21.5/lib/xemacs/mule-packages Now, the paths look like /usr/users/support/nk/cvs/xemacs/src $ ./xemacs --debug-paths emacs-roots: ("/usr/users/support/nk/cvs/xemacs/" "/sw/i386_fbsd4/xemacs-21.5/") configure-package-path: nil early-packages and early-package-load-path: nil nil late-packages and late-package-load-path: ("/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/" "/usr/users/support/nk/cvs/xemacs-packages/" "/usr/users/support/nk/cvs/xemacs-packages/comm/" "/usr/users/support/nk/cvs/xemacs-packages/games/" "/usr/users/support/nk/cvs/xemacs-packages/libs/" "/usr/users/support/nk/cvs/xemacs-packages/mule/" "/usr/users/support/nk/cvs/xemacs-packages/oa/" "/usr/users/support/nk/cvs/xemacs-packages/os/" "/usr/users/support/nk/cvs/xemacs-packages/prog/" "/usr/users/support/nk/cvs/xemacs-packages/wp/") ("/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/edict/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/egg-its/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/leim/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/locale/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/lookup/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/mule-base/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/lisp/skk/") last-packages and last-package-load-path: nil nil lisp-directory: "/usr/users/support/nk/cvs/xemacs/lisp/" mule-lisp-directory: "/usr/users/support/nk/cvs/xemacs/lisp/mule/" Info-directory-list: ("/usr/users/support/nk/cvs/xemacs/info/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/info/" "/usr/local/info" "/usr/share/info") exec-directory: /usr/users/support/nk/cvs/xemacs/lib-src/ exec-path: ("/usr/users/support/nk/bin/" "/client/bin/" "/usr/local/bin/" "/bin/" "/usr/bin/" "/usr/X11R6/bin/" "/prj/bin/" "/client/sbin/" "/sbin/" "/usr/sbin/" "/etc/" "/bin/" "/usr/users/support/nk/cvs/xemacs/lib-src/") doc-directory: "/usr/users/support/nk/cvs/xemacs/lib-src/" data-directory: "/usr/users/support/nk/cvs/xemacs/etc/" data-directory-list: ("/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/app-defaults/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/mule/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/mule-doc/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/skk/" "/sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages/etc/start-files/" "/usr/users/support/nk/cvs/xemacs/etc/") It's funny, the mule-packages lie in the destination emacs-root, while the xemacs-packages are found in the source emacs-root. Hmm, strange, well for me, that is. As Steve has pointed out, I would also have thought that the checks run without any packages installed, because this inherently causes a first installation of the xemacs core to fail. norbert. From yoshiki@xemacs.org Tue May 8 03:27:48 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA26592; Tue, 8 May 2001 03:27:40 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f487RZE08044; Tue, 8 May 2001 16:27:35 +0900 To: xemacs-beta@xemacs.org Cc: ben@xemacs.org Subject: find-tag infloop From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue_May__8_16:27:35_2001-1" Date: 08 May 2001 16:27:35 +0900 Message-ID: <87wv7snvvc.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 106 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) --Multipart_Tue_May__8_16:27:35_2001-1 Content-Type: text/plain; charset=US-ASCII xemacs -vanilla M-. will loop infinitely. This is because (while (file-exists-p (setq cur (expand-file-name ".." cur))) (let ((parent-tag-file (expand-file-name "TAGS" cur))) (when (file-readable-p parent-tag-file) (push parent-tag-file result)))) doesn't terminate. On linux, (file-exists-p (expand-file-name ".." "/")) returns t. In my case, varible cur changes like this: /home/penny /home / /.. / /.. / file-exists-p returns t for all of them. I just worked around this problem by setting tags-check-parent-directories-for-tag-files to nil. --Multipart_Tue_May__8_16:27:35_2001-1 Content-Type: text/plain; charset=US-ASCII uname -a: Linux u 2.2.19 #1 Mon Apr 9 15:27:31 JST 2001 i686 unknown ../../xemacs/configure '--with-mule' XEmacs 21.5-b0 "alfalfa" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /home/penny/work/xemacs Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Compiling in support for Canna on Mule. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- --Multipart_Tue_May__8_16:27:35_2001-1 Content-Type: text/plain; charset=US-ASCII -- Yoshiki Hayashi --Multipart_Tue_May__8_16:27:35_2001-1-- From martin@m17n.org Tue May 8 03:28:12 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA26630; Tue, 8 May 2001 03:28:07 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA28945; Tue, 8 May 2001 16:28:00 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA07716; Tue, 8 May 2001 16:27:59 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f487Rxf15742; Tue, 8 May 2001 16:27:59 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.40959.199977.165302@gargle.gargle.HOWL> Date: Tue, 8 May 2001 16:27:59 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: XEmacs Beta Test , Andy Piper , Ben Wing Subject: Interactive customize buffer button widgets broken or non-existent X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid If I get a customize buffer, e.g. by doing M-x customize-variable RET case-fold-search RET Then in 21.1.14, I see 3-d buttons Set Save and Done, presumably as God intended. In 21.5 --with-widgets, the Set, Save, and Done buttons become 2-d and non-mouse-track-sensitive. Which looks really ugly, since the Reset stays 3-d. In 21.5 -without-widgets, the Set, Save, and Done buttons simply disappear. Do the buttons in customize buffers in 21.5 (or 21.4) actually work correctly for anyone on Unix? From sperber@informatik.uni-tuebingen.de Tue May 8 03:29:29 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA26671 for ; Tue, 8 May 2001 03:29:28 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id A725D1062; Tue, 8 May 2001 09:29:21 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f487TKg02659; Tue, 8 May 2001 09:29:20 +0200 (CEST) (envelope-from sperber) To: Norbert Koch Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 08 May 2001 09:29:19 +0200 In-Reply-To: (Norbert Koch's message of "08 May 2001 08:38:02 +0200") Message-ID: Lines: 12 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Norbert" == Norbert Koch writes: Norbert> It's funny, the mule-packages lie in the destination emacs-root, while Norbert> the xemacs-packages are found in the source emacs-root. Norbert> Hmm, strange, well for me, that is. Do xemacs-packages exit in the destination emacs-root? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From steve@turnbull.sk.tsukuba.ac.jp Tue May 8 03:45:18 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA27306; Tue, 8 May 2001 03:45:16 -0400 Received: by localhost id m14x23E-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 8 May 2001 16:36:56 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.41496.245600.62812@turnbull.sk.tsukuba.ac.jp> Date: Tue, 8 May 2001 16:36:56 +0900 To: Yoshiki Hayashi Cc: Yoshiaki Kasahara , xemacs-beta@xemacs.org Subject: Re: make-charset doesn't handle 'short-name' properly In-Reply-To: <87d79kpiay.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <20010425.171837.884091679.kasahara@nc.kyushu-u.ac.jp> <20010507.222740.749333612.kasahara@nc.kyushu-u.ac.jp> <87d79kpiay.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Yoshiki" == Yoshiki Hayashi writes: Yoshiki> But it's definitely a good thing to improve the Yoshiki> readability of source code. OK, so that means there's no behavior problem and I _don't_ apply to 21.4? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From martin@m17n.org Tue May 8 03:49:21 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA27510 for ; Tue, 8 May 2001 03:49:20 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA29163; Tue, 8 May 2001 16:49:14 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA07888; Tue, 8 May 2001 16:49:13 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f487nCX16423; Tue, 8 May 2001 16:49:12 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.42232.701854.939901@gargle.gargle.HOWL> Date: Tue, 8 May 2001 16:49:12 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Michael Sperber , XEmacs Beta Test Subject: Extremely hostile init file migration experience with 21.5. X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Suppose I create a trivial .emacs file like rm .emacs; touch .emacs then run xemacs xemacs -no-site-file XEmacs *looks* like it's perfectly content merely putting up the splash screen, when in fact it's asking a question. If I then type M-x, I get Command attempted to use minibuffer while in minibuffer (and I see a Help buffer with migration instructions) even though there was no clue the minibuffer was active. Even more horrible things, from a UI perspective, happen if the user does File->Open as the first action in the xemacs session. A broken file dialog box appears, and this message is displayed: Minibuffer already active: abort it with `^]', enable new one with `n': From steve@turnbull.sk.tsukuba.ac.jp Tue May 8 03:56:17 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA27807 for ; Tue, 8 May 2001 03:56:15 -0400 Received: by localhost id m14x2Dp-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 8 May 2001 16:47:53 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.42153.345971.83025@turnbull.sk.tsukuba.ac.jp> Date: Tue, 8 May 2001 16:47:53 +0900 To: Norbert Koch Cc: xemacs-beta@xemacs.org, sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] In-Reply-To: References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "NK" == Norbert Koch writes: NK> It's funny, the mule-packages lie in the destination NK> emacs-root, while the xemacs-packages are found in the NK> source emacs-root. I guess this could be due to symlinks, then. Note that no actual packages are being found (except in Mule). Do you have any Mule packages in cvs? NK> As Steve has pointed out, I would also have thought that the NK> checks run without any packages installed, because this NK> inherently causes a first installation of the xemacs core to NK> fail. No, "make install" does not run "make check". Shouldn't, anyway. So this doesn't prevent installation. These checks _definitely_ will not run without packages available, because the libraries that define those functions are not in core. I don't know how to deal with this. I think probably the tests/automated stuff should condition-case the requires, and if they fail run a limited subset or tests, and warn. I don't think that's a bad thing; if packages exercise some part of xemacs well, I don't see why we shouldn't use them in testing (if the alternative is that we don't write any tests). But that's not my job at the moment. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From nk@lamia.lf.net Tue May 8 04:04:53 2001 Received: from lamia.lf.net (lamia.LF.net [212.9.160.192]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA28304 for ; Tue, 8 May 2001 04:04:52 -0400 Received: by lamia.lf.net (Smail3.2.0.111/lamia.lf.net) via LF.net GmbH Internet Services for mail.xemacs.org id m14x2Te-001Sq4C; Tue, 8 May 2001 10:04:14 +0200 (CEST) Sender: nk@lamia.lf.net (Norbert Koch) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> Organization: LF.net GmbH X-Attribution: viteno X-NCC-RegID: de.lfnet X-URL: http://www.LF.net/ X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R: lt{Y/s1g[=5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 08 May 2001 10:04:14 +0200 In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "08 May 2001 09:29:19 +0200") Message-ID: Lines: 27 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Hi! >>>>>> "Norbert" == Norbert Koch writes: > > Norbert> It's funny, the mule-packages lie in the destination emacs-root, while > Norbert> the xemacs-packages are found in the source emacs-root. > > Norbert> Hmm, strange, well for me, that is. > > Do xemacs-packages exit in the destination emacs-root? /usr/users/support/nk/cvs/xemacs-packages is the top-level of my CVS package sources. There, as you know, we have another structure. I don't grok the fact that mule-package paths are okay, xemacs-package paths are not. Where would I look for this? Should I try to fix package paths during configure? Thanks, norbert. From nk@lamia.lf.net Tue May 8 04:06:13 2001 Received: from lamia.lf.net (lamia.LF.net [212.9.160.192]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA28364 for ; Tue, 8 May 2001 04:06:13 -0400 Received: by lamia.lf.net (Smail3.2.0.111/lamia.lf.net) via LF.net GmbH Internet Services for mail.xemacs.org id m14x2Uw-001Sq4C; Tue, 8 May 2001 10:05:34 +0200 (CEST) Sender: nk@lamia.lf.net (Norbert Koch) To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org, sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> <15095.42153.345971.83025@turnbull.sk.tsukuba.ac.jp> Organization: LF.net GmbH X-Attribution: viteno X-NCC-RegID: de.lfnet X-URL: http://www.LF.net/ X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R: lt{Y/s1g[=5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 08 May 2001 10:05:34 +0200 In-Reply-To: <15095.42153.345971.83025@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Tue, 8 May 2001 16:47:53 +0900") Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: Hi! > I guess this could be due to symlinks, then. Note that no actual > packages are being found (except in Mule). Do you have any Mule > packages in cvs? Yes, I've got the whole package tree lying around as in cvs checkout xemacs-packages norbert. From sperber@informatik.uni-tuebingen.de Tue May 8 04:23:45 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA29108 for ; Tue, 8 May 2001 04:23:44 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id D08791079; Tue, 8 May 2001 10:23:37 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f488NbK02812; Tue, 8 May 2001 10:23:37 +0200 (CEST) (envelope-from sperber) To: Norbert Koch Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 08 May 2001 10:23:37 +0200 In-Reply-To: (Norbert Koch's message of "08 May 2001 10:04:14 +0200") Message-ID: Lines: 55 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "norbert" == Norbert Koch writes: norbert> sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: norbert> Hi! >>>>>>> "Norbert" == Norbert Koch writes: >> Norbert> It's funny, the mule-packages lie in the destination emacs-root, while Norbert> the xemacs-packages are found in the source emacs-root. >> Norbert> Hmm, strange, well for me, that is. >> >> Do xemacs-packages exit in the destination emacs-root? norbert> /usr/users/support/nk/cvs/xemacs-packages norbert> is the top-level of my CVS package sources. There, as you know, we norbert> have another structure. norbert> I don't grok the fact that mule-package paths are okay, norbert> xemacs-package paths are not. That's because XEmacs thinks your checked-out CVS sandbox *is* the xemacs-package hierarchy while it isn't. (Ben wanted this feature very badly.) The solution is to move it somewhere else or to make a symlink from the actual xemacs-package hierarchy to inside your build directory. For example, my build directory looks like this: -rw-r--r-- 1 sperber PUstaff 2873 Apr 30 15:22 Installation -r--r--r-- 1 sperber PUstaff 11887 Apr 30 15:22 Makefile -rw-r--r-- 1 sperber PUstaff 25605 Apr 30 15:22 Makefile.in -rw-r--r-- 1 sperber PUstaff 105298 Apr 30 15:22 config.log -rwxr-xr-x 1 sperber PUstaff 55979 Apr 30 15:22 config.status* lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 etc@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/etc lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 info@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/info drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:29 lib-src/ lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 lisp@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/lisp drwxr-xr-x 2 sperber PUstaff 2048 Apr 13 11:52 lock/ drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:24 lwlib/ lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 man@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/man lrwxr-xr-x 1 sperber PUstaff 73 Apr 13 12:03 site-packages@ -> /afs/informatik.uni-tuebingen.de/share/xemacs-21/lib/xemacs/site-packages drwxr-xr-x 2 sperber PUstaff 6144 Apr 30 15:29 src/ lrwxr-xr-x 1 sperber PUstaff 64 Apr 13 11:52 tests@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/tests lrwxr-xr-x 1 sperber PUstaff 75 Apr 13 12:03 xemacs-packages@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-packages/staging Everything except site-packages and xemacs-packages was installed automatically by configure and make. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From yoshiki@xemacs.org Tue May 8 09:26:29 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA08066; Tue, 8 May 2001 09:26:27 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f48DQOE10907; Tue, 8 May 2001 22:26:24 +0900 To: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el References: <15093.49523.736978.443168@gargle.gargle.HOWL> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 08 May 2001 22:26:24 +0900 In-Reply-To: <15093.49523.736978.443168@gargle.gargle.HOWL> (Alexey Mahotkin's message of "Mon, 7 May 2001 01:26:11 +0400 (MSD)") Message-ID: <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 24 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Alexey Mahotkin writes: > I've fixed `list-coding-systems', both with C-u (it simply works now > ;) and without it (it now lists only base coding systems, as per > documentation). It was broken because interface of appropriate > functions changed heavily. > > It was necessary to change record separator from colon to semicolon > because some coding systems have colons in their names. > > Hope it will go into base XEmacs (notify me in that case, please :) Thanks for the patch. Your patch is good and I'd like to approve it. But I can't since mule-diag.el is in the package. XEmacs 21.1 does not have functions like coding-system-aliasee. I think mule-diag.el should belong to core so that it can avoid issues like this. But the status quo is that mule-diag.el belongs to mule-base package and XEmacs 21.1 must be supported by package. Could you please fix it to work with XEmacs 21.1? Then that will definitely go in. -- Yoshiki Hayashi From steve@turnbull.sk.tsukuba.ac.jp Tue May 8 11:43:18 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA15730; Tue, 8 May 2001 11:43:11 -0400 Received: by localhost id m14x9Vc-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 00:34:44 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.4627.125124.352427@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 00:34:43 +0900 To: Yoshiki Hayashi Cc: xemacs-beta@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el In-Reply-To: <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Yoshiki" == Yoshiki Hayashi writes: Yoshiki> Your patch is good and I'd like to approve it. But I Yoshiki> can't since mule-diag.el is in the package. XEmacs 21.1 Yoshiki> does not have functions like coding-system-aliasee. I Yoshiki> think mule-diag.el should belong to core so that it can Yoshiki> avoid issues like this. I tend to disagree. The functions in that file are basically developer's aids; they have little to do with the Mule implementation per se. An excellent candidate for packagization, IMO. I don't see why the same argument doesn't apply to all packages that use APIs that might change. calc comes to mind as an example of a library that has been "attacked" many times by unexpected API changes, but surely you wouldn't advocate moving calc to the core. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From andyp@bea.com Tue May 8 11:56:54 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA16513; Tue, 8 May 2001 11:56:53 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA08394; Tue, 8 May 2001 08:56:51 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001348wss.beasys.com [192.168.6.179]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id IAA05924; Tue, 8 May 2001 08:57:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 May 2001 08:54:43 -0700 To: Martin Buchholz , XEmacs Beta Test , Andy Piper , Ben Wing From: Andy Piper Subject: Re: Interactive customize buffer button widgets broken or non-existent In-Reply-To: <15095.40959.199977.165302@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:27 PM 5/8/01 +0900, Martin Buchholz wrote: >In 21.5 --with-widgets, the Set, Save, and Done buttons become 2-d and >non-mouse-track-sensitive. Which looks really ugly, since the Reset >stays 3-d. They are 3d if you use the appropriate widget set. What were you hoping they would be sensitive to? The reset is not 3d because an appropriate widget does not exist on all platforms (mainly athena). andy From andyp@bea.com Tue May 8 11:58:23 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA16633 for ; Tue, 8 May 2001 11:58:22 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA08648; Tue, 8 May 2001 08:58:27 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001348wss.beasys.com [192.168.6.179]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id IAA06178; Tue, 8 May 2001 08:59:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 May 2001 08:56:19 -0700 To: James LewisMoss From: Andy Piper Subject: Re: Update to last message Cc: xemacs-beta@xemacs.org In-Reply-To: References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed So I can't reproduce this on RH 7.0, so maybe there is something extra in your environment. I started XEmacs -vanilla and then brought up the file and switched on font-lock. Is there anything else I should do? andy At 03:57 PM 5/7/01 -0400, James LewisMoss wrote: > >>>>> On Mon, 07 May 2001 09:41:23 -0700, Andy Piper said: > > Andy> If you can send me a file that crashes XEmacs when font-locked > Andy> that would be swell. I should be able to nail it then. > >So far it's been a directory listing that I've found to crash it. >I'll try to find a file as well. Kewl. Just found one. Between the >----s > >----------------------------------------------------------------- >#include >#include >int main (void) >{ > unsigned long msize = 64; > if (msize != 0 && ((msize - 1) > (2147483647L * 2UL + 1))) > fprintf (stderr, "test FAILED\n"); > exit (0); >} >----------------------------------------------------------------- > > Andy> Can you also print the contents of w. > >(gdb) up >#1 0x8172886 in GaugeExpose (w=0x8642480, event=0xbfffddec, >region=0x8428208) at xlwgauge.c:425 >425 XDrawLine(dpy,win,gctop, e0+1,y, e1-1,y) ; >(gdb) print *w >$1 = {core = {self = 0x8642480, widget_class = 0x81a7fe0, parent = >0x8642138, xrm_name = 1131, being_destroyed = 0 '\000', destroy_callbacks >= 0x8647260, constraints = 0x0, x = 0, y = 0, width = 250, height = 24, >border_width = 1, managed = 1 '\001', sensitive = 1 '\001', >ancestor_sensitive = 1 '\001', event_table = 0x0, tm = {translations = >0x8642468, proc_table = 0x84e9038, current_state = 0x0, lastEventTime = >0}, accelerators = 0x0, border_pixel = 0, border_pixmap = 2, popup_list = >0x0, num_popups = 0, name = 0x83f38d7 "Progress", screen = 0x845ef08, >colormap = 32, window = 20971708, depth = 16, background_pixel = 25388, >background_pixmap = 2, visible = 1 '\001', mapped_when_managed = 1 '\001'}} >(gdb) info locals >gw = 0x8642480 >dpy = (Display *) 0x83e43c0 >win = 20971708 >gc = 0x66200008 >gctop = 0x66200008 >gcbot = 0x66200008 >len = 20971708 >e0 = 9848 >e1 = -9599 >x = 135735124 >y = 64469 >i = 0 >v0 = 0 >v1 = 100 >value = 0 >(gdb) info args >w = 0x8642480 >event = (XEvent *) 0xbfffddec >region = 0x8428208 >(gdb) > > >Again I just loaded the elisp from the last message (actually missing >the last few related to dired). Then I opened the file. and did M-x >font-lock-mode and it crashed. I an still see the two boxes in the >box at the bottom of the screen. It says "Fontifying >ulong-test.c...". > >Thanks >Jim > >-- >@James LewisMoss | Blessed Be! >@ http://jimdres.home.mindspring.com | Linux is kewl! >@"Argue for your limitations and sure enough, they're yours." Bach From steve@turnbull.sk.tsukuba.ac.jp Tue May 8 12:57:23 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA20052; Tue, 8 May 2001 12:57:16 -0400 Received: by localhost id m14xAfH-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 01:48:47 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.9070.726354.454718@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 01:48:46 +0900 To: Andy Piper Cc: Martin Buchholz , XEmacs Beta Test , Ben Wing Subject: Re: Interactive customize buffer button widgets broken or non-existent In-Reply-To: <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> References: <15095.40959.199977.165302@gargle.gargle.HOWL> <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Andy" == Andy Piper writes: Andy> [Customize buttons] are 3d if you use the appropriate widget Andy> set. Yup. Works for me. Andy> What were you hoping they would be sensitive to? The reset Andy> is not 3d because an appropriate widget does not exist on Andy> all platforms (mainly athena). You mean the button/select-menu thingee? What's wrong with the way it's done with the Lisp widget (namely using a standard button and a popup menu rather than the newfangled popup-menu-in-place-button)? Is this for some reason not doable, or merely unimplemented for lack of time? I've noticed two other bugs btw (old build, 21.2.46 Urania, but I doubt this has changed). (1) the labels are not centered in the native buttons; they're apparently flush right. (Xaw3d widgets.) (2) if you _don't_ select from the reset menu, the reset button stays depressed after the menu disappears. To get it to stay down I need to press the mouse button while on the reset button, then drag to the title area of the popup menu, then release. clicking on the button behaves correctly: the menu pops up and stays, when it pops down the button returns to "up" state. However, clicking on it again brings up the menu and then the button pops back up. (obviously this isn't a native widget issue.) uname -a: Linux tleepslib2 2.2.13 #1 Wed Mar 15 23:15:54 JST 2000 i586 unknown /coda/Projects/XEmacs/21.2-HEAD/configure '--with-mule' '--with-xim=xlib' '--with-widgets=athena' '--with-athena=3d' '--pdump' '--with-xfs' '--srcdir=/coda/Projects/XEmacs/21.2-HEAD' XEmacs 21.2-b46 "Urania" configured for `i586-pc-linux'. Compilation / Installation: Source code location: /coda/Projects/XEmacs/21.2-HEAD Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw3d - Athena library to link: Xaw3d Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Databases: Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. - Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Using the new portable dumper. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From jimdres@mindspring.com Tue May 8 12:58:24 2001 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA20111 for ; Tue, 8 May 2001 12:58:24 -0400 Received: from eeyore.lewismoss.org (user-2ivf7p6.dialup.mindspring.com [165.247.159.38]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA25997; Tue, 8 May 2001 12:55:45 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14xAlM-0007GV-00; Tue, 08 May 2001 12:55:04 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> From: James LewisMoss In-Reply-To: Andy Piper's message of "Tue, 08 May 2001 08:56:19 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 08 May 2001 12:54:43 -0400 Message-ID: Lines: 20 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On Tue, 08 May 2001 08:56:19 -0700, Andy Piper said: Andy> So I can't reproduce this on RH 7.0, so maybe there is Andy> something extra in your environment. I started XEmacs -vanilla Andy> and then brought up the file and switched on font-lock. Is Andy> there anything else I should do? Not sure. Maybe something else in the elisp stuff makes a difference (from two or three messages ago I'll resend if you like). Could it be a dark/light/auto background mode thing? Maybe the combination of faces I have? Maybe something broken on Debian. Thanks for all the help. Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From andyp@bea.com Tue May 8 13:05:41 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA20470; Tue, 8 May 2001 13:05:36 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA24587; Tue, 8 May 2001 10:05:40 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001418wss.beasys.com [192.168.6.249]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id KAA21782; Tue, 8 May 2001 10:06:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010508100216.00afebf0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 May 2001 10:03:30 -0700 To: "Stephen J. Turnbull" From: Andy Piper Subject: Re: Interactive customize buffer button widgets broken or non-existent Cc: Martin Buchholz , XEmacs Beta Test , Ben Wing In-Reply-To: <15096.9070.726354.454718@turnbull.sk.tsukuba.ac.jp> References: <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> <15095.40959.199977.165302@gargle.gargle.HOWL> <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:48 AM 5/9/01 +0900, Stephen J. Turnbull wrote: >What's wrong with the way it's done with the Lisp widget (namely using >a standard button and a popup menu rather than the newfangled >popup-menu-in-place-button)? Is this for some reason not doable, or >merely unimplemented for lack of time? Unimplemented because it means delving into the guts of customize - but I guess that could be fixed. >I've noticed two other bugs btw (old build, 21.2.46 Urania, but I >doubt this has changed). > >(1) the labels are not centered in the native buttons; they're >apparently flush right. (Xaw3d widgets.) Hmmn. They are centered in Motif. I wonder what gives. andy From andyp@bea.com Tue May 8 13:06:26 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA20526 for ; Tue, 8 May 2001 13:06:25 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA24777; Tue, 8 May 2001 10:06:30 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001418wss.beasys.com [192.168.6.249]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id KAA22062; Tue, 8 May 2001 10:07:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 May 2001 10:04:21 -0700 To: James LewisMoss From: Andy Piper Subject: Re: Update to last message Cc: xemacs-beta@xemacs.org In-Reply-To: References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:54 PM 5/8/01 -0400, James LewisMoss wrote: > >>>>> On Tue, 08 May 2001 08:56:19 -0700, Andy Piper said: > > Andy> So I can't reproduce this on RH 7.0, so maybe there is > Andy> something extra in your environment. I started XEmacs -vanilla > Andy> and then brought up the file and switched on font-lock. Is > Andy> there anything else I should do? > >Not sure. Maybe something else in the elisp stuff makes a >difference (from two or three messages ago I'll resend if you like). >Could it be a dark/light/auto background mode thing? Maybe the >combination of faces I have? Maybe something broken on Debian. So can you reproduce it using vanilla? If not try building up your .emacs until it breaks. andy From jimdres@mindspring.com Tue May 8 13:58:20 2001 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA23317 for ; Tue, 8 May 2001 13:58:17 -0400 Received: from eeyore.lewismoss.org (user-2ivf7p6.dialup.mindspring.com [165.247.159.38]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA06782; Tue, 8 May 2001 13:55:43 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14xBhO-0007KX-00; Tue, 08 May 2001 13:55:02 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> From: James LewisMoss In-Reply-To: Andy Piper's message of "Tue, 08 May 2001 10:04:21 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 08 May 2001 13:54:42 -0400 Message-ID: Lines: 28 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On Tue, 08 May 2001 10:04:21 -0700, Andy Piper said: Andy> At 12:54 PM 5/8/01 -0400, James LewisMoss wrote: >> >>>>> On Tue, 08 May 2001 08:56:19 -0700, Andy Piper >> >>>>> said: >> Andy> So I can't reproduce this on RH 7.0, so maybe there is Andy> something extra in your environment. I started XEmacs -vanilla Andy> and then brought up the file and switched on font-lock. Is Andy> there anything else I should do? >> >> Not sure. Maybe something else in the elisp stuff makes a >> difference (from two or three messages ago I'll resend if you >> like). Could it be a dark/light/auto background mode thing? >> Maybe the combination of faces I have? Maybe something broken on >> Debian. Andy> So can you reproduce it using vanilla? If not try building up Andy> your .emacs until it breaks. I couldn't. Adding just that code to -vanilla I could reproduce. Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From andyp@bea.com Tue May 8 14:10:00 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA23888 for ; Tue, 8 May 2001 14:09:59 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA09304; Tue, 8 May 2001 11:10:01 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001418wss.beasys.com [192.168.6.249]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id LAA08699; Tue, 8 May 2001 11:10:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20010508110730.00b18cc0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 May 2001 11:07:51 -0700 To: James LewisMoss From: Andy Piper Subject: Re: Update to last message Cc: xemacs-beta@xemacs.org In-Reply-To: References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Do you set a bunch of stuff in Xdefaults? Does this show up even with vanilla? andy At 01:54 PM 5/8/01 -0400, James LewisMoss wrote: > >>>>> On Tue, 08 May 2001 10:04:21 -0700, Andy Piper said: > > Andy> At 12:54 PM 5/8/01 -0400, James LewisMoss wrote: > >> >>>>> On Tue, 08 May 2001 08:56:19 -0700, Andy Piper > >> >>>>> said: > >> > Andy> So I can't reproduce this on RH 7.0, so maybe there is > Andy> something extra in your environment. I started XEmacs -vanilla > Andy> and then brought up the file and switched on font-lock. Is > Andy> there anything else I should do? > >> > >> Not sure. Maybe something else in the elisp stuff makes a > >> difference (from two or three messages ago I'll resend if you > >> like). Could it be a dark/light/auto background mode thing? > >> Maybe the combination of faces I have? Maybe something broken on > >> Debian. > > Andy> So can you reproduce it using vanilla? If not try building up > Andy> your .emacs until it breaks. > >I couldn't. Adding just that code to -vanilla I could reproduce. > >Jim > >-- >@James LewisMoss | Blessed Be! >@ http://jimdres.home.mindspring.com | Linux is kewl! >@"Argue for your limitations and sure enough, they're yours." Bach From amitp@Stanford.EDU Tue May 8 14:32:31 2001 Received: from elaine7.Stanford.EDU (elaine7.Stanford.EDU [171.64.15.72]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA24985 for ; Tue, 8 May 2001 14:32:17 -0400 Received: (from amitp@localhost) by elaine7.Stanford.EDU (8.11.1/8.11.1) id f48IWFU12787; Tue, 8 May 2001 11:32:15 -0700 (PDT) Date: Tue, 8 May 2001 11:32:15 -0700 (PDT) From: Amit Jayant Patel To: Jeff Mincy cc: Subject: Re: Font locking bug - infinite loop In-Reply-To: <15094.64595.590000.271958@antarres.muniversal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 7 May 2001, Jeff Mincy wrote: > > I've been whittling away my ~/.vm file until I could get this bug to > occur reliably. I've also run xemacs -q to avoid loading my own > ~/.emacs file. So I think after many weeks of trying to pin this down, > I've come down to a small bit of ~/.vm code that triggers the bug on > my system. > > > Your pattern > > (setq vm-summary-font-lock-keywords > '(("Re:" 1 yellow t))) > > Matches the first paren expression. (You don't have any) Yes, the 1 should be a 0. It's actually correct in my original .vm file, but it wasn't in my test file. > (setq font-lock-keywords vm-summary-font-lock-keywords) I hadn't done this because my understanding was that font-lock mode automatically picks this up. It was highlighting without my doing this, anyway. Anyway, I made these changes and I'm still getting the bad behavior. :( I think it's related to the frame parameters, actually, because when I take them out, it seems to behave better: (setq vm-frame-parameter-alist '((primary-folder ( (name . "vm") (toolbar-shadow-thickness . 1) (border-width . 3) )))) Does the progress meter use any of the frame parameters? - Amit From jimdres@mindspring.com Tue May 8 14:45:25 2001 Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA25677 for ; Tue, 8 May 2001 14:45:24 -0400 Received: from eeyore.lewismoss.org (user-2ivf7p6.dialup.mindspring.com [165.247.159.38]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA13014; Tue, 8 May 2001 14:42:43 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14xCQs-0007Qv-00; Tue, 08 May 2001 14:42:02 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> <4.3.2.7.2.20010508110730.00b18cc0@san-francisco.beasys.com> From: James LewisMoss In-Reply-To: Andy Piper's message of "Tue, 08 May 2001 11:07:51 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 08 May 2001 14:41:42 -0400 Message-ID: Lines: 48 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On Tue, 08 May 2001 11:07:51 -0700, Andy Piper said: Andy> Do you set a bunch of stuff in Xdefaults? Does this show up Andy> even with vanilla? andy Ah. Damn. Cleared xrdb with "xrdb -remove". Ran xemacs -vanilla (with gdb mixed in there). Opened the C file. And the M-x font-lock-mode and same crash. Maybe this is an X issue. 4.0.3 ldd of the binary shows: libXaw.so.6 => /usr/X11R6/lib/libXaw.so.6 (0x40032000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4006c000) libpng.so.2 => /usr/lib/libpng.so.2 (0x400ae000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x400da000) libz.so.1 => /usr/lib/libz.so.1 (0x400f9000) libcompface.so.1 => /usr/lib/libcompface.so.1 (0x40109000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40114000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40122000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40137000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40181000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4018f000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4026a000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40273000) libdb3.so.3 => /usr/lib/libdb3.so.3 (0x4028a000) libncurses.so.5 => /lib/libncurses.so.5 (0x40336000) libpq.so.2 => /usr/lib/libpq.so.2 (0x40376000) libldap.so.2 => /usr/lib/libldap.so.2 (0x40386000) libm.so.6 => /lib/libm.so.6 (0x403ac000) libutil.so.1 => /lib/libutil.so.1 (0x403ce000) libc.so.6 => /lib/libc.so.6 (0x403d1000) libdl.so.2 => /lib/libdl.so.2 (0x404e4000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x404e9000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40516000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x405e0000) libresolv.so.2 => /lib/libresolv.so.2 (0x4060e000) libnsl.so.1 => /lib/libnsl.so.1 (0x4061f000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40634000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4063e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libdb2.so.2 => /lib/libdb2.so.2 (0x4064a000) libpam.so.0 => /lib/libpam.so.0 (0x4068b000) Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From jimdres@mindspring.com Tue May 8 14:51:55 2001 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA26127 for ; Tue, 8 May 2001 14:51:38 -0400 Received: from eeyore.lewismoss.org (user-2ivf7p6.dialup.mindspring.com [165.247.159.38]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA10317; Tue, 8 May 2001 14:38:34 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14xCMl-0007QS-00; Tue, 08 May 2001 14:37:47 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> <4.3.2.7.2.20010508110730.00b18cc0@san-francisco.beasys.com> From: James LewisMoss In-Reply-To: Andy Piper's message of "Tue, 08 May 2001 11:07:51 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 08 May 2001 14:37:26 -0400 Message-ID: Lines: 14 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On Tue, 08 May 2001 11:07:51 -0700, Andy Piper said: Andy> Do you set a bunch of stuff in Xdefaults? Does this show up Andy> even with vanilla? andy Yes. Forgot about it before. Apologies. I'm playing around with those settings now to see if anything there is causing troubles. Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From jimdres@mindspring.com Tue May 8 15:23:14 2001 Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA28008 for ; Tue, 8 May 2001 15:23:13 -0400 Received: from eeyore.lewismoss.org (user-2ivf7p6.dialup.mindspring.com [165.247.159.38]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA09377; Tue, 8 May 2001 15:20:36 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 14xD1X-0007UO-00; Tue, 08 May 2001 15:19:55 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <3AF5EC2A.D0063822@666.com> <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> <4.3.2.7.2.20010508110730.00b18cc0@san-francisco.beasys.com> From: James LewisMoss In-Reply-To: Andy Piper's message of "Tue, 08 May 2001 11:07:51 -0700" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 08 May 2001 15:19:34 -0400 Message-ID: Lines: 17 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On Tue, 08 May 2001 11:07:51 -0700, Andy Piper said: Andy> Do you set a bunch of stuff in Xdefaults? Does this show up Andy> even with vanilla? andy I've tracked it down to changing one customization. If I change the Progress Feedback Style to "small" I get a bunch of X errors, but no crash. Changing it back to "large" and the crash happens when I open the next file. Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From alexm@hsys.msk.ru Tue May 8 15:48:19 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA29355 for ; Tue, 8 May 2001 15:48:18 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.5) with ESMTP id 7781440 for xemacs-beta@xemacs.org; Tue, 08 May 2001 16:48:11 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp137-35.dialup.mtu-net.ru [62.118.137.35]) by mtu.ru (Postfix) with ESMTP id 7223C7361 for ; Tue, 8 May 2001 23:48:14 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 13092 invoked by uid 1000); 8 May 2001 19:47:18 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.19782.470107.692088@gargle.gargle.HOWL> Date: Tue, 8 May 2001 23:47:18 +0400 (MSD) To: Yoshiki Hayashi Cc: xemacs-beta@xemacs.org, xemacs-patch@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el In-Reply-To: <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "YH" == Yoshiki Hayashi writes: YH> But I can't since mule-diag.el is in the package. XEmacs YH> 21.1 does not have functions like coding-system-aliasee. I've tested this tiny patch to my patch with XEmacs 21.1.10 (those functions were broken there as horribly too): --- mule-diag.el 2001/05/06 21:18:52 1.4 +++ mule-diag.el 2001/05/08 19:15:42 @@ -391,7 +391,8 @@ ;; Print detailed information on CODING-SYSTEM. (defun print-coding-system (coding-system) (princ coding-system) - (if (coding-system-alias-p coding-system) + ;; aliases for coding system are not supported in XEmacs 21.1.x + (if (and (functionp 'coding-system-alias-p) (coding-system-alias-p coding-system)) (princ (format " (alias of %s)\n" (coding-system-aliasee coding-system))) (let ((type (coding-system-type coding-system)) (eol-type (coding-system-eol-type coding-system))) 'encode and 'decode properties in 21.1 are printed out rather incomprehensibly: alternativnyj-mac;ccl;Cy.Alt:t;cr;[1 110 14 1051 21 140 -1017 -1268 ...skipped... 32 32 32 32 32 32 1648 -66292 22];Coding-system used for Alternativnyj This could be somehow "fixed" (at least printing just "there is 'encode/'decode ccl program") simply, as `arrayp' helps to distinguish between old-style and new-style ccl-programs. YH> I think mule-diag.el should belong to core so that it can avoid issues YH> like this. But the status quo is that mule-diag.el belongs to YH> mule-base package and XEmacs 21.1 must be supported by package. Hm. Is there anywhere explained which versions of XEmacsen should be supported by packages? YH> Could you please fix it to work with XEmacs 21.1? Then that will YH> definitely go in. That'd be great even though I understand that no one probably will use those ;) But it was very important patch for my Lisp education (thanks again, Hannu) :) --alexm From nk@lamia.lf.net Tue May 8 16:19:24 2001 Received: from lamia.lf.net (lamia.LF.net [212.9.160.192]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA31240 for ; Tue, 8 May 2001 16:19:24 -0400 Received: by lamia.lf.net (Smail3.2.0.111/lamia.lf.net) via LF.net GmbH Internet Services for mail.xemacs.org id m14xDwS-001Sq4C; Tue, 8 May 2001 22:18:44 +0200 (CEST) Sender: nk@lamia.lf.net (Norbert Koch) To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> Organization: LF.net GmbH X-Attribution: viteno X-NCC-RegID: de.lfnet X-URL: http://www.LF.net/ X-Face: iq-"D}ZS'It[NXourO#`D+JoJC>bZPU\xvX4Um\sR}_zUI?R: lt{Y/s1g[=5L/BHY@]NxB(D?&:tCwX@Vp:YJURe}$MDZ1&/v<`C+^AVc"s/&m`Mu#s| From: Norbert Koch Date: 08 May 2001 22:18:44 +0200 In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "08 May 2001 10:23:37 +0200") Message-ID: Lines: 54 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Ah, I simply love the Internet. It's cute talking to a guy located but 70 km away via a server in the States (It only takes 19 hops to get there :-) [...] > norbert> I don't grok the fact that mule-package paths are okay, > norbert> xemacs-package paths are not. > > That's because XEmacs thinks your checked-out CVS sandbox *is* the > xemacs-package hierarchy while it isn't. (Ben wanted this feature > very badly.) > > The solution is to move it somewhere else or to make a symlink from > the actual xemacs-package hierarchy to inside your build directory. > For example, my build directory looks like this: > > -rw-r--r-- 1 sperber PUstaff 2873 Apr 30 15:22 Installation > -r--r--r-- 1 sperber PUstaff 11887 Apr 30 15:22 Makefile > -rw-r--r-- 1 sperber PUstaff 25605 Apr 30 15:22 Makefile.in > -rw-r--r-- 1 sperber PUstaff 105298 Apr 30 15:22 config.log > -rwxr-xr-x 1 sperber PUstaff 55979 Apr 30 15:22 config.status* > lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 etc@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/etc > lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 info@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/info > drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:29 lib-src/ > lrwxr-xr-x 1 sperber PUstaff 63 Apr 13 11:52 lisp@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/lisp > drwxr-xr-x 2 sperber PUstaff 2048 Apr 13 11:52 lock/ > drwxr-xr-x 2 sperber PUstaff 2048 Apr 30 15:24 lwlib/ > lrwxr-xr-x 1 sperber PUstaff 62 Apr 13 11:52 man@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/man > lrwxr-xr-x 1 sperber PUstaff 73 Apr 13 12:03 site-packages@ -> /afs/informatik.uni-tuebingen.de/share/xemacs-21/lib/xemacs/site-packages > drwxr-xr-x 2 sperber PUstaff 6144 Apr 30 15:29 src/ > lrwxr-xr-x 1 sperber PUstaff 64 Apr 13 11:52 tests@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs/tests > lrwxr-xr-x 1 sperber PUstaff 75 Apr 13 12:03 xemacs-packages@ -> /afs/informatik.uni-tuebingen.de/home/sperber/build/xemacs-packages/staging > > Everything except site-packages and xemacs-packages was installed > automatically by configure and make. Allright, I think, I've got it, at least I don't see the error messages any longer. CWD = /usr/local/users/support/nk/cvs/xemacs which is the toplevel of my xemacs source tree. If I create the two symlinks mule-packages -> /sw/i386_fbsd4/xemacs-21.5/lib/xemacs/mule-packages xemacs-packages -> /sw/i386_fbsd4/xemacs-21.5/lib/xemacs/xemacs-packages everything runs smoothly. I only wonder, why I (or others) haven't noticed this, err, feature, by now. Or should I have R some FM? Thanks for the help, norbert. From alexm@hsys.msk.ru Tue May 8 16:45:21 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA32739 for ; Tue, 8 May 2001 16:45:16 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-168.dialup.mtu-net.ru [62.118.131.168]) by mtu.ru (Postfix) with ESMTP id 0D12C733A for ; Wed, 9 May 2001 00:45:14 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 13534 invoked by uid 1000); 8 May 2001 20:44:27 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.23211.39938.402150@gargle.gargle.HOWL> Date: Wed, 9 May 2001 00:44:27 +0400 (MSD) To: xemacs-beta@xemacs.org Subject: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Salam, there is a very annoying issue when using non-Mule XEmacsen in Cyrillic environments under X with xkb. src/event-Xt.c contains x_keysym_to_character() which translates Cyrillic_XXX to one-byte character code (also used by Mule). Without Mule it always produces iso8859-5 characters, which is very annoying because in fact this charset is very rarely used in Russia. Various horrible hacks float around, e.g.: (global-set-key [(Cyrillic_HARDSIGN)] '(lambda () (interactive) (insert "\xFF"))) and so on for every Cyrillic_XXX. This looks horrible, does not work with isearch and is otherwise unacceptable, though widely used :) Some decide to disable Xkb. Some try to switch to Mule, but get stuck with font encoding problem we've been fixing recently :) I think I'll try to implement (set-xkb-cyrillic-charset "koi8-r") ;; also "iso8859-5" (default), ;; "windows-1251" and "cp866" that switches cyrillic[] array used by that function. I've already got some approval of this idea and encouragement by some local XEmacs users. Hope to have patch available very soon. --alexm From hniksic@arsdigita.com Tue May 8 18:08:03 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA04006 for ; Tue, 8 May 2001 18:08:02 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xFBa-00034I-00; Tue, 08 May 2001 23:38:26 +0200 Sender: hniksic@florida.arsdigita.de To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 08 May 2001 23:38:26 +0200 In-Reply-To: <15096.23211.39938.402150@gargle.gargle.HOWL> (Alexey Mahotkin's message of "Wed, 9 May 2001 00:44:27 +0400 (MSD)") Message-ID: Lines: 33 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > (global-set-key [(Cyrillic_HARDSIGN)] > '(lambda () > (interactive) > (insert "\xFF"))) Does this work: (global-set-key 'Cyrillic_HardSIGN 'self-insert-command) (put 'Cyrillic_HardSIGN 'ascii-value ?\xff) If it works, it should also work with isearch and friends. > I think I'll try to implement > > (set-xkb-cyrillic-charset "koi8-r") ;; also "iso8859-5" (default), > ;; "windows-1251" and "cp866" The name might be misleading because: * AFAIK x_keysym_to_character is not xkb-specific. * It uses the term `charset' which *looks* like it refers to Mule, although the function has in fact nothing to do with Mule. * Other charsets might require similar hacks. How about: (x-set-keysym-translation 'cyrillic 'koi8-r) (x-set-keysym-translation 'latin-2 'windows-1250) ... From hniksic@arsdigita.com Tue May 8 18:08:04 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA04017; Tue, 8 May 2001 18:08:03 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xF2c-00032W-00; Tue, 08 May 2001 23:29:10 +0200 Sender: hniksic@florida.arsdigita.de To: Alexey Mahotkin Cc: Yoshiki Hayashi , xemacs-beta@xemacs.org, xemacs-patch@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15096.19782.470107.692088@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 08 May 2001 23:29:10 +0200 In-Reply-To: <15096.19782.470107.692088@gargle.gargle.HOWL> (Alexey Mahotkin's message of "Tue, 8 May 2001 23:47:18 +0400 (MSD)") Message-ID: Lines: 10 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > Hm. Is there anywhere explained which versions of XEmacsen should > be supported by packages? Currently the earliest XEmacs you need to worry about is 21.1. It goes without saying that releases *later* than that are supported. When 21.4.x becomes stable and widely used, I expect the 21.1 support to be relaxed. From steve@turnbull.sk.tsukuba.ac.jp Tue May 8 23:39:10 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA19826 for ; Tue, 8 May 2001 23:39:07 -0400 Received: by localhost id m14xKg8-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 12:30:20 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.47560.186822.472920@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 12:30:16 +0900 To: Norbert Koch Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), xemacs-beta@xemacs.org Subject: Re: 21.5 maybe not finding package roots? [was: Byte-compiler tests fail] In-Reply-To: References: <15094.42462.327538.154687@turnbull.sk.tsukuba.ac.jp> <15094.44419.38688.611191@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "nk" == Norbert Koch writes: nk> everything runs smoothly. I only wonder, why I (or others) nk> haven't noticed this, err, feature, by now. It has been noticed, in various contexts. XEmacs is simply not as flexible in adapting to random user setups as it used to be. Partly Michael did some pruning away of some "backwards compatibility" code a couple of months ago. This may have for some reason suddenly manifested in your most recent builds. nk> Or should I have R some FM? Yeah, probably. However, I know there is some documentation, but it's not yet as complete and easy to find as we'd like. I think the "canonical setup" is by now pretty well explained in "README.packages" and in the Texinfo docs, but the theory and troubleshooting are not. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Tue May 8 23:58:30 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA20593 for ; Tue, 8 May 2001 23:58:28 -0400 Received: by localhost id m14xKz5-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 12:49:55 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.48738.879331.845820@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 12:49:54 +0900 To: Hrvoje Niksic Cc: Alexey Mahotkin , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> * Other charsets might require similar hacks. Some certainly would benefit. Alexey, please be careful to write your function so that it can be used to substitute any part of the keysym translation table. It is _not_ your responsibility to write the tables for Latin-2 or Shift JIS, but please do document the format for others. It might be nice to be able to define such translations on the fly from Lisp. Hrvoje> How about: Hrvoje> (x-set-keysym-translation 'cyrillic 'koi8-r) Hrvoje> (x-set-keysym-translation 'latin-2 'windows-1250) Much better IMO, but as I understand it, conceptually there is only one keysym translation table. So how about the interface (x-set-keysym-translation 'Cyrillic_HARDSIGN ?\xff) (x-set-keysym-translation-subset 'cyrillic 'koi8-r) (setq koi8-r (x-get-keysym-translation-subset 'cyrillic)) etc? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 00:09:33 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA21071 for ; Wed, 9 May 2001 00:09:31 -0400 Received: by localhost id m14xL9r-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 13:01:03 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.49407.763993.21009@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 13:01:03 +0900 To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Non-english discussion channels In-Reply-To: <15096.23211.39938.402150@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Alexey" == Alexey Mahotkin writes: Alexey> I've already got some approval of this idea and Alexey> encouragement by some local XEmacs users. BTW, Alexey, the xemacs-mule@xemacs.org list is chartered to be multi-lingual. If for some reason it would be convenient, you and others are welcome to hold development-related discussions in Russian on that list. They need not be restricted specifically to Mule; any topic related to using XEmacs for non-English languages is welcome. I and other developers do monitor that list. I don't read Russian, but if a Russian thread should suddenly break into English, I would certainly consider that a request for my attention. This model has worked fairly well for Japanese (until now, the main non-Latin-X constituency for XEmacs). We could also create an xemacs-users-ru list to parallel c.e.x and xemacs-beta, but specifically chartered for Russian discussion. Again, this has worked for Japanese (although traffic has gone to zero on xemacs-users-ja recently). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 00:26:11 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA21860; Wed, 9 May 2001 00:26:07 -0400 Received: by localhost id m14xLPu-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 13:17:38 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15096.50402.634349.684105@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 13:17:38 +0900 To: Alexey Mahotkin Cc: Yoshiki Hayashi , xemacs-beta@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el In-Reply-To: <15096.19782.470107.692088@gargle.gargle.HOWL> References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15096.19782.470107.692088@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Alexey" == Alexey Mahotkin writes: Alexey> 'encode and 'decode properties in 21.1 are printed out Alexey> rather incomprehensibly: Alexey> This could be somehow "fixed" (at least printing just Alexey> "there is 'encode/'decode ccl program") simply, as Alexey> `arrayp' helps to distinguish between old-style and Alexey> new-style ccl-programs. Why "fix" it? The point of these functions is "debug" information for developers. They are hardly friendly to ordinary users, so removing information is a bad idea IMO. Alexey> Hm. Is there anywhere explained which versions of Alexey> XEmacsen should be supported by packages? Packages are supported by XEmacs starting with 20.4. You "should" support them all. In practice, nobody is likely to object if you submit a patch as "tested with $STABLE and $BETA", and ignore older versions. The earliest version tested should be documented in the file if you have any suspicions. Right now STABLE=21.1, BETA=21.5, and 21.4 is close enough to 21.5 not to make a difference which you test. (This will not be true anymore in a few weeks, as Ben Wing is planning a large merge of Mule code he is currently developing.). Mule APIs change often enough that you should always be suspicious of backward incompatibilities in mule libraries. :( YH> Could you please fix it to work with XEmacs 21.1? Then that YH> will definitely go in. Alexey> That'd be great even though I understand that no one Alexey> probably will use those ;) If they worked, probably people would use them. I certainly would. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From didier@lrde.epita.fr Wed May 9 03:57:55 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA02556; Wed, 9 May 2001 03:57:51 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id JAA17775 Wed, 9 May 2001 09:55:30 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 14xOyX-0006tj-00; Wed, 09 May 2001 10:05:37 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 14xOtB-0008LC-00; Wed, 09 May 2001 10:00:05 +0200 To: Martin Buchholz Cc: Michael Sperber , XEmacs Beta Test Subject: Re: Extremely hostile init file migration experience with 21.5. References: <15095.42232.701854.939901@gargle.gargle.HOWL> X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: <15095.42232.701854.939901@gargle.gargle.HOWL> (Martin Buchholz's message of "Tue, 8 May 2001 16:49:12 +0900") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 09 May 2001 10:00:04 +0200 Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA02556 Martin Buchholz wrote: > XEmacs *looks* like it's perfectly content merely putting up the > splash screen, when in fact it's asking a question. I've been getting the same behavior for ages with my init.el that asks questions (whether I want to start gnus or not for instance). When the frame pops up, the question is usually not displayed. For me, moving the mouse (really, the X focus) away from the XEmacs frame, and back again makes the minibuffer be (re)displayed correctly. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From ben@666.com Wed May 9 05:00:16 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id FAA05357 for ; Wed, 9 May 2001 05:00:15 -0400 Received: (qmail 78387 invoked by alias); 9 May 2001 09:00:14 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 78361 invoked by uid 0); 9 May 2001 09:00:13 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 9 May 2001 09:00:13 -0000 Message-ID: <3AF9077A.67EC110B@666.com> Date: Wed, 09 May 2001 02:01:46 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshiki Hayashi CC: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yoshiki Hayashi wrote: > > Alexey Mahotkin writes: > > > I've fixed `list-coding-systems', both with C-u (it simply works now > > ;) and without it (it now lists only base coding systems, as per > > documentation). It was broken because interface of appropriate > > functions changed heavily. > > > > It was necessary to change record separator from colon to semicolon > > because some coding systems have colons in their names. > > > > Hope it will go into base XEmacs (notify me in that case, please :) > > Thanks for the patch. Your patch is good and I'd like to > approve it. But I can't since mule-diag.el is in the > package. XEmacs 21.1 does not have functions like > coding-system-aliasee. I think mule-diag.el should belong > to core so that it can avoid issues like this. But the > status quo is that mule-diag.el belongs to mule-base package > and XEmacs 21.1 must be supported by package. Could you > please fix it to work with XEmacs 21.1? Then that will > definitely go in. speaking of this ... long ago i realized that xemacs-base and mule-base definitely belong in the core, not as packages. what do others think of this? > > -- > Yoshiki Hayashi -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From martin@m17n.org Wed May 9 06:02:17 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA07609; Wed, 9 May 2001 06:02:15 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id TAA14582; Wed, 9 May 2001 19:02:04 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id TAA16831; Wed, 9 May 2001 19:02:03 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f49A23s02552; Wed, 9 May 2001 19:02:03 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.5531.21587.210056@gargle.gargle.HOWL> Date: Wed, 9 May 2001 19:02:03 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Andy Piper Cc: XEmacs Beta Test , Ben Wing Subject: Re: Interactive customize buffer button widgets broken or non-existent In-Reply-To: <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> References: <15095.40959.199977.165302@gargle.gargle.HOWL> <4.3.2.7.2.20010508085245.00b0a2a0@san-francisco.beasys.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Andy" == Andy Piper writes: Andy> At 04:27 PM 5/8/01 +0900, Martin Buchholz wrote: >> In 21.5 --with-widgets, the Set, Save, and Done buttons become 2-d and >> non-mouse-track-sensitive. Which looks really ugly, since the Reset >> stays 3-d. Andy> They are 3d if you use the appropriate widget set. What were you hoping Andy> they would be sensitive to? The reset is not 3d because an appropriate Andy> widget does not exist on all platforms (mainly athena). Actually, the Reset button (the one with the menu) is always 3-d, on every xemacs I tested. Clearly, if the Reset button can be 3-d, then the simpler button without a menu can be 3-d as well. And the code clearly exists, since this all works in 21.1.14. With xemacs-21.5 --without-widgets, the Set, Save, and Done buttons disappear completely. If there is no GUI way to display them (although we know there are, because of 21.1.14), then at least "text" buttons should be used, like in tty mode. BTW, Andy, I can arrange access to my systems, so that you see and debug for yourself. Now you have a "real" internet connection, right? From alexm@hsys.msk.ru Wed May 9 06:46:21 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA09325 for ; Wed, 9 May 2001 06:46:12 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp136-228.dialup.mtu-net.ru [62.118.136.228]) by mtu.ru (Postfix) with ESMTP id 09306733A for ; Wed, 9 May 2001 14:46:06 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 29193 invoked by uid 1000); 9 May 2001 10:44:04 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.8052.613253.195665@gargle.gargle.HOWL> Date: Wed, 9 May 2001 14:44:04 +0400 (MSD) To: Hrvoje Niksic Cc: Stephen J Turnbull Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: >>>>> "SJT" == Stephen J Turnbull writes: Hrvoje> Does this work: Hrvoje> (global-set-key 'Cyrillic_HardSIGN 'self-insert-command) Hrvoje> (put 'Cyrillic_HardSIGN 'ascii-value ?\xff) Hrvoje> If it works, it should also work with isearch and friends. No, it doesn't. 21.1 says last typed character has no ASCII equivalent: # 21.4 ignores 'ascii-value and continues to use hardcoded 8859-5 chars. >> (set-xkb-cyrillic-charset "koi8-r") ;; also "iso8859-5" (default), >> ;; "windows-1251" and "cp866" Hrvoje> The name might be misleading because: Hrvoje> * AFAIK x_keysym_to_character is not xkb-specific. I always thought that x11/keysymdef.h is defined only for xkb (IMHO, xmodmap is able only to specify numeric character codes and does not know about Cyrillic_XXX et al). Hrvoje> * It uses the term `charset' which *looks* like it refers to Hrvoje> Mule, although the function has in fact nothing to do with Hrvoje> Mule. Hrvoje> * Other charsets might require similar hacks. Hrvoje> How about: Hrvoje> (x-set-keysym-translation 'cyrillic 'koi8-r) Hrvoje> (x-set-keysym-translation 'latin-2 'windows-1250) ... I like style of this one, see below. SJT> Much better IMO, but as I understand it, conceptually there is SJT> only one keysym translation table. So how about the interface SJT> (x-set-keysym-translation 'Cyrillic_HARDSIGN ?\xff) SJT> (x-set-keysym-translation-subset 'cyrillic 'koi8-r) SJT> (setq koi8-r (x-get-keysym-translation-subset 'cyrillic)) SJT> etc? In this case first clause should be (it should modify cyrillic_koi8_r[] that is stored somewhere in some hashtable and used by x_keysym_to_character(): (x-set-keysym-translation 'koi8-r 'Cyrillic_HARDSIGN ?\xff) (x-set-keysym-translation 'iso8859-5 'Cyrillic_HARDSIGN ?\xca) (x-set-keysym-translation 'windows-1251 'Cyrillic_HARDSIGN ?\xda) (I just wanted to hardcode those tables into src/event-Xt.c, but do not object to implement modifying those tables). I think they should be predefined in stock XEmacs w/o any Lisp definitions (in style of cyrillic[] array that currently exists). Next we choose (x-set-keysym-translation-subset 'cyrillic 'koi8-r) I do not understand what you're trying to do with (setq koi8-r (x-get-keysym-translation-subset 'cyrillic)) I slightly feel like opening Pandora's box. :) --alexm From hniksic@arsdigita.com Wed May 9 07:26:31 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA10954 for ; Wed, 9 May 2001 07:26:30 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xS5o-0005n6-00; Wed, 09 May 2001 13:25:20 +0200 Sender: hniksic@florida.arsdigita.de To: Alexey Mahotkin Cc: Stephen J Turnbull , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 09 May 2001 13:25:20 +0200 In-Reply-To: <15097.8052.613253.195665@gargle.gargle.HOWL> (Alexey Mahotkin's message of "Wed, 9 May 2001 14:44:04 +0400 (MSD)") Message-ID: Lines: 23 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > >>>>> "SJT" == Stephen J Turnbull writes: > > Hrvoje> Does this work: > > Hrvoje> (global-set-key 'Cyrillic_HardSIGN 'self-insert-command) > Hrvoje> (put 'Cyrillic_HardSIGN 'ascii-value ?\xff) > > Hrvoje> If it works, it should also work with isearch and friends. > > No, it doesn't. 21.1 says > > last typed character has no ASCII equivalent: # I made two mistakes: I misnamed the property, and my `put' line contains a case mismatch. It should be: (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) 21.1 should respect that. If 21.4 doesn't, it's a bug. From martin@m17n.org Wed May 9 07:28:53 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA11082 for ; Wed, 9 May 2001 07:28:53 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id UAA15872; Wed, 9 May 2001 20:28:11 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id UAA17320; Wed, 9 May 2001 20:28:10 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f49BS9l06952; Wed, 9 May 2001 20:28:09 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.10697.599913.797551@gargle.gargle.HOWL> Date: Wed, 9 May 2001 20:28:09 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: Hrvoje Niksic , Stephen J Turnbull , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.8052.613253.195665@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "A" == Alexey Mahotkin writes: Hrvoje> * AFAIK x_keysym_to_character is not xkb-specific. A> I always thought that x11/keysymdef.h is defined only for xkb (IMHO, A> xmodmap is able only to specify numeric character codes and does not A> know about Cyrillic_XXX et al). keysymdef.h has been around for eons. I.e. before X11R6. Unfortunately, Russian has several possible encodings, mostly due to historical reasons I guess. Since XEmacs has coding systems, you would think if you simply told xemacs which encodings your system was using (or if it could guess) then everything should work. This is not quite true. Probably Koi8 is the dominant encoding in Russia, and it would be more useful for xemacs to conform to that. But most of the computers I have acccess to have iso-8859-5 fonts. Unfortunately, although it shouldn't matter what internal representation is used for characters internally, xemacs prefers to have the fonts it uses match the encoding in the internal representation. Alexey, I encourage you to try to be the Russian maintainer for XEmacs. Doing things properly might be hard, though. Perhaps Ben will Unicodeify XEmacs, and then we will need a general mechanism to map any characters to any fonts, and russian support should be simply a matter of writing the appropriate mapping tables. A> (I just wanted to hardcode those tables into src/event-Xt.c, but do A> not object to implement modifying those tables). I think they should A> be predefined in stock XEmacs w/o any Lisp definitions (in style of A> cyrillic[] array that currently exists). I wrote that code in event-Xt.c, but I did it for all character sets, without any special attention to Cyrillic. Or even any testing for Cyrillic. When designed properly, there should only be one internal representation for a given character - i.e. we should not have iso8859-5 and koi8 represented separately internally. This means that the event-Xt.c code should not know anything about koi8. A> I slightly feel like opening Pandora's box. :) Mule is hard. Good luck. From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 07:31:33 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA11239; Wed, 9 May 2001 07:31:32 -0400 Received: by localhost id m14xS3l-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 20:23:13 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.10401.480667.869203@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 20:23:13 +0900 To: Ben Wing Cc: Yoshiki Hayashi , xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el In-Reply-To: <3AF9077A.67EC110B@666.com> References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <3AF9077A.67EC110B@666.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Ben" == Ben Wing writes: Ben> speaking of this ... long ago i realized that xemacs-base Ben> and mule-base definitely belong in the core, not as packages. What's the rationale? Is it just the build and runtime problems due to missing libraries when bootstrapping, or is it something else? Ben> what do others think of this? I'm not sure. Many of those files do not implement "core" functionality (eg, canna.el and mule-diag.el), and can use standard APIs as documented in Lispref. Certainly, it's annoying to have build problems (eg, Norbert Koch's make check failures) because commonly used libraries are in packages. But I think it's better to fix that problem by having a subset of packages distributed with XEmacs sources, and keep the logical distinction between "core" libraries (which are implemented via internal APIs we reserve the right to change on a whim) and "package" libraries, which use only public APIs. I don't know how to implement this for CVS, though, or if it even needs to be. I have thought about it for the tarballs. Note that it is not a problem for the netinstaller. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From alexm@hsys.msk.ru Wed May 9 07:47:45 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA12076 for ; Wed, 9 May 2001 07:47:44 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp130-96.dialup.mtu-net.ru [62.118.130.96]) by mtu.ru (Postfix) with ESMTP id B53AA7378 for ; Wed, 9 May 2001 15:47:37 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 30519 invoked by uid 1000); 9 May 2001 11:46:39 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-ID: <15097.11807.418101.695489@tyranny.hsys.msk.ru.> Date: Wed, 9 May 2001 15:46:39 +0400 (MSD) To: Hrvoje Niksic Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> I made two mistakes: I misnamed the property, and my `put' Hrvoje> line contains a case mismatch. It should be: Hrvoje> (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) Hrvoje> (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) Hrvoje> 21.1 should respect that. It does. isearch works. Thank you! Anyway it seems like we need to implement (x-set-keysym-translation/-subset) anyway, how do you think? Or just fix 21.4 (see below) and get done with that? Someone also suggested (global-set-key [(Cyrillic_HARDSIGN)] [ÿ]) It works too. (though isearch in gnus v5.6.45 does not work with "Keyboard macro terminated by a command ringing the bell" Hrvoje> If 21.4 doesn't, it's a bug. 21.4.1 doesn't. It keeps inserting ISO8859-5 code for HARDSIGN (0xca). I could test any patches for that matter. --alexm From rendhalver@users.sourceforge.net Wed May 9 07:51:31 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA12382 for ; Wed, 9 May 2001 07:51:29 -0400 Received: from ulthwe.dyndns.org (p86-tnt1.brs.ihug.com.au [203.173.188.86]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id VAA20347 for ; Wed, 9 May 2001 21:51:12 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p86-tnt1.brs.ihug.com.au [203.173.188.86] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15097.11926.967889.665526@ulthwe.dyndns.org> Date: Wed, 9 May 2001 21:48:38 +1000 To: xemacs-beta@xemacs.org Subject: build reports for 21.4 X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII hi all just a query are build-reports for 21.4 needed ?? just wondering since its considered gamma software that means its still being heavily tested does this testing include build-reports ?? was going to send one for the newely commited changes any one think this should be done -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From alexm@hsys.msk.ru Wed May 9 08:13:41 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA13248 for ; Wed, 9 May 2001 08:13:41 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.5) with ESMTP id 7796284 for xemacs-beta@xemacs.org; Wed, 09 May 2001 09:13:33 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-230.dialup.mtu-net.ru [62.118.131.230]) by mtu.ru (Postfix) with ESMTP id E4F3A7353 for ; Wed, 9 May 2001 16:13:38 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 30897 invoked by uid 1000); 9 May 2001 12:11:38 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.13306.520307.336309@tyranny.hsys.msk.ru.> Date: Wed, 9 May 2001 16:11:38 +0400 (MSD) To: Martin Buchholz Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.10697.599913.797551@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.10697.599913.797551@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "MB" == Martin Buchholz writes: MB> keysymdef.h has been around for eons. I.e. before X11R6. By the way, while we're at it, probably you know: what is the proper function to get X keysym-code (0x6ff) from the string like "XK_Cyrillic_HARDSIGN"? If I'm going to implement (x-set-keysym-translation), I'll need that one.. MB> Probably Koi8 is the dominant encoding in Russia, and it would be MB> more useful for xemacs to conform to that. But most of the MB> computers I have acccess to have iso-8859-5 fonts. If that was Solaris, then it's ok, because they know only of ISO standards and not about actual situation :) Most Linux installations use koi8-r (and have to support 8859-5 for reasons that I'm trying to fix :) MB> Unfortunately, although it shouldn't matter what internal MB> representation is used for characters internally, xemacs prefers MB> to have the fonts it uses match the encoding in the internal MB> representation. MB> When designed properly, there should only be one internal MB> representation for a given character - i.e. we should not have MB> iso8859-5 and koi8 represented separately internally. This means MB> that the event-Xt.c code should not know anything about koi8. MB> Mule is hard. Good luck. I am not speaking of Mule here :) Mule works mostly ok (see parallel thread). I need to somehow cover simplest cases of non-Mule one-byte encodings and with straightforward internal representations. MB> Alexey, I encourage you to try to be the Russian maintainer for MB> XEmacs. I do not know about full-size maintenance, but I'll surely try to fix once and for all every subsystem I use (gnus, vm, ispell, psgml) if need be (sometimes it is). :) --alexm From alexm@hsys.msk.ru Wed May 9 08:13:42 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA13242 for ; Wed, 9 May 2001 08:13:37 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-230.dialup.mtu-net.ru [62.118.131.230]) by mtu.ru (Postfix) with ESMTP id 407EA7341 for ; Wed, 9 May 2001 16:13:36 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 30884 invoked by uid 1000); 9 May 2001 12:02:41 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.12769.931887.711914@tyranny.hsys.msk.ru.> Date: Wed, 9 May 2001 16:02:41 +0400 (MSD) To: Hrvoje Niksic Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> I made two mistakes: I misnamed the property, and my `put' Hrvoje> line contains a case mismatch. It should be: Hrvoje> (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) Hrvoje> (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) By the way, there is no chapter "Character properties" in lispref.info (there is "String properties" chapter). Is there any other properties for characters (I could try to write up some summary documentation for that...)? --alexm From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 08:33:38 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA14102; Wed, 9 May 2001 08:33:34 -0400 Received: by localhost id m14xT1W-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 21:24:58 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 21:24:58 +0900 To: Alexey Mahotkin Cc: Ben Wing , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.8052.613253.195665@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid BTW, Hrvoje doesn't care to be separately addressed if the mail is going to the ML anyway, but Ben likes to be CC'd; he sorts on that basis. Addressees adjusted. >>>>> "Alexey" == Alexey Mahotkin writes: Hrvoje> If it works, it should also work with isearch and friends. Alexey> No, it doesn't. Bletch. Thanks for testing it. Alexey> In this case first clause should be (it should modify Alexey> cyrillic_koi8_r[] that is stored somewhere in some Alexey> hashtable and used by x_keysym_to_character(): That's what I wanted to avoid. OK, I see that it's probably unavoidable in no-mule. And it's probably right to do it inside that switch (this automatically makes it configurable according to character set, so that the iso-to-koi translation does NOT get applied in the Latin-2 buffer, which would really hinder a Polish/Russian translator). As Martin points out, in Mule the internal representation should be unique. (It can't be in no-Mule, because we have no other way to translate to the font encoding.) As far as I know, however, it's not Mule XEmacs that wants the to fonts match internal representation. It's that XEmacs developers have never done anything about using the facilities provided by Mule to handle fonts that have different encoding from internal. I _will_ take a look at this. I've been meaning to for a _long_ time, but got side-tracked by the release thing. Alexey> I think they should be predefined in stock XEmacs w/o any Alexey> Lisp definitions (in style of cyrillic[] array that Alexey> currently exists). OK, I agree about the need for predefinition, especially in no-Mule. However, in practice, we don't know which fonts are important. So there should be a Lisp-level way to create and install such arrays. If you hack only for Cyrillic, you will create a Russianized XEmacs. And will you put in (eg) the extra characters the Ukrainians want? I disagree strongly about implementing such arrays for Mule, however. Use of a single internal representation has good reasons, although our laziness in fixing up input and output translations has been bad for Russian (and presumably Greek) users since day 1, and is increasingly bad for users of Windows 125x sets I would guess. As for predefinition in C vs Lisp: We try to think in terms of implementing _everything_ in the text editor in Lisp, for robustness and flexibility. We move down to the C level when we want the efficiency. We don't _need_ it here; users will never see the delay in installing such a table from Lisp rather than C, since it only happens once per session. We do _need_ the Lisp level definition, since it's probable that Greeks, at least, will need this too. And we don't know who else! We get robust predefinition from Lisp by "dumping" the Lisp into the executable, where we always know where to find it. Alexey> I do not understand what you're trying to do with (setq koi8-r (x-get-keysym-translation-subset 'cyrillic)) Oh, you can forget that, it was a dumb idea. I have lots of those. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From hniksic@arsdigita.com Wed May 9 08:34:53 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA14180 for ; Wed, 9 May 2001 08:34:52 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xT9b-00061P-00; Wed, 09 May 2001 14:33:19 +0200 Sender: hniksic@florida.arsdigita.de To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.12769.931887.711914@tyranny.hsys.msk.ru.> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 09 May 2001 14:33:19 +0200 In-Reply-To: <15097.12769.931887.711914@tyranny.hsys.msk.ru.> (Alexey Mahotkin's message of "Wed, 9 May 2001 16:02:41 +0400 (MSD)") Message-ID: Lines: 14 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> I made two mistakes: I misnamed the property, and my `put' > Hrvoje> line contains a case mismatch. It should be: > > Hrvoje> (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) > Hrvoje> (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) > > By the way, there is no chapter "Character properties" in lispref.info > (there is "String properties" chapter). `ascii-character' is the property of a symbol, not of a character. From martin@m17n.org Wed May 9 08:39:06 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA14431 for ; Wed, 9 May 2001 08:39:05 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id VAA16521; Wed, 9 May 2001 21:38:42 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id VAA17819; Wed, 9 May 2001 21:38:40 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f49Ccem07325; Wed, 9 May 2001 21:38:40 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.14928.235135.144321@gargle.gargle.HOWL> Date: Wed, 9 May 2001 21:38:40 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: Hrvoje Niksic , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.12769.931887.711914@tyranny.hsys.msk.ru.> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.12769.931887.711914@tyranny.hsys.msk.ru.> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "A" == Alexey Mahotkin writes: >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> I made two mistakes: I misnamed the property, and my `put' Hrvoje> line contains a case mismatch. It should be: Hrvoje> (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) Hrvoje> (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) A> By the way, there is no chapter "Character properties" in lispref.info A> (there is "String properties" chapter). Technically, character lisp objects themselves have no properties. In the above, it's a SYMBOL that has a property. From martin@m17n.org Wed May 9 08:49:02 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA14833 for ; Wed, 9 May 2001 08:49:01 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id VAA16590; Wed, 9 May 2001 21:48:35 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id VAA17862; Wed, 9 May 2001 21:48:34 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f49CmYn07396; Wed, 9 May 2001 21:48:34 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.15522.24687.245432@gargle.gargle.HOWL> Date: Wed, 9 May 2001 21:48:34 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.13306.520307.336309@tyranny.hsys.msk.ru.> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.10697.599913.797551@gargle.gargle.HOWL> <15097.13306.520307.336309@tyranny.hsys.msk.ru.> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "A" == Alexey Mahotkin writes: >>>>> "MB" == Martin Buchholz writes: MB> keysymdef.h has been around for eons. I.e. before X11R6. A> By the way, while we're at it, probably you know: what is the proper A> function to get X keysym-code (0x6ff) from the string like A> "XK_Cyrillic_HARDSIGN"? If I'm going to implement A> (x-set-keysym-translation), I'll need that one.. I'm not sure what you want here. Check out XKeysymToString. Check out x-keysym-hash-table and x-keysym-on-keyboard-p and its implementation. (I wrote that many years ago) MB> Probably Koi8 is the dominant encoding in Russia, and it would be MB> more useful for xemacs to conform to that. But most of the MB> computers I have acccess to have iso-8859-5 fonts. A> If that was Solaris, then it's ok, because they know only of ISO I used to work at Sun, and can confirm Sun's zealous devotion to standards. For some things, like the C language, this was a good decision. But for other things, like `make' and iso8859-5, a reality check would be useful. In Sun's defence, iso8859-5 was the Soviet government's idea. I don't know if the Russian government has abandoned iso8859-5 officially, or recommended a new ISO standard for Cyrillic. I'm sure it's all very political. From alexm@hsys.msk.ru Wed May 9 08:49:12 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA14843 for ; Wed, 9 May 2001 08:49:12 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp138-138.dialup.mtu-net.ru [62.118.138.138]) by mtu.ru (Postfix) with ESMTP id 0B75B732E for ; Wed, 9 May 2001 16:49:08 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 31198 invoked by uid 1000); 9 May 2001 12:48:12 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.15500.542224.262451@tyranny.hsys.msk.ru.> Date: Wed, 9 May 2001 16:48:12 +0400 (MSD) To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "SJT" == Stephen J Turnbull writes: SJT> That's what I wanted to avoid. OK, I see that it's probably SJT> unavoidable in no-mule. And it's probably right to do it inside SJT> that switch (this automatically makes it configurable according SJT> to character set, so that the iso-to-koi translation does NOT get SJT> applied in the Latin-2 buffer, which would really hinder a SJT> Polish/Russian translator). Oh oh oh. In large letters: I intend all those (x-set-keysym-translation/-subset) work _only_ in non-Mule XEmacsen. Those functions will not even exist when Mule is enabled. I am completely satisfied with how Mule does what it does. Maybe it'll clear someone's understanding of the situation. Rushing off home, so will answer (and read) to other several hours later. --alexm From martin@m17n.org Wed May 9 08:49:28 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA14849 for ; Wed, 9 May 2001 08:49:16 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id VAA16605 for ; Wed, 9 May 2001 21:49:05 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id VAA17867 for ; Wed, 9 May 2001 21:49:04 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f49Cn4a07399; Wed, 9 May 2001 21:49:04 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.15551.611817.473987@gargle.gargle.HOWL> Date: Wed, 9 May 2001 21:49:03 +0900 From: XEmacs Release Engineer To: XEmacs Beta Test Subject: XEmacs 21.5.1 "anise" is released. Reply-To: martin@xemacs.org Brief summary of changes to 21.5.1 "anise" -- This release contains a huge pile of changes by Ben Wing, including both bug fixes and features. Highlights: -- Many changes to make printing work on Windows -- byte-compilation speed improvements -- New functions for cleanly eliminating byte-compiler warnings -- Remove core bytecompiler warnings -- Improve interactive help interface -- etags improvements -- Better "About XEmacs" page -- Windows configury changes -- Get QUIT working on Windows -- Fix shy group regexp code -- etc. etc. -- The `short-name' argument to make-charset now works correctly -- Yoshiaki Kasahara -- `custom' changes -- Didier Verna -- SET_FACE_PROPERTY bug fix -- Jerry James -- Unix tty configury changes -- Martin Buchholz -- Fix compile error with g++ on bsdi -- Martin Buchholz -- Fix crash with xlc -O3 -- Martin Buchholz -- Fix link error with (pre-release) gcc 3.0 -- Martin Buchholz -- Fix build error if system has makeinfo 3.12 -- Martin Buchholz -- Speed up `intern' and hash tables containing strings -- Martin Buchholz -- Make hash table mapping safe -- Martin Buchholz -------- ChangeLog entries from xemacs-21.5.1/ChangeLog ------- 2001-01-31 Jason R. Mastaler * etc/FTP: Updated FTP mirrors list. 2001-05-04 Martin Buchholz * configure.in (opsys): Use lower-case `uname -s` as the default value for opsys. The previous code effectively did the non-sensical opsys=$canonical because [] magically disappear in configure.in. -------- ChangeLog entries from xemacs-21.5.1/lib-src/ChangeLog ------- 2001-04-29 Ben Wing * gnuclient.c (filename_expand): Warning fix. 2001-04-20 Ben Wing * .cvsignore: Added stuff for Windows. -------- ChangeLog entries from xemacs-21.5.1/lisp/ChangeLog ------- 2001-05-06 Ben Wing * dialog.el (make-dialog-box): * menubar-items.el (default-menubar): * printer.el (generic-print-buffer): * printer.el (generic-print-region): implement printing the selection when it's selected. unrelated: * minibuf.el (input-error): * subr.el (error): a couple of error cleanups. * update-elc.el ((preloaded-file-list site-load-packages need-to-dump dumped-exe)): * update-elc.el (update-elc-files-to-compile): if bytecomp or byte-optimize need recompiling, then load the .el version of them first, recompile them, and reload the .elc versions to recompile everything else (so we won't be waiting until the cows come home). 2001-05-05 Ben Wing * subr.el (error): Add missing errors to the doc string. 2001-05-05 Ben Wing * dialog.el (make-dialog-box): fix doc string. * menubar-items.el (default-menubar): Add Page Setup for Windows, take out Pretty Print. * printer.el: * printer.el (printer-current-device): New. * printer.el (Printer-get-device): New. * printer.el (Printer-clear-device): New. * printer.el (generic-page-setup): New. * printer.el (generic-print-buffer): * printer.el (generic-print-region): Implement Page Setup. Handle errors properly. unrelated: * gtk-init.el: Fix the warning properly. 2001-05-04 Ben Wing * printer.el (generic-print-buffer): * printer.el (generic-print-region): Enable dialog boxes. Apply workaround recommended by Kirill. * simple.el (kill-whole-line): * simple.el (kill-line-1): * simple.el (kill-entire-line): * simple.el (kill-line): * simple.el (backward-kill-line): Take out interactive dependence of kill-whole-line. 2001-04-22 Ben Wing ----------------------- byte-comp warning fixes ----------------- * bytecomp-runtime.el: * bytecomp-runtime.el (with-boundp): New. * bytecomp-runtime.el (if-boundp): New. * bytecomp-runtime.el (declare-boundp): New. * bytecomp-runtime.el (globally-declare-boundp): New. * bytecomp-runtime.el (byte-compile-with-fboundp): New. * bytecomp-runtime.el ('with-fboundp-1): New. * bytecomp-runtime.el (with-fboundp): New. * bytecomp-runtime.el (if-fboundp): New. * bytecomp-runtime.el (declare-fboundp): New. * bytecomp-runtime.el (globally-declare-fboundp): New. * bytecomp-runtime.el (byte-compile-with-byte-compiler-warnings-suppressed): New. * bytecomp-runtime.el ('with-byte-compiler-warnings-suppressed-1): New. * bytecomp-runtime.el (with-byte-compiler-warnings-suppressed): New. * bytecomp-runtime.el (with-obsolete-variable): New. * bytecomp-runtime.el (with-obsolete-function): New. New functions for cleanly eliminating byte-compiler warnings. Their definitions require no changes at all in bytecomp.el, meaning that any package that wants to use them and be compatible with older versions of XEmacs need only copy the code and rename the functions (i.e. prefix them with the package name). * apropos.el (apropos-symbol-face): * apropos.el (apropos-keybinding-face): * apropos.el (apropos-label-face): * apropos.el (apropos-property-face): * cl-extra.el (cl-map-overlays): * coding.el: * coding.el (set-keyboard-coding-system): * coding.el (set-terminal-coding-system): * console.el (resume-pid-console): * dialog-gtk.el: * dialog-gtk.el (popup-builtin-open-dialog): * dialog-gtk.el (popup-builtin-color-dialog): * dragdrop.el (experimental-dragdrop-drop-mime-default): * dragdrop.el (gtk-start-drag): * dragdrop.el (gtk-start-drag-region): * faces.el (init-face-from-resources): * faces.el (init-device-faces): * faces.el (init-frame-faces): * faces.el (init-global-faces): * faces.el (set-face-stipple): * files.el (set-visited-file-name): * files.el (basic-save-buffer): * files.el (save-some-buffers-1): * files.el (file-remote-p): * fill.el (fill-move-forward-to-break-point): * fill.el (find-space-insertable-point): * font-lock.el: * frame.el (suspend-or-iconify-emacs): * frame.el (suspend-emacs-or-iconify-frame): * gdk.el: * generic-widgets.el: * generic-widgets.el (build-ui::radio-group): * generic-widgets.el (build-ui::button): * glade.el: * gnome-widgets.el: * gnome.el: * gtk-extra.el: * gtk-faces.el (gtk-choose-font): * gtk-file-dialog.el: * gtk-file-dialog.el (gtk-file-dialog-fill-file-list): * gtk-file-dialog.el (gtk-file-dialog-fill-directory-list): * gtk-file-dialog.el (gtk-file-dialog-new): * gtk-font-menu.el: * gtk-font-menu.el (gtk-reset-device-font-menus): * gtk-init.el: * gtk-init.el (gtk-initialize-compose): * gtk-package.el: * gtk-password-dialog.el: * gtk-widget-accessors.el: * gtk-widgets.el: * gtk.el: * isearch-mode.el (isearch-help-or-delete-char): * ldap.el: * lib-complete.el (read-library-internal): * lib-complete.el (read-library): * lib-complete.el (read-library-name): * lisp-mnt.el (lm-report-bug): * minibuf.el (minibuffer-smart-mouse-tracker): * minibuf.el (minibuffer-smart-select-kludge-filename): * minibuf.el (read-file-name-internal-1): * minibuf.el (read-color-completion-table): * modeline.el (modeline-toggle-read-only): * mouse.el (mouse-consolidated-yank): * mouse.el (default-mouse-track-maybe-own-selection): * msw-font-menu.el (mswindows-reset-device-font-menus): * multicast.el (open-multicast-group): * mwheel.el: * package-get.el (package-get-update-base-from-buffer): * scrollbar.el (init-scrollbar-from-resources): * symbols.el: * syntax.el (describe-syntax-table): * toolbar.el (init-toolbar-from-resources): * toolbar-items.el (toolbar): * toolbar-items.el (toolbar-paste): * tty-init.el (init-pre-tty-win): * tty-init.el (init-post-tty-win): * wid-browse.el (widget-browse-sexp): * widgets-gtk.el: * x-faces.el: * x-font-menu.el: * x-font-menu.el (x-font-menu-font-data): * x-init.el: * x-misc.el: * x-mouse.el: * x-scrollbar.el: * x-select.el: * x-win-sun.el: * x-win-xfree86.el: Eliminate byte-compiler warnings using the new functions in bytecomp-runtime.el. * coding.el (coding-system-get): New. * coding.el (coding-system-put): New. * coding.el (coding-system-category): New. * mule\mule-misc.el (coding-system-get): Removed. * mule\mule-misc.el (coding-system-put): Removed. * mule\mule-misc.el (coding-system-category): Removed. Move these functions, since they're not Mule-specific and are used in prefer-coding-system. * font.el: * font.el (cl): * font.el (set-font-family): * font.el (set-font-weight): * font.el (set-font-style): * font.el (set-font-size): * font.el (set-font-registry): * font.el (set-font-encoding): * font.el (font-family): * font.el (font-weight): * font.el (font-style): * font.el (font-size): * font.el (font-registry): * font.el (font-encoding): * font.el (set-font-style-by-keywords): * font.el (font-properties-from-style): * font.el (font-combine-fonts-internal): * font.el (font-x-font-regexp): * font.el (x-font-create-object): * font.el (x-font-create-name): * font.el (ns-font-create-name): * font.el (mswindows-font-create-name): * font.el (font-update-device-fonts): * font.el (font-update-one-face): * font.el (font-rgb-color-p): * font.el (font-rgb-color-red): * font.el (font-tty-compute-color-delta): * font.el (font-normalize-color): This file was incredibly ugly. Clean it up. Avoid using defsubst for any exported functions, to avoid possible compatibility problems if we later change the internal interface. (It happened before, with face accessors, between 19.8 and 19.9). Fix tons of warnings. * gpm.el: * gpm.el (gpm-is-supported-p): New. * gpm.el (gpm-delete-device-hook): Clean up (new function gpm-is-supported-p eliminates duplicate code in gpm-create/delete-device-hook) and eliminate warnings. ---------- make byte-recompile-directory work in the --------- core `lisp' dir, even in the absence of a Mule XEmacs (i.e. make it skip the Mule files rather than trying to compile them). now you should be able to do `touch *.el' in the `lisp' dir, then M-x byte-recompile-directory, and get no warnings. * bytecomp.el: * bytecomp.el (byte-recompile-ignore-uncompilable-mule-files): New. * bytecomp.el (byte-compile-inbuffer): * bytecomp.el (byte-compile-inbuffer)): New. * bytecomp.el (byte-compile-outbuffer)): New. * bytecomp.el (byte-compile-warn): * bytecomp.el (byte-recompile-directory): * bytecomp.el (byte-recompile-file): Avoid trying to compile Mule files in byte-recompile-directory when we're not in a Mule XEmacs, since we're highly likely to get syntax errors. * mule\arabic.el: * mule\canna-leim.el: * mule\english.el: * mule\greek.el: * mule\kinsoku.el: * mule\latin.el: * mule\misc-lang.el: * mule\mule-category.el: * mule\mule-ccl.el: * mule\mule-charset.el: * mule\mule-cmds.el: * mule\mule-coding.el: * mule\mule-help.el: * mule\mule-init.el: * mule\mule-misc.el: * mule\mule-tty-init.el: * mule\mule-x-init.el: * mule\thai-xtis-chars.el: * mule\viet-chars.el: Add a coding-system cookie to all Mule files so that byte-recompile-directory ignores them. * code-files.el (load): * code-files.el (find-coding-system-magic-cookie): Removed. * files.el: * files.el (find-coding-system-magic-cookie-in-file): New. Magic cookie function moved to files.el from code-files.el (for use by bytecomp even in a non-coding-system XEmacs), and changed names and semantics for use by bytecomp. NOTE: IMO this is an internal function that we can change as we like (and there is absolutely no code anywhere else using the function). ---------------- GUI improvements: menus, help ------------------- * help.el: * help.el (help-map): Removed. * help.el (help-for-help): * help.el (Help-princ-face): * help.el (Help-prin1-face): * help.el (describe-function-1): * help.el (describe-variable): Rearrange order of keymap declarations to be alphabetical. Improve help on help to include all bindings, and group by category. Add bindings for new Info commands. Remove warnings. Use command-hyper-apropos in place of command-apropos. * hyper-apropos.el: * hyper-apropos.el (hyper-apropos-programming-apropos): * hyper-apropos.el (command-hyper-apropos): New. Add a function to do the equivalent of command-apropos. * help-macro.el (make-help-screen): Evals its help-text argument so you can put expressions there. Used now by help-for-help. * info.el: * info.el (Info-search): * info.el (Info-search-next): New. * info.el (Info-index): Removed. * info.el (Info-find-index-alternatives): New. * info.el (Info-read-search-text-regexp): New. * info.el (Info-search-text-in-lispref): New. * info.el (Info-search-text-in-xemacs): New. * info.el (Info-search-index-in-lispref): New. * info.el (Info-search-index-in-xemacs-and-lispref): New. * info.el (Info-mode-map): Add binding to continue text searches. Expand index searches to work over multiple info documents. Add commands to search text/index in User and Lispref. * lisp-mode.el (construct-lisp-mode-menu): Add new entry, "Uncomment Region" (parallels "Comment Out Region"). * menubar-items.el (default-menubar): * menubar-items.el (default-popup-menu): Redo Help menu; add bindings for new Info commands to search the index or text of the User and Lispref manuals. Add command for mark-paragraph, activate-region. Make Edit->R accelerator be rectangle, not register (more commonly used), and put rectangle first. Fix the Edit Init File entry to never load the .elc file. Simplify the default-popup-menu. Add Cmds->Tabs menu. * menubar.el (popup-buffer-menu): Doc fix. * menubar.el ((boundp 'menu-accelerator-map)): Use kp-left not kp_left, etc. ---------------- Miscellaneous bug fixes/cleanup ------------------- * bytecomp-runtime.el (byte-compiler-options): Correct doc string. * easymenu.el (easy-menu-do-define): fix extra quote. * fill.el (fill-paragraph-or-region): Rewrite to be more correct -- use call-interactively so that we always get exactly the same behavior as if the functions were called directly. * font-lock.el (font-lock-fontify-pending-extents): * gutter-items.el (clear-progress-feedback): * gutter-items.el (abort-progress-feedback): * gutter-items.el (raw-append-progress-feedback): * simple.el (clear-message): * simple.el (raw-append-message): No need to fiddle with zmacs-region-stays, now that bogus clearing of it (2001-04-28 src/ChangeLog) is removed. * dialog.el (make-dialog-box): Put dialog titles back in -- this time correctly. Fix various other problems with leaks and such. * keymap.el (key-sequence-list-description): Clean up fun to always correctly canonicalize. * simple.el: * simple.el (delete-forward-p): * simple.el (comment-padding): New. * simple.el (comment-region): * simple.el (do-auto-fill): * simple.el (indent-new-comment-line): Clean up Kinsoku comments, synch comment-region with FSF 20.7. * simple.el (region-exists-p): * simple.el (region-active-p): Add comment about which one is correct to use in menu specs. * sound.el (load-sound-file): Minor code clean up. * startup.el: * startup.el (command-line-early): * startup.el (initial-scratch-message): Comment changes. Add info about sample.init.el to splash screen. Improve initial-scratch-message and clarify purpose of Scratch buffer. Fix byte-compile warning. ------------------------ Added features ------------------------- * etags.el: * etags.el (tags-check-parent-directories-for-tag-files): New. * etags.el (buffer-tag-table-list): Add new variable to control whether etags checks all parent directories for tag files. (On by default.) * hash-table.el: New file, useful utility functions. * dumped-lisp.el (preloaded-file-list): Dump hash-table.el. 2001-05-03 Adrian Aichner * build-report.el: Remove CVS keywords since this file has been in core lisp for a while now. * build-report.el (build-report-make-output-files): Fix typo. 2001-04-30 Ben Wing * printer.el: * printer.el (printer-page-header): * printer.el (Print-context): New. * printer.el (printer-page-footer): * printer.el (generate-header-element): New. * printer.el (generate-header-line): New. * printer.el (print-context-property): * printer.el (generic-print-buffer): * printer.el (generic-print-region): Implement headers and footers. Implement calling Print dialog box (#### but it doesn't quite work yet). 2001-04-28 Ben Wing * about.el (xemacs-hackers): * about.el (about-url-alist): * about.el (about-personal-info): * about.el (about-hacker-contribution): More contributions. * simple.el (handle-post-motion-command): Fix spurious setting of zmacs-region-stays to t after a non-shift motion command. * etags.el (find-tag-internal): Sync up with FSF 20.7, to fix bugs handling some etags line formats. * gtk-init.el (init-post-gtk-win): * msw-init.el (init-post-mswindows-win): * x-init.el: * x-init.el (x-activate-region-as-selection): Removed. * x-init.el (init-post-x-win): * keydefs.el (global-map): * simple.el: * startup.el (command-line): * toolbar-items.el: * toolbar-items.el (init-x-toolbar-list): Removed. * toolbar-items.el (init-toolbar-list): New. * toolbar-items.el (init-x-toolbar): Removed. * toolbar-items.el (init-toolbar): New. * toolbar-items.el (x-init-toolbar-from-resources): Removed. * toolbar.el: Move non-window-system specific code that was duplicated in all window systems into the generic code. * gutter.el: * gutter.el (init-gutter): Removed. (unused) * mouse.el: * mouse.el (default-mouse-track-maybe-own-selection): * mouse.el (mouse-track-activate-rectangular-selection): New. * select.el: * select.el (disown-selection): * select.el (activate-region-as-selection): * select.el (primary-selection-extent): * select.el (valid-simple-selection-p): Clean up the rectangle code w.r.t. selections. You'll now get the right text copied into the primary selection (but not the clipboard yet, unfortunately -- that really requires defining our own rectangle type). 2001-04-25 IKEYAMA Tomonori * faces.el (make-face-bold): * faces.el (make-face-italic): * faces.el (make-face-bold-italic): * faces.el (make-face-unbold): * faces.el (make-face-unitalic): * faces.el (make-face-smaller): * faces.el (make-face-larger): Call frob-face-property each for mswindows and msprinter. 2001-04-24 Hrvoje Niksic * about.el (about-finish-buffer): Make sure the last change works even if EVENT is nil. 2001-04-24 Hrvoje Niksic * about.el (about-mailto-link): Use compose-mail for sending mail. (about-finish-buffer): Kill/bury the buffer where the user clicked, not the one that happens to be the current buffer at the time. 2001-04-24 Hrvoje Niksic * about.el (about-personal-info): Update my bio. (about-hacker-contribution): Ditto. 2001-04-23 Didier Verna * cus-edit.el (custom-variable-pre-save): New. * cus-edit.el (custom-variable-post-save): New. * cus-edit.el (custom-variable-save): use them. * cus-edit.el (custom-face-pre-save): New. * cus-edit.el (custom-face-post-save): New. * cus-edit.el (custom-face-save): use them. * cus-edit.el (custom-group-pre-save): New. * cus-edit.el (custom-group-post-save): New. * cus-edit.el (custom-group-save): use them. * cus-edit.el (Custom-save): use the pre/post functions above, call `custom-save-all' only once. * cus-edit.el (custom-variable-pre-reset-standard): New. * cus-edit.el (custom-variable-post-reset-standard): New. * cus-edit.el (custom-variable-reset-standard): use them. * cus-edit.el (custom-face-pre-reset-standard): New. * cus-edit.el (custom-face-post-reset-standard): New. * cus-edit.el (custom-face-reset-standard): use them. * cus-edit.el (custom-group-pre-reset-standard): New. * cus-edit.el (custom-group-post-reset-standard): New. * cus-edit.el (Custom-reset-standard): use them. * cus-edit.el (custom-face-reset-saved): use the pre/post functions above, call `custom-save-all' only once. 2001-04-15 Ben Wing * about.el: * about.el (about-headline-face): New. * about.el (about-link-face): New. * about.el (about-current-release-maintainers): New. * about.el (about-other-current-hackers): New. * about.el (about-once-and-future-hackers): New. * about.el (about-lookup-url): New. * about.el (about-get-buffer): * about.el (about-mailto-link): New. * about.el (about-finish-buffer): * about.el (about-xemacs): * about.el (about-features): Removed. * about.el (about-advantages): New. * about.el (about-maintainer-info): Removed. * about.el (about-personal-info): New. * about.el (about-hacker-contribution): New. * about.el (about-maintainer): * about.el (about-show-linked-info): * about.el (about-hackers): Major revamping. Rewriting of most of the text, improve the link handling, separate info on contributors into personal and contribution info, add new contributors, update personal info, etc. etc. * menubar-items.el (default-menubar): Help menubar entry for News now says more accurately "What's New in XEmacs". * mouse.el: * mouse.el (mouse-track-cleanup-hook): * mouse.el (mouse-track): Don't set-buffer to a dead buffer when calling mouse-track cleanup hooks. 2001-04-18 Didier Verna * cus-edit.el (Custom-reset-standard): reset to standard settings not only when the buffer's :custom-state is 'modified, but also when it is 'set or 'saved. -------- ChangeLog entries from xemacs-21.5.1/lwlib/ChangeLog ------- 2001-04-28 Ben Wing * lwlib-utils.c (destroy_all_children): fix warning reported by Isaac Hollander . -------- ChangeLog entries from xemacs-21.5.1/man/ChangeLog ------- 2001-05-07 Martin Buchholz * make-stds.texi: Support makeinfo 3.12 2001-04-26 John H. Palmieri * xemacs/frame.texi (XEmacs under X): Document default-frame-plist rather than default-frame-alist. 2001-04-15 Ben Wing * xemacs-faq.texi (Q1.0.1): * xemacs-faq.texi (Q1.0.2): Rewrite description of XEmacs to match what's on web page, in about.el. -------- ChangeLog entries from xemacs-21.5.1/nt/ChangeLog ------- 2001-05-01 Adrian Aichner * xemacs.mak: Define EMACS_PATCH_LEVEL like configure.in does. * xemacs.mak (XEMACS_VERSION_STRING): Build this more like configure.in does. * xemacs.mak (docfile): Use del instead of $(DEL) in shell command. 2001-05-01 Ben Wing * config.inc.samp (MAKEINFO): point at more standard c: not f:. * minitar.c: * minitar.c (Usage): * minitar.c (octal): * minitar.c (makepath): * minitar.c (main): Fix more compiler warnings, clean up the style to conform more to standard XEmacs. 2001-05-01 Ben Wing * xemacs.mak (DEPEND): Don't add config.inc to the horked depend file. It's not recognized by nmake and just results in warnings. * xemacs.mak (docfile): Don't use $(DEL) in the middle of a shell command, because it will try to call `-del' and fail. 2001-04-27 Adrian Aichner * compface.mak (clean): New target. * xemacs.mak: Use $(DEL) everywhere, instead of some occurences of del and @$(DEL). Add GTK supporting variables and document it as currently unsupported on MSWindows. * xemacs.mak (XEMACS_VERSION_STRING): Initialize according to emacs_is_beta. Use emacs_beta_version as patch level for non-beta version. * xemacs.mak (HAVE_GTK): New. * xemacs.mak (GTK_DIR): New. 2001-04-20 Ben Wing * .cvsignore: Added stuff for Windows. -------- ChangeLog entries from xemacs-21.5.1/nt/installer/Wise/ChangeLog ------- 2001-04-27 Ben Wing * renamed file `display readme.dlg' to display-readme.dlg. -------- ChangeLog entries from xemacs-21.5.1/src/ChangeLog ------- 2001-05-08 Yoshiki Hayashi * buffer.c (Vcase_fold_search): Remove obsolete comment about non ASCII case-fold-search. This bug has been fixed by case-table changes. 2001-05-08 Yoshiaki Kasahara * mule-charset.c (Fmake_charset): Add missing else. 2001-05-07 Martin Buchholz * s/bsd386.h: Use NOT_C_CODE instead of `emacs' to protect Makefiles 2001-05-08 Martin Buchholz * s/bsdos4.h: Protect C code with #ifndef NOT_C_CODE. 2000-04-22 zhaoway * event-stream.c (is_scrollbar_event): Return 0 when XEmacs is compiled without scrollbars. 2001-05-05 Martin Buchholz TTY configury portability improvements. Support systems which use OXTABS instead of TAB3, without any s&m. * s/bsd386.h: Remove definitions for system symbols TABDLY and OXTABS. * s/freebsd.h: Likewise. * s/gnu.h: Likewise. * s/netbsd.h: Likewise. * s/nextstep.h: Remove definitions for TAB3 and BSD_TERMIOS. * systty.h: Fix up (unused) tty tab delay/expansion code. Better preprocessor symbol hygiene. Remove BSD_TERMIOS cruft. * sysdep.c (child_setup_tty): More careful code. Check for OXTABS. * sysdep.c (tty_init_sys_modes_on_device): Tab expansion disabling code was buggy. So I fixed it. But it shouldn't have been done at all. So I also #if 0'ed it. 2001-05-06 Ben Wing * console-msw.h: * device-msw.c: * device-msw.c (print_dialog_worker): * device-msw.c (mswindows_handle_print_dialog_box): * device-msw.c (syms_of_device_mswindows): * dialog-msw.c (mswindows_make_dialog_box_internal): * general-slots.h: implement printing the selection when it's selected. unrelated: * mule-charset.c (Fset_charset_ccl_program): * mule-charset.c (invalidate_charset_font_caches): force redisplay when set-charset-ccl-program called. 2001-05-04 Martin Buchholz * s/bsdos4.h (openpty): Add declaration, missing from system headers. 2001-05-05 Martin Buchholz * search.c (warn_about_possibly_incompatible_back_references): Target of a DEFVAR_INT should be a Fixnum, not int. 2001-05-05 Ben Wing * console-msw.h: * device-msw.c: * device-msw.c (mswindows_get_default_margin): * frame-msw.c (mswindows_size_frame_internal): * frame-msw.c (msprinter_init_frame_1): * frame-msw.c (vars_of_frame_mswindows): Change top/bottom margin defaults to 0.5 inches. 2001-04-23 Ben Wing ------------ notable bug fix: Windows event code -------------- * event-msw.c (FAKE_MOD_QUIT): * event-msw.c (mswindows_dequeue_dispatch_event): * event-msw.c (mswindows_wnd_proc): * event-msw.c (emacs_mswindows_quit_p): Get critical quit working. ------------ notable bug fix and new feature: regex code -------------- * lisp.h: * regex.c: * regex.c (enum): * regex.c (print_compiled_pattern): * regex.c (INIT_REG_TRANSLATE_SIZE): * regex.c (regex_compile): * regex.c (re_match_2_internal): * regex.h: * regex.h (RE_SYNTAX_AWK): * regex.h (RE_SYNTAX_GREP): * regex.h (RE_SYNTAX_EGREP): * regex.h (RE_SYNTAX_POSIX_EGREP): * regex.h (_RE_SYNTAX_POSIX_COMMON): * regex.h (struct re_pattern_buffer): * search.c: * search.c (vars_of_search): Shy groups were implemented in a horrible, half-assed way that would cause them to screw up regex searching in most cases. Fixed to work correctly. Also extended back-reference syntax past 9. Only is recognized as such if there are at least that many non-shy groups; and optionally will warn about such uses, to catch old code that might be using them differently. (Added variable to control this in search.c -- `warn-about-possibly-incompatible-back- references', on by default for the moment. Declared in lisp.h. ---------------- process/SIGIO improvements ------------------- * process-unix.c: * process-unix.c (get_internet_address): * process-unix.c (unix_canonicalize_host_name): * process-unix.c (unix_open_network_stream): * process-unix.c (unix_open_multicast_group): define USE_GETADDRINFO to replace more complex conditional, and use it. the code conditionalized on this in unix_open_network_stream had *serious* problems handling errors. it's now fixed, and major amounts of duplicate code between the two versions were combined. don't disable SIGIO and other interrupts unless CONNECT_NEEDS_SLOWED_INTERRUPTS is defined -- don't penalize OS's without bugs. similarly for a freebsd bug that was affecting all OS's. * s\ultrix.h: define CONNECT_NEEDS_SLOWED_INTERRUPTS, since that's the OS mentioned as having a kernel bug. * sysdep.c (request_sigio_on_device): * sysdep.c (unrequest_sigio_on_device): fix SIGIO problems on Linux. add check for O_ASYNC in case it's defined and FASYNC isn't. add comment about other ways to do SIGIO on Linux. * callproc.c (Fold_call_process_internal): * process.c (Fstart_process_internal): Deal with the possibility that `default-directory' doesn't have terminating slash. Correct comments about vfork. ---------------- Miscellaneous bug fixes/cleanup ------------------- * callint.c (Finteractive): Add lots of documentation -- exactly what the Lisp equivalents of all the interactive specs are. * console.h (struct console): change type of quit_char to Emchar. * event-msw.c (lstream_type_create_mswindows_selectable): spacing change. * event-Xt.c: * event-msw.c: * event-stream.c: * events-mod.h: * events.c: * events.h: * frame-x.c: * gpmevent.c: * keymap.c: Eliminate events-mod.h and combine into events.h. * emacs.c: * emacs.c (make_arg_list_1): * emacs.c (main_1): A couple of char->Extbyte changes, add a comment. * glyphs-msw.c (mswindows_resource_instantiate): * glyphs-msw.c (mswindows_xface_instantiate): * glyphs-msw.c (mswindows_subwindow_instantiate): * glyphs-msw.c (mswindows_widget_instantiate): * glyphs-msw.c (mswindows_native_layout_instantiate): * glyphs-msw.c (mswindows_button_instantiate): * glyphs-msw.c (mswindows_edit_field_instantiate): * glyphs-msw.c (mswindows_progress_gauge_instantiate): * glyphs-msw.c (mswindows_tree_view_instantiate): * glyphs-msw.c (mswindows_tab_control_instantiate): * glyphs-msw.c (mswindows_label_instantiate): * glyphs-msw.c (mswindows_scrollbar_instantiate): * glyphs-msw.c (mswindows_combo_box_instantiate): Correct indentation of function defns to not exceed 80 cols. Try (sort of) to fix some code that sets the colors of the progress gauge. (Commented out) * keymap.c (syms_of_keymap): use DEFSYMBOL. * process.c (read_process_output): No need to fiddle with zmacs_region_stays, now that bogus clearing of it (see below) is removed. * search.c (Freplace_match): warning fix. 2001-05-03 Martin Buchholz * s/aix4.h: Fix crash with xlc -O3. Improve comment explaining how -O3 works. 2001-05-02 Jerry James * faces.h (SET_FACE_PROPERTY): pass parameters to Fadd_spec_to_specifier in the correct order. 2001-05-01 Martin Buchholz Fix link error with gcc 3.0 on Linux. * terminfo.c (UP): Remove. * terminfo.c (BC): Remove. * terminfo.c (PC): Remove. They weren't used, and in any case, these symbols should be defined in the *library*. 2001-04-30 Martin Buchholz Make string hashing more efficient. Makes intern much faster. Makes hash tables containing strings faster. * symbols.c (hash_string): A much better hash function. Change prototype to return unsigned value. (init_symbols_once_early): Use unsigned type for hash value. (oblookup): Use unsigned type for hash value. 2001-04-04 Martin Buchholz * keymap.c (Fmap_keymap): Revert to previous implementation, since elisp_maphash is now safe. * elhash.c: Remove erroneously added comment. * elhash.c (copy_compress_hentries): New. (Fmaphash): Use copy_compress_hentries. (elisp_maphash): Use copy_compress_hentries. (elisp_map_remhash): Use copy_compress_hentries. (elisp_maphash_unsafe): New. * elhash.h: Add prototype for elisp_maphash_unsafe. * elhash.c (Fmaphash): Avoid crashes/unpredictable behavior if a hash table is modified during a mapping function, perhaps indirectly via gc. (free_hentries): New. Avoid crash if a pdumped hash table is collected. (maphash_unwind): New. * tests.c: Add C-level hash table tests. 2001-04-28 Ben Wing * buffer.c (Ferase_buffer): * editfns.c (buffer_insert1): * editfns.c (Finsert_before_markers): * editfns.c (Finsert_string): * editfns.c (Finsert_char): * editfns.c (Fdelete_region): * editfns.c (Fwiden): * editfns.c (Fnarrow_to_region): remove bogus lines setting zmacs_region_stays to 0. * scrollbar-msw.c (mswindows_handle_mousewheel_event): remove debug lines. 2001-03-08 Mike Alexander * event-msw.c (mswindows_need_event_in_modal_loop): Don't dispatch a message if we didn't get one. (mswindows_need_event): Terminate the correct process when one exits instead of the first one on Vprocess_list and look for process termination when in mswindows_protect_modal_loop. 2001-04-20 Ben Wing * .cvsignore: Added stuff for Windows. 2001-04-15 Ben Wing * cmdloop.c (call_command_loop): Fix braino in bit-rotting code. * event-stream.c: * event-stream.c (Fnext_event): * event-stream.c (is_scrollbar_event): * event-stream.c (execute_command_event): Better fix for Yoshiki's `C-x @ h x causes a crash' problem. His fix introduces other problems. We filter out scrollbar events specifically, making them somewhat invisible to command-building, and not appearing in `this-command-keys'. More work is still needed (see comments in event-stream.c), but this fixes all the major problems. 2001-04-15 Gunnar Evermann * process-unix.c (unix_open_network_stream): If connect() fails invalidate file descriptor after closing it. From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 09:06:04 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA15776 for ; Wed, 9 May 2001 09:06:03 -0400 Received: by localhost id m14xTX8-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 21:57:38 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.16066.234550.50485@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 21:57:38 +0900 To: rendhalver@users.sourceforge.net Cc: xemacs-beta@xemacs.org Subject: build reports for 21.4 In-Reply-To: <15097.11926.967889.665526@ulthwe.dyndns.org> References: <15097.11926.967889.665526@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Peter" == Peter Brown writes: Peter> are build-reports for 21.4 needed ?? Still useful. It's some indication of the usage by platform, and it also tells us what people are using for configurations. We don't make much use of this data at the moment, but eventually it will go into a database of some kind. If you do "make check", then consistent reporters like you also give us some "time-series" information; we can check to see if warnings, test results, etc are changing from build to build. Watching the build report count go up makes me feel warm and fuzzy inside, too. :-) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From rendhalver@users.sourceforge.net Wed May 9 09:17:55 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA16421 for ; Wed, 9 May 2001 09:17:53 -0400 Received: from ulthwe.dyndns.org (p86-tnt1.brs.ihug.com.au [203.173.188.86]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id XAA28723; Wed, 9 May 2001 23:17:49 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p86-tnt1.brs.ihug.com.au [203.173.188.86] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15097.17131.344613.601793@ulthwe.dyndns.org> Date: Wed, 9 May 2001 23:15:23 +1000 To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: build reports for 21.4 In-Reply-To: <15097.16066.234550.50485@turnbull.sk.tsukuba.ac.jp> References: <15097.11926.967889.665526@ulthwe.dyndns.org> <15097.16066.234550.50485@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Stephen J. Turnbull writes: > >>>>> "Peter" == Peter Brown writes: > > Peter> are build-reports for 21.4 needed ?? > > Still useful. It's some indication of the usage by platform, and it > also tells us what people are using for configurations. well if there is any build options you specifically want checked on linux let me know happy to chuck them :) > We don't make much use of this data at the moment, but eventually it > will go into a database of some kind. if you need any perl hacking to get that onfo into a DB let me know i maybe able to help as ive done lots of playing with perl for web things > If you do "make check", then > consistent reporters like you also give us some "time-series" > information; we can check to see if warnings, test results, etc are > changing from build to build. nice to be considered a consistent reporter :) its prolly due to adrians build package and subscribing to cvs-commits oki will hack my build package options to include those make check buffers then > Watching the build report count go up makes me feel warm and fuzzy > inside, too. :-) can definatly understand warm and fuzzyness ;) "warm and fuzzy" is a good thing to feel so i guess i will keep on sending them -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 09:19:56 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA16512; Wed, 9 May 2001 09:19:54 -0400 Received: by localhost id m14xTkS-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 9 May 2001 22:11:24 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.16892.560161.717187@turnbull.sk.tsukuba.ac.jp> Date: Wed, 9 May 2001 22:11:24 +0900 To: Alexey Mahotkin Cc: ben@xemacs.org, xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.12769.931887.711914@tyranny.hsys.msk.ru.> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.12769.931887.711914@tyranny.hsys.msk.ru.> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Alexey" == Alexey Mahotkin writes: Alexey> Anyway it seems like we need to implement Alexey> (x-set-keysym-translation/-subset) anyway, how do you Alexey> think? Or just fix 21.4 (see below) and get done with Alexey> that? My preference is the fix for 21.4. That's an ugly bug. x-set-keysym... stuff should be targeted for 21.5. It is still needed there, we won't be eliminating no-mule support any time soon. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From ben@666.com Wed May 9 09:42:51 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id JAA18003 for ; Wed, 9 May 2001 09:42:49 -0400 Received: (qmail 30637 invoked by alias); 9 May 2001 13:42:38 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 30618 invoked by uid 0); 9 May 2001 13:42:37 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 9 May 2001 13:42:37 -0000 Message-ID: <3AF949AB.44B7160E@666.com> Date: Wed, 09 May 2001 06:44:11 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stephen J. Turnbull" CC: Yoshiki Hayashi , xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <3AF9077A.67EC110B@666.com> <15097.10401.480667.869203@turnbull.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Stephen J. Turnbull" wrote: > > >>>>> "Ben" == Ben Wing writes: > > Ben> speaking of this ... long ago i realized that xemacs-base > Ben> and mule-base definitely belong in the core, not as packages. > > What's the rationale? Is it just the build and runtime problems due > to missing libraries when bootstrapping, or is it something else? it has to do with maintainability. much of the stuff in xemacs-base really is part of the core [e.g. advice.el, comint.el, shell.el, etc.]. much of the core depends on xemacs-base, and xemacs-base depends on the core, and these two things are closely tied together. but there's an artificial separation here that makes it very difficult and cumbersome to make changes in xemacs-base, since we have to worry about keeping compatibility with old versions of xemacs and can't use other new core functions in them, etc. the whole purpose of the package system is to allow independent chunks to be maintained and upgraded independently, but in this case xemacs-base is *NOT* an independent package since it's so bound up with the core. any potential gain from being able to upgrade it independently is far outweighed by the loss caused by the difficulty in working on its code. the fact that some files do not seem part of the core is irrelevant. we simply move those files out -- or perhaps, move everything in xemacs-base that's really part of the core into the core, and leave the remainder. > > Ben> what do others think of this? > > I'm not sure. Many of those files do not implement "core" > functionality (eg, canna.el and mule-diag.el), and can use standard > APIs as documented in Lispref. > > Certainly, it's annoying to have build problems (eg, Norbert Koch's > make check failures) because commonly used libraries are in packages. > But I think it's better to fix that problem by having a subset of > packages distributed with XEmacs sources, and keep the logical > distinction between "core" libraries (which are implemented via > internal APIs we reserve the right to change on a whim) and "package" > libraries, which use only public APIs. > > I don't know how to implement this for CVS, though, or if it even > needs to be. I have thought about it for the tarballs. Note that it > is not a problem for the netinstaller. > > -- > University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN > Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 > _________________ _________________ _________________ _________________ > What are those straight lines for? "XEmacs rules." -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From colin@xemacs.org Wed May 9 10:41:07 2001 Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA21833 for ; Wed, 9 May 2001 10:41:02 -0400 Received: from pivsbh2-idmz.ms.com (localhost [127.0.0.1]) by pivsbh2.ms.com (Postfix) with SMTP id 5EF2A24C6 for ; Wed, 9 May 2001 10:37:16 -0400 (EDT) Received: from hqfid1.morgan.com (unknown [144.14.36.134]) by pivsbh2-idmz.ms.com (Postfix) with ESMTP id 3F65424CA for ; Wed, 9 May 2001 10:37:16 -0400 (EDT) Received: from hqgcs1.morgan.com (hqgcs1.morgan.com [144.14.254.14]) by hqfid1.morgan.com (8.8.5/hub+ldap v2.4) with ESMTP id KAA24169 for ; Wed, 9 May 2001 10:37:15 -0400 (EDT) Received: (craffert@localhost) by hqgcs1.morgan.com (SGI-8.9.3/sendmail.cf.client v1.05) id OAA18222; Wed, 9 May 2001 14:37:15 GMT X-Authentication-Warning: hqgcs1.morgan.com: craffert set sender to colin@xemacs.org using -f To: XEmacs Beta List Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs Keywords: alt,put,self-insert-command,global-set-key,ascii-character References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> From: Colin Rafferty Mail-Copies-To: never X-Face: $%/0:A=g/0mfAd_-AHyqWK$D&dZ;sk7OJFQw",'KwWutsgG|+n.E:(Q<*Sw=&]o4>i1<-[<;W,f#;.,W'}w"y2\8}Iki{CzF,/BaDHcMIvNQ~ZVw19<^CD}wZV2/NRg8.\WHR.%^H#CZ#&K]GQo!a;KtLwLlRk0MNdjf--29.ZW.[t'mOdEnN|a^;AV{<\[!h_0}/{h{iQILgp9mG*;]:_R_@bL<,Fkfm~GYf@<@UH$0?%.v"a[5Z X-Y-Zippy: ..I'll make you an ASHTRAY!! Date: 09 May 2001 10:37:15 -0400 In-Reply-To: Hrvoje Niksic's message of "09 May 2001 13:25:20 +0200" Message-ID: Lines: 27 User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hrvoje Niksic writes: > (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) > (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) How would I do this for something other than an actual key. For example, in the A+ programming language, I would like to have the following: (global-set-key [('alt ?a)] 'self-insert-command) (put [(alt ?a)] 'ascii-character ?\301) However, the `put' fails (of course) with the following error: >> Object type has no settable properties: [(alt ?\[)] Is there a way that I can bind A-a to an arbitrary symbol, and then manipulate it appropriately: (bind-key-sequence-to-symbol [('alt ?a)] 'ALT_A) (global-set-key 'ALT_A 'self-insert-command) (put 'ALT_A 'ascii-character ?\301) Thanks. -- Colin From hniksic@arsdigita.com Wed May 9 11:06:56 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA23501 for ; Wed, 9 May 2001 11:06:55 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xVYD-0006ad-00 for ; Wed, 09 May 2001 17:06:53 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 09 May 2001 17:06:53 +0200 In-Reply-To: (Colin Rafferty's message of "09 May 2001 10:37:15 -0400") Message-ID: Lines: 48 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Colin Rafferty writes: > Hrvoje Niksic writes: > > > (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) > > (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) > > How would I do this for something other than an actual key. For > example, in the A+ programming language, I would like to have the > following: > > (global-set-key [('alt ?a)] 'self-insert-command) > (put [(alt ?a)] 'ascii-character ?\301) You'd have to be more tricky than that. I hoped something like this might have a chance to work: (defun colins-command () (interactive) (self-insert-internal ?\301) ;; Attempt No. 1 to fool isearch. (setq this-command 'self-insert-command)) ;; Attempt No. 2 to fool isearch. (put 'colins-command 'isearch-command t) (global-set-key [(alt a)] 'colins-command) But it doesn't work because isearch-maybe-frob-keyboard-macros, which gets called from isearch-pre-command-hook, i.e. *before* your function is run, explicitly checks for self-insert-command. I was tempted to try to "fix" isearch-maybe-frob-keyboard-macros, but after some thinking I concluded that it was the only reasonable thing to do. Remember that isearch needs to update its search string with the new character. Isearch cannot know in advance what character colins-command is about to insert; since colins-command is not self-insert-command, just using last-command-event would be wrong. But then I remembered that "keysyms" aren't really cast in stone, and that with a little trickery you can fake keysyms from Lisp. Here is the result: (global-set-key '(alt a) [fake-keysym]) (global-set-key 'fake-keysym 'self-insert-command) (put 'fake-keysym 'ascii-character ?\301) From rendhalver@ulthwe.dyndns.org Wed May 9 12:15:29 2001 Received: from ulthwe.dyndns.org (p196-tnt1.brs.ihug.com.au [203.173.188.196]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA28524 for ; Wed, 9 May 2001 12:15:22 -0400 Received: (from rendhalver@localhost) by ulthwe.dyndns.org (8.11.0/8.11.0) id f49GCpP13771; Thu, 10 May 2001 02:12:51 +1000 Date: Thu, 10 May 2001 02:12:51 +1000 Message-Id: <200105091612.f49GCpP13771@ulthwe.dyndns.org> From: To: xemacs-beta@xemacs.org Subject: problem with 21.5.1 This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.5 (beta1) "anise" [Lucid] (i686-pc-linux, Mule) of Thu May 10 2001 on ulthwe.dyndns.org configured using `configure --with-mule --prefix=/usr/local/xemacs-beta --with-prefix --srcdir=/Hacking/src/xemacs/xemacs-21.5' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: hi all got a problem with 21.5.1 (latest cvs) it complains about not finding pces-xm i have no idea what that does i looked for it in the file system but it doesnt exist let me know if you need more info my init.el file works with 21.4.1 just fine here is the output from -debug-init Backtrace Signaling: (file-error "Cannot open load file" "pces-xm") signal(file-error ("Cannot open load file" "pces-xm")) load("pces-xm" nil t nil) si:require(pces-xm nil) require(pces-xm) byte-code("..." [product find-coding-system raw-text-dos copy-coding-system no-conversion-dos raw-text-mac no-conversion-mac raw-text-unix no-conversion-unix featurep mule require pces-xm pces-20 apel-ver put provide pces-xfc product-find-by-name "APEL" product-run-checkers (10 2) product-add-feature product-version vector nil] 12) load-internal("pces-xfc" nil t nil binary) load("pces-xfc" nil t nil) si:require(pces-xfc nil) require(pces-xfc) byte-code("..." [emacs-major-version product require poe fboundp open-network-stream tcp featurep xemacs file-coding pces-xfc pces-raw mule 20 pces-e20 pces-om boundp NEMACS pces-nemacs apel-ver put provide pces product-find-by-name "APEL" product-run-checkers (10 2) product-add-feature product-version vector nil] 12) load-internal("pces" nil t nil binary) load("pces" nil t nil) si:require(pces nil) require(pces) byte-code("..." [emacs-major-version product current-load-list require pces featurep mule xemacs poem-xm 20 poem-e20 poem-om boundp NEMACS poem-nemacs poem-ltn1 fboundp string-as-unibyte # byte-optimizer (nil byte-compile-inline-expand) error "%s already has a byte-optimizer, can't make it inline" put byte-compile-inline-expand defsubst-maybe t string-as-multibyte # charset-after # defun-maybe char-octet # apel-ver provide poem product-find-by-name "APEL" product-run-checkers (10 2) product-add-feature product-version vector nil] 12) load-internal("poem" nil t nil binary) load("poem" nil t nil) si:require(poem nil) require(poem) byte-code("..." [mouse-button-3 mouse-button-2 mouse-button-1 emacs-major-version running-xemacs current-load-list require poe running-emacs-18 boundp 18 featurep xemacs running-mule-merged-emacs MULE mule running-xemacs-with-mule running-emacs-19 19 running-emacs-19_29-or-later 29 20 running-xemacs-19 running-xemacs-20-or-later running-xemacs-19_14-or-later 14 button1 button2 button3 [mouse-1] [mouse-2] [down-mouse-3] nil fboundp tl:make-overlay defalias make-overlay make-obsolete tl:overlay-put overlay-put tl:overlay-buffer overlay-buffer poem mcharset invisible emacs-minor-version] 3) load-internal("emu" nil t nil binary) load("emu" nil t nil) require(emu) byte-code("..." [require emu tl-str autoload add-path "file-detect" get-latest-path file-installed-p] 3) load-internal("tl-misc" nil t nil binary) load("tl-misc" nil t nil) require(tl-misc) byte-code("..." [require tl-misc call-after-loaded tm-view #] 3) load-internal("tm-setup" nil t nil binary) load("tm-setup" nil t nil) require(tm-setup) load-internal("mime-setup" nil nil nil binary) load("mime-setup") load-internal("vm-conf" nil nil nil undecided) load("vm-conf") load-library("vm-conf") load-internal("/home/rendhalver/.xemacs/init.el" t t t undecided) load("/home/rendhalver/.xemacs/init.el" t t t) load-user-init-file() load-init-file() command-line() normal-top-level() Recent keystrokes: misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user Recent messages (most recent first): Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Entering debugger... Loading debug...done Loading debug... Loading mime-setup... Loading vm-conf... Loading /home/rendhalver/.recent-files.el...done Loading /home/rendhalver/.recent-files.el... From colin@xemacs.org Wed May 9 12:24:57 2001 Received: from hqvsbh1.ms.com (hqvsbh1-x0.ms.com [205.228.12.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA29173 for ; Wed, 9 May 2001 12:24:56 -0400 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f49GOtv11476 for ; Wed, 9 May 2001 12:24:56 -0400 (EDT) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9894254951.011430; Wed, 9 May 01 12:24:55 -0400 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.11.3/8.11.3) id f49GOsu11419 for ; Wed, 9 May 2001 12:24:54 -0400 (EDT) Received: from unknown(144.14.36.134) by hqvsbh1 via smap (4.1) id sma.9894254931.011360; Wed, 9 May 01 12:24:53 -0400 Received: from hqgcs1.morgan.com (hqgcs1.morgan.com [144.14.254.14]) by hqfid1.morgan.com (8.8.5/hub+ldap v2.4) with ESMTP id MAA13568 for ; Wed, 9 May 2001 12:24:53 -0400 (EDT) Received: (craffert@localhost) by hqgcs1.morgan.com (SGI-8.9.3/sendmail.cf.client v1.05) id QAA65547; Wed, 9 May 2001 16:24:53 GMT X-Authentication-Warning: hqgcs1.morgan.com: craffert set sender to colin@xemacs.org using -f To: XEmacs Beta List Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs Keywords: alt,global-set-key,self-insert-command,put,hrvoje,fake-keysym,ascii-character References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> From: Colin Rafferty Mail-Copies-To: never X-Face: ""xJff%{>hr-{:QXl"Xk2O@@(+F]e{"%EYQiW@mUuvEsL>=mx96j12qW[%m;|:B^n{J8k?Mz[K1_+H;$v,nYx^1o_=4M,L+]FIU~[[`-w~~xsy-BX,?tAF_.8u&0y*@aCv;a}Y'{w@#*@iwAl?oZpvvv X-Y-Zippy: Yow! Are we in the perfect mood? Date: 09 May 2001 12:24:52 -0400 In-Reply-To: Hrvoje Niksic's message of "09 May 2001 17:06:53 +0200" Message-ID: Lines: 29 User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hrvoje Niksic writes: > Colin Rafferty writes: >> Hrvoje Niksic writes: >> > (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) >> > (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) >> How would I do this for something other than an actual key. >> (bind-key-sequence-to-symbol [('alt ?a)] 'ALT_A) >> (global-set-key 'ALT_A 'self-insert-command) >> (put 'ALT_A 'ascii-character ?\301) > ... > But then I remembered that "keysyms" aren't really cast in stone, and > that with a little trickery you can fake keysyms from Lisp. Here is > the result: > (global-set-key '(alt a) [fake-keysym]) > (global-set-key 'fake-keysym 'self-insert-command) > (put 'fake-keysym 'ascii-character ?\301) Thank you very much Hrvoje. This is exactly what I needed. I think I understand key bindings a little but more now. -- Colin From kifer@sbkifer.cs.sunysb.edu Wed May 9 14:33:05 2001 Received: from sbcs.cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA05080 for ; Wed, 9 May 2001 14:33:03 -0400 Received: from sbkifer (sbkifer [130.245.1.35]) by sbcs.cs.sunysb.edu (8.9.3/8.9.3) with SMTP id OAA16629 for ; Wed, 9 May 2001 14:31:06 -0400 (EDT) Message-Id: <200105091831.OAA16629@sbcs.cs.sunysb.edu> From: kifer@cs.sunysb.edu (Michael Kifer) To: xemacs-beta@xemacs.org Subject: Using dired-handler-fn as a file name handler for file-local-copy Date: Wed, 09 May 2001 14:31:08 -0400 Sender: kifer@cs.sunysb.edu It seems that EFS attaches dired-handler-fn as a handler for file-local-copy to every local file: (find-file-name-handler "/tmp/foo" 'file-local-copy) I believe this is an illegitimate use, because by definition such a handler is supposed to help make a local copy of a file. It is not supposed to be used for every imaginable hack. In EFS it is used to update the Dired buffer, which has nothing to do with making local copies. The problem is that this (what I believe illegitimate) use has the potential to confuse other packages (and it does cause hickups to Ediff; it probably would confuse trump.el or cause problems porting it to XEmacs). --michael From ben@666.com Wed May 9 15:09:46 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id PAA07437 for ; Wed, 9 May 2001 15:09:45 -0400 Received: (qmail 11354 invoked by alias); 9 May 2001 19:09:40 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 11295 invoked by uid 0); 9 May 2001 19:09:39 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 9 May 2001 19:09:39 -0000 Message-ID: <3AF99651.C4DE3E2D@666.com> Date: Wed, 09 May 2001 12:11:13 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Wing CC: xemacs-patches@xemacs.org, XEmacs beta list Subject: Re: [PATCH] References: <200105091348.JAA18493@gwyn.tux.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ack! i did write changelog entries, just forgot to include them here. this includes the changelogs for both patches i sent out. stephen, the regex changes relate to the previous changes i made, so you don't need them. 2001-05-09 Ben Wing * regex.c (regex_compile): fix error compiling regexps with back-references in them. 2001-05-09 Ben Wing * files.el (find-file-noselect): * files.el (recover-session-finish): fix byte-compilation warnings. 2001-05-09 Ben Wing * font.el (bold): New. * font.el (italic): New. * font.el (oblique): New. * font.el (dim): New. * font.el (underline): New. * font.el (overline): New. * font.el (linethrough): New. * font.el (strikethru): New. * font.el (reverse): New. * font.el (blink): New. * font.el (smallcaps): New. * font.el (bigcaps): New. * font.el (dropcaps): New. * gtk-widget-accessors.el (import-widget-accessors): * widgets-gtk.el (gtk-widget-instantiate-internal): * x-font-menu.el (x-font-menu-font-data): New. * x-font-menu.el (x-font-menu-load-font): fix byte-compilation warnings. 2001-05-09 Ben Wing * etags.c (add_regex): temporary fix to avoid crashes with new regex code. 2001-05-09 Ben Wing * PROBLEMS: * PROBLEMS (Note): i swear i already committed this. 2001-05-09 Ben Wing * xemacs.mak (OS): do not warn about gtk when we're not trying to compile with it. Ben Wing wrote: > > NOTE: This patch has been committed. > > Stephen, if you didn't get the latest PROBLEMS change, here it is once > again. no more changes; it just didn't want to commit itself. > > the only other thing you want is the change to nt/xemacs.mak. > > fixup Patch (bash -ci "cvs-diff -no-changelog "): > > ? confdefs.h > ? man/lispref/patch.exe.stackdump > ? src/xemacs.opt > cvs server: Diffing . > Index: PROBLEMS > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/PROBLEMS,v > retrieving revision 1.46 > diff -u -r1.46 PROBLEMS > --- PROBLEMS 2001/04/12 18:20:32 1.46 > +++ PROBLEMS 2001/05/09 10:11:05 > @@ -20,10 +20,10 @@ > Also, Try finding the things you need using one of the search commands > XEmacs provides (e.g. `C-s'). > > -A general advice: > - WATCH OUT for .emacs file! ~/.emacs is your Emacs init file. If > - you observe strange problems, invoke XEmacs with the `-q' option > - and see if you can repeat the problem. > +General advice: > + WATCH OUT for your init file! (~/.xemacs/init.el or ~/.emacs) If > + you observe strange problems, invoke XEmacs with the `-vanilla' > + option and see if you can repeat the problem. > > > * Problems with building XEmacs > @@ -552,60 +552,53 @@ > and later. > > ** Cygwin > + > *** In general use etc/check_cygwin_setup.sh to trap environment problems. > > The script etc/check_cygwin_setup.sh will attempt to detect whether > -you have a suitable environment for building. This script may not work > +you have a suitable environment for building. This script may not work > correctly if you are using ash instead of bash (see below). > - > -*** X11 not detected. > - > -This is usually because xmkmf is not in your path or because you are > -using the default cygwin shell. The default cygwin shell (/bin/sh.exe) > -is ash which appears to work in most circumstances but has some weird > -failure modes. I recommend replacing sh.exe with bash.exe, this will > -mean configure is slower but more reliable. > > -*** Subprocesses do not work. > - > -You do not have "tty" in your CYGWIN32 (for b19) or CYGWIN (for b20) > -environment variable. This must be set in your autoexec.bat (win95) or > -the system properties (winnt) as it must be read before the cygwin dll > -initializes. > - > -*** ^G does not work on hung subprocesses. > +*** Syntax errors running configure scripts, make failing with exit code 127 > + in inexplicable situations, etc. > > -This is a known problem. It can be remedied with cygwin b20 or greater > -by defining BROKEN_SIGIO in src/s/cygwin32.h, however this currently > -leads to instability in XEmacs. > +This may be because you are using the default cygwin shell. The > +default cygwin shell (/bin/sh.exe) is ash which appears to work in > +most circumstances but has some weird failure modes. You need to > +replace the symlink with bash.exe. > + > +*** Lots of compile errors, esp. on lines containing macro definitions > + terminated by backslashes. > + > +Your partition holding the source files is mounted binary. It needs > +to be mounted text. (This will not screw up any binary files because > +the Cygwin utilities specify explicitly whether they want binary or > +text mode when working with source vs. binary files, which overrides > +the mount type.) To fix this, you just need to run the appropriate > +mount command once -- afterwards, the settings are remembered in the > +registry. > + > +*** Errors from make like /c:not found. > + > +Make sure you set the environment variable MAKE_MODE to UNIX in your > +.bashrc, Control Panel (Windows 2000/NT), or AUTOEXEC.BAT (Windows > +98/95). > > -*** The XEmacs executable crashes at startup. > - > -This can be caused by many things. > - > -If you are running with X11 you need to have cygwin b19 or cygwin > -b20.1 or greater, cygwin b20 will not work. > - > -If you are running with cygwin b19 make sure you are using egcs 1.0.2 > -rather than vanilla gcc. XEmacs builds by default with -O3 which does > -not work with the gcc that ships with b19. Alternatively use -O2. > - > *** The info files will not build. > > -makeinfo that ships with cygwin (all versions) is a noop. You need to > +makeinfo that ships with Cygwin (all versions) doesn't work. You need to > obtain makeinfo from somewhere or build it yourself. > > -*** I have no graphics. > +*** XEmacs hangs while attempting to rebuild the .elc files. > > -You need to obtain the various graphics libraries. Pre-built versions > -of these and the X libraries are located on the XEmacs website in > -ftp://ftp.xemacs.org/pub/aux/cygwin*. > +Check to make sure you're not configuring with rel-alloc. The relocating > +allocator does not currently work under Cygwin due to bugs in Cygwin's > +mmap(). > > -*** There are no images in the toolbar buttons. > +*** Trying to build with X, but X11 not detected. > > -You need version 4.71 of commctrl.dll which does not ship with windows > -95. You can get this by installing IE 4.0 or downloading it from the > -microsoft website. > +This is usually because xmkmf is not in your path or because you are > +using the default cygwin shell. (See above.) > > > * Problems with running XEmacs > @@ -1704,13 +1697,37 @@ > > > ** Windows > -*** Emacs exits with "X protocol error" when run with an X server for > -Windows. > +*** In general, the Windows code is less mature than the Unix code. > + > +The Windows code base is still changing quickly. If you are > +experiencing problems, try the latest beta version to see if the > +problem still exists. Also ask on xemacs-nt@xemacs.org. > + > > -A certain X server for Windows had a bug which caused this. > -Supposedly the newer 32-bit version of this server doesn't have the > -problem. > +** Cygwin > +*** Subprocesses do not work. > > +You do not have "tty" in your CYGWIN environment variable. This must > +be set in your autoexec.bat (win95) or the system properties (winnt) > +as it must be read before the cygwin DLL initializes. > + > +*** ^G does not work on hung subprocesses. > + > +This is a known problem. It can be remedied by defining BROKEN_SIGIO > +in src/s/cygwin.h, however this currently leads to instability in XEmacs. > +(#### is this still true?) > + > +*** Errors from make like `/c:not found' when running `M-x compile'. > + > +Make sure you set the environment variable MAKE_MODE to UNIX in your > +init file (.xemacs/init.el), Control Panel (Windows 2000/NT), or > +AUTOEXEC.BAT (Windows 98/95). > + > +*** There are no images in the toolbar buttons. > + > +You need version 4.71 of commctrl.dll which does not ship with windows > +95. You can get this by installing IE 4.0 or downloading it from the > +microsoft website. > > > * Compatibility problems (with Emacs 18, GNU Emacs, or previous XEmacs/lemacs) > cvs server: Diffing dynodump > cvs server: Diffing dynodump/i386 > cvs server: Diffing dynodump/ppc > cvs server: Diffing dynodump/sparc > cvs server: Diffing etc > cvs server: Diffing etc/custom > cvs server: Diffing etc/custom/example-themes > cvs server: Diffing etc/eos > cvs server: Diffing etc/idd > cvs server: Diffing etc/photos > cvs server: Diffing etc/sparcworks > cvs server: Diffing etc/tests > cvs server: Diffing etc/tests/external-widget > cvs server: Diffing etc/toolbar > cvs server: Diffing info > cvs server: Diffing lib-src > Index: lib-src/etags.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lib-src/etags.c,v > retrieving revision 1.24 > diff -u -r1.24 etags.c > --- lib-src/etags.c 2001/04/12 18:21:00 1.24 > +++ lib-src/etags.c 2001/05/09 10:11:18 > @@ -5163,6 +5163,8 @@ > (void) scan_separators (name); > > patbuf = xnew (1, struct re_pattern_buffer); > + memset (patbuf, 0, sizeof (struct re_pattern_buffer)); > + > /* Translation table to fold case if appropriate. */ > patbuf->translate = (ignore_case) ? lc_trans : NULL; > patbuf->fastmap = NULL; > cvs server: Diffing lisp > Index: lisp/font.el > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/font.el,v > retrieving revision 1.8 > diff -u -r1.8 font.el > --- lisp/font.el 2001/05/04 22:42:02 1.8 > +++ lisp/font.el 2001/05/09 10:11:24 > @@ -33,7 +33,9 @@ > (globally-declare-fboundp > '(x-list-fonts > mswindows-list-fonts ns-list-fonts internal-facep fontsetp get-font-info > - get-fontset-info mswindows-define-rgb-color cancel-function-timers)) > + get-fontset-info mswindows-define-rgb-color cancel-function-timers > + ;; #### perhaps we should rewrite font-warn to avoid the warning > + font-warn)) > > (globally-declare-boundp > '(global-face-data > @@ -222,20 +224,19 @@ > (format "font-%s-mask" attr))))))) > ))) > > -(let ((mask 0)) > - (define-new-mask bold (setq mask (1+ mask))) > - (define-new-mask italic (setq mask (1+ mask))) > - (define-new-mask oblique (setq mask (1+ mask))) > - (define-new-mask dim (setq mask (1+ mask))) > - (define-new-mask underline (setq mask (1+ mask))) > - (define-new-mask overline (setq mask (1+ mask))) > - (define-new-mask linethrough (setq mask (1+ mask))) > - (define-new-mask strikethru (setq mask (1+ mask))) > - (define-new-mask reverse (setq mask (1+ mask))) > - (define-new-mask blink (setq mask (1+ mask))) > - (define-new-mask smallcaps (setq mask (1+ mask))) > - (define-new-mask bigcaps (setq mask (1+ mask))) > - (define-new-mask dropcaps (setq mask (1+ mask)))) > +(define-new-mask bold 1) > +(define-new-mask italic 2) > +(define-new-mask oblique 3) > +(define-new-mask dim 4) > +(define-new-mask underline 5) > +(define-new-mask overline 6) > +(define-new-mask linethrough 7) > +(define-new-mask strikethru 8) > +(define-new-mask reverse 9) > +(define-new-mask blink 10) > +(define-new-mask smallcaps 11) > +(define-new-mask bigcaps 12) > +(define-new-mask dropcaps 13) > > (defvar font-caps-display-table > (let ((table (make-display-table)) > Index: lisp/gtk-widget-accessors.el > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/gtk-widget-accessors.el,v > retrieving revision 1.3 > diff -u -r1.3 gtk-widget-accessors.el > --- lisp/gtk-widget-accessors.el 2001/05/04 22:42:04 1.3 > +++ lisp/gtk-widget-accessors.el 2001/05/09 10:11:24 > @@ -107,6 +107,7 @@ > > (defun import-widget-accessors (file syms-function-name &rest description) > "Import multiple widgets, and emit a suitable vars_of_foo() function for them.\n" > + (declare (special c-mode-common-hook c-mode-hook)) > (let ((c-mode-common-hook nil) > (c-mode-hook nil)) > (find-file file)) > Index: lisp/widgets-gtk.el > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/widgets-gtk.el,v > retrieving revision 1.3 > diff -u -r1.3 widgets-gtk.el > --- lisp/widgets-gtk.el 2001/05/04 22:42:16 1.3 > +++ lisp/widgets-gtk.el 2001/05/09 10:11:25 > @@ -134,7 +134,6 @@ > (gtk-widget-get-style > (frame-property nil 'text-widget)))) > widget) > - (setq x widget) > widget)) > > (defun gtk-widget-property-internal () > Index: lisp/x-font-menu.el > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/x-font-menu.el,v > retrieving revision 1.8 > diff -u -r1.8 x-font-menu.el > --- lisp/x-font-menu.el 2001/05/04 22:42:17 1.8 > +++ lisp/x-font-menu.el 2001/05/09 10:11:25 > @@ -190,7 +190,7 @@ > ;; If the user didn't specify one (with "-dt-*-*", for example) > ;; get the truename and use the possibly suboptimal data from that. > ;;;###autoload > -(defun* x-font-menu-font-data (face dcache) > +(defun x-font-menu-font-data (face dcache) > (let* ((case-fold-search t) > (domain (if font-menu-this-frame-only-p > (selected-frame) > @@ -207,21 +207,22 @@ > (string-match x-font-regexp-foundry-and-family truename)) > (setq family (capitalize (match-string 1 truename))) > (setq entry (vassoc family (aref dcache 0)))) > - (when (null entry) > - (return-from x-font-menu-font-data (make-vector 5 nil))) > - > - (when (string-match x-font-regexp name) > - (setq weight (capitalize (match-string 1 name))) > - (setq size (string-to-int (match-string 6 name)))) > + > + (if (null entry) > + (make-vector 5 nil) > + > + (when (string-match x-font-regexp name) > + (setq weight (capitalize (match-string 1 name))) > + (setq size (string-to-int (match-string 6 name)))) > > - (when (string-match x-font-regexp truename) > - (when (not (member weight (aref entry 1))) > - (setq weight (capitalize (match-string 1 truename)))) > - (when (not (member size (aref entry 2))) > - (setq size (string-to-int (match-string 6 truename)))) > - (setq slant (capitalize (match-string 2 truename)))) > + (when (string-match x-font-regexp truename) > + (when (not (member weight (aref entry 1))) > + (setq weight (capitalize (match-string 1 truename)))) > + (when (not (member size (aref entry 2))) > + (setq size (string-to-int (match-string 6 truename)))) > + (setq slant (capitalize (match-string 2 truename)))) > > - (vector entry family size weight slant))) > + (vector entry family size weight slant)))) > > (defun x-font-menu-load-font (family weight size slant resolution) > "Try to load a font with the requested properties. > cvs server: Diffing lisp/mule > cvs server: Diffing lisp/term > cvs server: Diffing lock > cvs server: Diffing lwlib > cvs server: Diffing man > cvs server: Diffing man/internals > cvs server: Diffing man/lispref > cvs server: Diffing man/new-users-guide > cvs server: Diffing man/xemacs > cvs server: Diffing modules > cvs server: Diffing modules/base64 > cvs server: Diffing modules/ldap > cvs server: Diffing modules/sample > cvs server: Diffing modules/zlib > cvs server: Diffing netinstall > cvs server: Diffing nt > Index: nt/xemacs.mak > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v > retrieving revision 1.61 > diff -u -r1.61 xemacs.mak > --- nt/xemacs.mak 2001/05/01 12:05:20 1.61 > +++ nt/xemacs.mak 2001/05/09 10:11:33 > @@ -1500,19 +1500,10 @@ > !endif > !if $(HAVE_GTK) > -------------------------------------------------------------------- > - WARNING: Compiling WITHOUT GTK support. > - WARNING: As of xemacs-21.2-b44 > - WARNING: gtk-xemacs is not supported on MSWindows (mingw or msvc). > - WARNING: Yes, we know that gtk has been ported to native MSWindows > - WARNING: but XEmacs is not yet ready to use that port. > - -------------------------------------------------------------------- > -!else > - -------------------------------------------------------------------- > - WARNING: Compiling without GTK support. > - WARNING: As of xemacs-21.2-b44 > - WARNING: gtk-xemacs is not supported on MSWindows (mingw or msvc). > - WARNING: Yes, we know that gtk has been ported to native MSWindows > - WARNING: but XEmacs is not yet ready to use that port. > + WARNING: You specified HAVE_GTK=1, but we are compiling WITHOUT GTK support. > + WARNING: gtk-xemacs is not currently supported on MSWindows (mingw or msvc). > + WARNING: Yes, we know that gtk has been ported to native MSWindows, but > + WARNING: XEmacs is not yet ready to use that port. > -------------------------------------------------------------------- > !endif > !if $(HAVE_XPM) > cvs server: Diffing nt/installer > cvs server: Diffing nt/installer/Wise > cvs server: Diffing src > Index: src/regex.c > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/regex.c,v > retrieving revision 1.26 > diff -u -r1.26 regex.c > --- src/regex.c 2001/05/04 22:42:32 1.26 > +++ src/regex.c 2001/05/09 10:11:42 > @@ -3087,6 +3087,8 @@ > else > PATUNFETCH; > } > + else > + PATUNFETCH; > } > > if (reg > bufp->re_nsub) > cvs server: Diffing src/m > cvs server: Diffing src/s > cvs server: Diffing tests > cvs server: Diffing tests/DLL > cvs server: Diffing tests/Dnd > cvs server: Diffing tests/automated > cvs server: Diffing tests/gtk > cvs server: Diffing tests/mule > cvs server: Diffing tests/tooltalk -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From alexm@hsys.msk.ru Wed May 9 16:35:26 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA12176 for ; Wed, 9 May 2001 16:35:25 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp132-25.dialup.mtu-net.ru [62.118.132.25]) by mtu.ru (Postfix) with ESMTP id 7DD36733A for ; Thu, 10 May 2001 00:35:19 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 359 invoked by uid 1000); 9 May 2001 20:24:30 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.42878.842212.851171@tyranny.hsys.msk.ru> Date: Thu, 10 May 2001 00:24:30 +0400 (MSD) To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: 'ascii-character property broken (Was (set-xkb-cyrillic-charset) In-Reply-To: <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "SJT" == Stephen J Turnbull writes: Hrvoje> If it works, it should also work with isearch and friends. Alexey> No, it doesn't. SJT> Bletch. Thanks for testing it. Details (substitute actual characters instead of (0xFF) and (0xCA)): (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) ===> ?(0xFF) (get 'Cyrillic_HARDSIGN 'ascii-character) ===> ?(0xFF) But when I try to type that character, it shows (0xCA) and after that: (get 'Cyrillic_HARDSIGN 'ascii-character) ===> ?(0xCA) setting it again with `put' yields the same results. Code in src/events.c (`event-to-character') was effectively untouched since 21.1.x. --alexm From alexm@hsys.msk.ru Wed May 9 17:14:47 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA14305 for ; Wed, 9 May 2001 17:14:46 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-170.dialup.mtu-net.ru [62.118.131.170]) by mtu.ru (Postfix) with ESMTP id BEF50731A for ; Thu, 10 May 2001 01:14:43 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 595 invoked by uid 1000); 9 May 2001 21:13:54 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.45842.183634.985129@tyranny.hsys.msk.ru> Date: Thu, 10 May 2001 01:13:54 +0400 (MSD) To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "SJT" == Stephen J Turnbull writes: Alexey> In this case first clause should be (it should modify Alexey> cyrillic_koi8_r[] that is stored somewhere in some hashtable Alexey> and used by x_keysym_to_character(): SJT> That's what I wanted to avoid. OK, I see that it's probably SJT> unavoidable in no-mule. And it's probably right to do it inside SJT> that switch (this automatically makes it configurable according SJT> to character set, SJT> so that the iso-to-koi translation does NOT get SJT> applied in the Latin-2 buffer, which would really hinder a SJT> Polish/Russian translator). Just for clarity: there is no "iso-to-koi" translation here and no concept of "Latin-2 buffer". I speak of non-Mule, and there is only one-to-one translation between internal representation (single byte), font encoding and external representation (bytes in files). It is very common kind of setup AFAIK. We just need to implement various translations between Cyrillic_XXX and those one-byte encodings. SJT> As far as I know, however, SJT> it's not Mule XEmacs that wants the to fonts match internal SJT> representation. It does not want. It just doesn't go into trouble of doing something like Mule's (set-charset-ccl-program). SJT> It's that XEmacs developers have never done SJT> anything about using the facilities provided by Mule to handle SJT> fonts that have different encoding from internal. Huh? What about ccl-programs? Alexey> I think they should be predefined in stock XEmacs w/o any Lisp Alexey> definitions (in style of cyrillic[] array that currently Alexey> exists). SJT> OK, I agree about the need for predefinition, especially in SJT> no-Mule. However, in practice, we don't know which fonts are SJT> important. There are two most important encodings to support for non-Mule: koi8-r and iso8859-5 (for compatibility with default). Then there is more seldom used cp1251 (for compatibility with Windows). Finally there is cp866 that needs to be implemented mostly for completeness. SJT> So there should be a Lisp-level way to create and SJT> install such arrays. If you hack only for Cyrillic, you will SJT> create a Russianized XEmacs. Why ever? Cyrillic != Russian. As far as encodings allow, I'll surely try to support every Cyrillic character. E. g. koi8-r just does not include NJE, KJE, DZHE, TSHE and friends, while cp1251 and 8859-5 does include those. SJT> And will you put in (eg) the extra SJT> characters the Ukrainians want? Ukrainians have some variance of koi8-r called something like koi8-u. I'm sure someone from Ukraine will implement this encoding when there'll be general support for that and Ukrainian users will do (x-set-keysym-translation-subset 'cyrillic 'koi8-u) (See interface definition below). Nothing prevents us from doing that. SJT> I disagree strongly about implementing such arrays for Mule, SJT> however. Mule will use only the same array it is using currently (it will be renamed to cyrillic_iso8859_5[] probably, to reduce confusion). SJT> As for predefinition in C vs Lisp: We try to think in terms of SJT> implementing _everything_ in the text editor in Lisp, for SJT> robustness and flexibility. We move down to the C level when we SJT> want the efficiency. We don't _need_ it here; users will never SJT> see the delay in installing such a table from Lisp rather than C, SJT> since it only happens once per session. We do _need_ the Lisp SJT> level definition, since it's probable that Greeks, at least, will SJT> need this too. And we don't know who else! We get robust SJT> predefinition from Lisp by "dumping" the Lisp into the SJT> executable, where we always know where to find it. I just want to switch whole arrays, not single keysyms. I think that interface will be something like that: ;; define new Cyrillic encoding (x-define-keysym-translation-subset 'cyrillic 'koi8-r) (x-set-keysym-translation 'koi8-r 'Cyrillic_HARDSIGN ?\xFF) ... repeat for every Cyrillic character ;; this is done by user interactively or in ~/.emacs (x-set-keysym-translation-subset 'cyrillic 'koi8-r) Most popular encodings will be predefined in src/event-Xt.c, but still modifiable via (x-set-keysym-translation), surely (though this will probably be used only on newly defined keysym translation subsets). If there are no objections or additional comments, I'll start coding that tomorrow. --alexm From steve@turnbull.sk.tsukuba.ac.jp Wed May 9 23:17:33 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA01736 for ; Wed, 9 May 2001 23:17:29 -0400 Received: by localhost id m14xgop-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 10 May 2001 12:08:47 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.1598.952840.240962@turnbull.sk.tsukuba.ac.jp> Date: Thu, 10 May 2001 12:08:46 +0900 To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.45842.183634.985129@tyranny.hsys.msk.ru> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.45842.183634.985129@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Alexey" == Alexey Mahotkin writes: Alexey> Just for clarity: there is no "iso-to-koi" translation Alexey> here and no concept of "Latin-2 buffer". Whether there is an "iso-to-koi" translation is a matter of interpretation. In particular, I was thinking of an alternative implementation, leaving the guts of x_keysym_to_character untouched, and applying a translation to the "canonical" iso 8859/5 in a hook called at the end of that function. I now see that's a bad idea, but that's why I talk about such a translation. There may not currently be an official concept of "Latin-2 buffer" in no-mule, but Hrvoje has outlined some hacks that would make it possible at the Lisp level. It is important that we not eliminate that possibility in the process of making use of koi8-r fonts possible, robust, and convenient for users of Cyrillic. Alexey> We just need to implement various translations between Alexey> Cyrillic_XXX and those one-byte encodings. "We Cyrillic users," yes. "We XEmacs maintainers" have to be more careful. We've already been through this with Japanese. Mule XEmacs has had all kinds of trouble with Japanese-specific hacks and "standard conformant" implementations that somehow only work well for Japanese. I want to avoid that kind of problem with this Cyrillic support. If you want to start coding, that's fine. I'm just telling you about the kinds of problems with "straightforward" coding to deal with locale-specific problems that we've had in the past, and that I want to avoid them this time around. If your code doesn't address those issues, it will take longer to get integrated. SJT> It's that XEmacs developers have never done anything about SJT> using the facilities provided by Mule to handle fonts that SJT> have different encoding from internal. Alexey> Huh? What about ccl-programs? The point is that they mostly don't exist, and the ones that do aren't very good -- they were written by CCL programmers, not by people who know the languages. CCL is badly documented -- I should know, I compiled most of what's available outside of comments in the source. So it's hard for people who know what the users need to write CCL. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From youngs@xemacs.org Wed May 9 23:40:25 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA03019 for ; Wed, 9 May 2001 23:40:23 -0400 Received: from slackware.mynet.pc (wdcax13-136.dialup.optusnet.com.au [198.142.220.136]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4A3eIl28363 for ; Thu, 10 May 2001 13:40:18 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4A3aeg8026970; Thu, 10 May 2001 13:36:40 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Updated Packages in Pre-Releases - May 10 From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 10 May 2001 13:36:40 +1000 Message-ID: Lines: 156 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I've just uploaded the following updated packages to the 'Pre-Releases' directory: egg-its-1.26-pkg.tar.gz ======================= 2001-05-07 Yoshiki Hayashi * egg-cwnn-leim.el: chinese-egg-pinyin should call egg-pinyin-activate. * egg.el: Don't override C-\\ when one of leim feature is present. 2001-05-07 Katsumi Yamaoka * egg.el (its:all-completions): Remove too much `if'. pc-1.20-pkg.tar.gz ================== 2000-02-12 Sean MacLennan * pc-select.el The following now use `call-interactively': (pc-select-move|mark-line-up) (pc-select-move|mark-line-down) (pc-select-move|mark-page-up) (pc-select-move|mark-page-down) prog-modes-1.38.tar.gz ====================== 2001-04-11 Barry Warsaw * python-mode.el: Bumping to version 4.0 since we now support only XEmacs 21.1 and Emacs 20.7, although not all of the compatibility code for older Emacsen has been removed. Specifically, the old "make sure we have a current custom.el library" stuff is removed, as is the hack-around for an NTEmacs 19.34.6 make-temp-name bug. Updated much of the Commentary section in the initial comments. Much more importantly, I've integrated Ken Manheimer's pdbtrack stuff, which is way cool. When enabled (as by default), this turns on the overlay arrow when pdb is entered, either in the shell buffer or in the *Python* buffer. Specifically: (py-mode-map): Added C-c C-d to toggle pdb tracking. (py-pdbtrack-do-tracking-p): New user customizable variable to control whether overlay arrow tracking is enabled or not. This variable is buffer local and is turned on by default. (py-pdbtrack-minor-mode-string): The string that's added to the minor mode alist when actually doing pdb overlay arrow tracking. User customizable. (py-pdbtrack-toggle-stack-tracking, turn-on-pdbtrack, turn-off-pdbtrack): New commands to control pdb tracking. (py-pdbtrack-is-tracking-p): Helper variable used to control the display of py-pdbtrack-minor-mode-string. Set to true when the overlay arrow is enabled, and false when it's disabled. (py-pdbtrack-stack-entry-regexp, py-pdbtrack-input-prompt, py-pdbtrack-track-range): Inherited from pdbtrack.el and renamed. (py-pdbtrack-overlay-arrow, py-pdbtrack-track-stack-file): New functions which actually do the tracking. (py-shell): Add py-pdbtrack-track-stack-file to comint-output-filter-functions. Finally, add py-pdbtrack-track-stack-file to comint-output-filter-functions at the file level. This and the py-shell addition should ensure that pdb tracking is installed regardless of the order of operation. Also, add py-pdbtrack-minor-mode-string to minor-mode-alist. 2001-02-24 Barry Warsaw * python-mode.el (py-parse-state): Teach python-mode how to scan code which follows multi-line list comprehensions. 2001-02-20 Barry Warsaw * python-mode.el (py-execute-region): This one's easy... kill the temporary file's buffer after executing its contents. 2000-12-27 Barry Warsaw * python-mode.el (python-font-lock-keywords): Add highlighting of `as' as a keyword, but only in "import foo as bar" statements (including optional preceding `from' clause). 2000-10-27 Barry Warsaw * python-mode.el (py-goto-beginning-of-tqs): When searching backwards for the matching delimiter, watch out for backslash escaped delimiters. Also use = instead of eq for character comparison (because a character is = to it's integer value, but not eq to it). 2000-06-23 Barry Warsaw * python-mode.el (py-execute-region): Make sure the new temporary buffer is current for the insertion of the text. 2000-05-23 Barry Warsaw * python-mode.el (py-execute-region): Based on suggestions by Francois Pinard and Skip Montanaro, handle execution of indented regions by inserting an "if 1:" in front of the block. This better preserves things like triple quoted strings and commented regions. This patch resolves PR#264. Installation Instructions: ========================== Manually: --------- Simply download the files from: ftp.xemacs.org/pub/xemacs/beta/experimental/packages/ And unpack them into: [1] /usr/local/lib/xemacs/xemacs-packages/ Using XEmacs package tools: (XEmacs 21.1.14) --------------------------- 1) Options -> Manage Packages -> Add Download Site -> Pre-Releases 2) Options -> Manage Packages -> List and Install 3) Choose the packages you wish to install (there are brief instructions at the bottom of the '*Packages*' buffer). 4) Packages -> Install/Remove Selected 5) Re-start XEmacs. Using XEmacs package tools: (XEmacs 21.2 and above) --------------------------- 1) Tools -> Packages -> Add Download Site -> Pre-Releases 2) Tools -> Packages -> List and Install 3 - 5) As per 21.1.14 instructions. As always, please let me know how it goes. Enjoy. Footnotes: [1] Note that 'egg-its-1.26-pkg.tar.gz' is a Mule package and therefore should be unpacked into: /usr/local/lib/xemacs/mule-packages/ -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From rendhalver@users.sourceforge.net Thu May 10 01:53:05 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA09943; Thu, 10 May 2001 01:53:02 -0400 Received: from ulthwe.dyndns.org (p492-tnt1.brs.ihug.com.au [203.173.189.238]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id PAA21513; Thu, 10 May 2001 15:52:55 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p492-tnt1.brs.ihug.com.au [203.173.189.238] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15098.11302.47725.672028@ulthwe.dyndns.org> Date: Thu, 10 May 2001 15:50:30 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 10 In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Steve Youngs writes: > I've just uploaded the following updated packages to the > 'Pre-Releases' directory: these all installed without a hitch with xemacs-21.5.1 on my RH 7.0 linux box :) > egg-its-1.26-pkg.tar.gz > ======================= [snip] > pc-1.20-pkg.tar.gz > ================== [snip] > prog-modes-1.38.tar.gz > ====================== [snip] but i had a problem with installing leim-1.17 was trying to install it (first time i have) and i go this error package leim-1.17-pkg.tar.gz does not match md5 checksum any ideas ?? -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From martin@m17n.org Thu May 10 02:58:12 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA17937 for ; Thu, 10 May 2001 02:58:11 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id PAA25425; Thu, 10 May 2001 15:57:51 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id PAA23833; Thu, 10 May 2001 15:57:49 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A6vnm20298; Thu, 10 May 2001 15:57:49 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15098.15341.111749.752653@gargle.gargle.HOWL> Date: Thu, 10 May 2001 15:57:49 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: Hrvoje Niksic , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.11807.418101.695489@tyranny.hsys.msk.ru.> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id CAA17937 This: (global-set-key [(Cyrillic_HARDSIGN)] [ÿ]) I think this makes Cyrillic_hardsign into a keyboard macro, which I don't think is what you want. (define-key [(Cyrillic_hardsign)] 'self-insert-key) (put 'Cyrillic_hardsign 'ascii-character ?ÿ) seems to work. The key-handling code is difficult and in need of a rewrite. There are some design problems that are not so easy to fix. There are already so many layers of key translation, and yet more may be needed (for example, Alexey is working on adding another layer). Of course, the name `ascii-character' is a very bad name for this property. It should be possible to define a key as a character, e.g. (define-key [(Cyrillic_hardsign)] ?ÿ) should be equivalent to (define-key [(Cyrillic_hardsign)] 'self-insert-key) (put 'Cyrillic_hardsign 'ascii-character ?ÿ) since this is obvious meaning. Actually, this is probably the best way to migrate away from that ugly name `ascii-character'. From martin@m17n.org Thu May 10 03:17:04 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA18798 for ; Thu, 10 May 2001 03:16:58 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA25620; Thu, 10 May 2001 16:15:58 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA24002; Thu, 10 May 2001 16:15:57 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A7Fuq20532; Thu, 10 May 2001 16:15:56 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15098.16428.822147.955063@gargle.gargle.HOWL> Date: Thu, 10 May 2001 16:15:56 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: Hrvoje Niksic , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.11807.418101.695489@tyranny.hsys.msk.ru.> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA18798 Oh, Alexey, can't you do everything you need for koi8 without hacking the C code, by doing simply: ;;; koi8.el: (when (not (featurep 'mule)) (keyboard-translate 'Cyrillic_hardsign 'ydiaeresis) ... ) My apologies if this was already considered and rejected. It would be good if the following worked as expected. (keyboard-translate 'Cyrillic_hardsign ?ÿ) but this has different results from the above. From martin@m17n.org Thu May 10 03:21:19 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA18992; Thu, 10 May 2001 03:20:52 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA25719; Thu, 10 May 2001 16:20:47 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA24070; Thu, 10 May 2001 16:20:45 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A7Kjm20549; Thu, 10 May 2001 16:20:45 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.16717.517947.966975@gargle.gargle.HOWL> Date: Thu, 10 May 2001 16:20:45 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Ben Wing Cc: "Stephen J. Turnbull" , Yoshiki Hayashi , xemacs-beta@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el In-Reply-To: <3AF949AB.44B7160E@666.com> References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <3AF9077A.67EC110B@666.com> <15097.10401.480667.869203@turnbull.sk.tsukuba.ac.jp> <3AF949AB.44B7160E@666.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Ben" == Ben Wing writes: I completely agree with Ben about the maintainability issues below. Ben> it has to do with maintainability. much of the stuff in xemacs-base really is Ben> part of the core [e.g. advice.el, comint.el, shell.el, etc.]. much of the core Ben> depends on xemacs-base, and xemacs-base depends on the core, and these two Ben> things are closely tied together. but there's an artificial separation here Ben> that makes it very difficult and cumbersome to make changes in xemacs-base, Ben> since we have to worry about keeping compatibility with old versions of xemacs Ben> and can't use other new core functions in them, etc. the whole purpose of the Ben> package system is to allow independent chunks to be maintained and upgraded Ben> independently, but in this case xemacs-base is *NOT* an independent package Ben> since it's so bound up with the core. any potential gain from being able to Ben> upgrade it independently is far outweighed by the loss caused by the difficulty Ben> in working on its code. From martin@m17n.org Thu May 10 03:28:17 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA19282; Thu, 10 May 2001 03:28:07 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA25817; Thu, 10 May 2001 16:28:06 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA24130; Thu, 10 May 2001 16:28:05 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A7S5u20658; Thu, 10 May 2001 16:28:05 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.17156.930387.593444@gargle.gargle.HOWL> Date: Thu, 10 May 2001 16:28:04 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Colin Rafferty Cc: XEmacs Beta List Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "C" == Colin Rafferty writes: C> Hrvoje Niksic writes: >> But then I remembered that "keysyms" aren't really cast in stone, and >> that with a little trickery you can fake keysyms from Lisp. Here is >> the result: >> (global-set-key '(alt a) [fake-keysym]) >> (global-set-key 'fake-keysym 'self-insert-command) >> (put 'fake-keysym 'ascii-character ?\301) C> Thank you very much Hrvoje. This is exactly what I needed. C> I think I understand key bindings a little but more now. I believe the CANONICAL way to do this is via (global-unset-key [(alt a)]) ;; probably not necessary (define-key function-key-map [(alt a)] [ydiaeresis]) There are so many wonderful ways to define what your keyboard does in xemacs. Combine that with xmodmap, loadkeys, xkb, and you can start your new career as a keyboard-remapping consultant! From yoshiki@xemacs.org Thu May 10 03:33:33 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA19533; Thu, 10 May 2001 03:33:29 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4A7XIE30674; Thu, 10 May 2001 16:33:18 +0900 To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15096.19782.470107.692088@gargle.gargle.HOWL> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 10 May 2001 16:33:18 +0900 In-Reply-To: <15096.19782.470107.692088@gargle.gargle.HOWL> (Alexey Mahotkin's message of "Tue, 8 May 2001 23:47:18 +0400 (MSD)") Message-ID: <87u22tacap.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 30 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Alexey Mahotkin writes: > >>>>> "YH" == Yoshiki Hayashi writes: > > YH> But I can't since mule-diag.el is in the package. XEmacs > YH> 21.1 does not have functions like coding-system-aliasee. > > I've tested this tiny patch to my patch with XEmacs 21.1.10 (those > functions were broken there as horribly too): Thanks! I still have a few comments but it is cleary better than current version in package. Reviewed and approved. Steve, could you apply these two patches? <15093.49523.736978.443168@gargle.gargle.HOWL> http://list-archive.xemacs.org/xemacs-patches/200105/msg00029.html <15096.19782.470107.692088@gargle.gargle.HOWL> http://list-archive.xemacs.org/xemacs-patches/200105/msg00043.html The patched version does not print coding-system aliases with M-x list-coding-systems because (coding-system-get coding-system 'alias-coding-systems) doesn't work on XEmacs. C-u M-x prints subsidiary coding-systems (-unix, -mac, -dos) It should only print base coding-systems. However, these are not big issues since they haven't been working for quite a while. But you are always welcomed to fix them yourself. :-) -- Yoshiki Hayashi From steve@turnbull.sk.tsukuba.ac.jp Thu May 10 03:42:28 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA19884; Thu, 10 May 2001 03:42:27 -0400 Received: by localhost id m14xkx0-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 10 May 2001 16:33:30 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Message-ID: <15098.17482.339312.212450@turnbull.sk.tsukuba.ac.jp> Date: Thu, 10 May 2001 16:33:30 +0900 To: Martin Buchholz Cc: Alexey Mahotkin , Hrvoje Niksic , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15098.15341.111749.752653@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.15341.111749.752653@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA19884 >>>>> "mb" == Martin Buchholz writes: mb> (for example, Alexey is working on adding another layer). ? His proposal seems to just make a layer that is already there (x_keysym_to_character) configurable. (BTW, despite my caution, it seems pretty straightforward at first glance.) Is that what you mean (another "layer of complexity") or am I missing something? mb> It should be possible to define a key as a character, e.g. mb> (define-key [(Cyrillic_hardsign)] ?ÿ) I like this interface. mb> (define-key [(Cyrillic_hardsign)] 'self-insert-key) mb> (put 'Cyrillic_hardsign 'ascii-character ?ÿ) This seems to work with extended (Mule) characters, too. (global-set-key [(f5)] 'self-insert-command) (put 'f5 'ascii-character ?$B;z(B) F5 --| $B;z(B -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From martin@m17n.org Thu May 10 03:58:05 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA20464 for ; Thu, 10 May 2001 03:58:00 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA26225; Thu, 10 May 2001 16:57:33 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA24435; Thu, 10 May 2001 16:57:32 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A7vVY20996; Thu, 10 May 2001 16:57:31 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.18923.713533.136527@gargle.gargle.HOWL> Date: Thu, 10 May 2001 16:57:31 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15097.45842.183634.985129@tyranny.hsys.msk.ru> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.45842.183634.985129@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "A" == Alexey Mahotkin writes: >>>>> "SJT" == Stephen J Turnbull writes: Alexey> In this case first clause should be (it should modify Alexey> cyrillic_koi8_r[] that is stored somewhere in some hashtable Alexey> and used by x_keysym_to_character(): SJT> That's what I wanted to avoid. OK, I see that it's probably SJT> unavoidable in no-mule. And it's probably right to do it inside SJT> that switch (this automatically makes it configurable according SJT> to character set, SJT> so that the iso-to-koi translation does NOT get SJT> applied in the Latin-2 buffer, which would really hinder a SJT> Polish/Russian translator). A> Just for clarity: there is no "iso-to-koi" translation here and no A> concept of "Latin-2 buffer". I speak of non-Mule, and there is only A> one-to-one translation between internal representation (single byte), A> font encoding and external representation (bytes in files). It is A> very common kind of setup AFAIK. A> We just need to implement various translations between Cyrillic_XXX A> and those one-byte encodings. This model of computing is a very common one in the world of character sets smaller than 128. It's a very "low-tech" way of achieving a multi-lingual editor. The original developers of Multilingualization in Emacs targetted Japanese, for which the hack of using the 128-256 range of character codes doesn't work. So the low-tech way is not supported as well as it could be. But it's also so simple not much support is needed. You can have a function that sets the font for a default face for a buffer by using specifiers with (set-face-font 'default "*koi8" (current-buffer)) This allows you to implement the command (defun toggle-cyrillic-mode (&optional buffer) (interactive) ...) this technique, combined with the keyboard-translate or function-key-map mechanisms (and xmodmap, of course), allows you to have a complete russian (or ukranian, or hungarian, etc.) environment with very little lisp hacking. Mule does give you some extra benefits, but there's a price to pay. From alexm@hsys.msk.ru Thu May 10 04:02:29 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA20880 for ; Thu, 10 May 2001 04:02:24 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.5) with ESMTP id 7811894 for xemacs-beta@xemacs.org; Thu, 10 May 2001 05:02:12 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp139-115.dialup.mtu-net.ru [62.118.139.115]) by mtu.ru (Postfix) with ESMTP id D4ABF7342 for ; Thu, 10 May 2001 12:02:16 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 1879 invoked by uid 1000); 10 May 2001 07:44:44 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.18156.526293.520167@tyranny.hsys.msk.ru> Date: Thu, 10 May 2001 11:44:44 +0400 (MSD) To: Yoshiki Hayashi Cc: xemacs-beta@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el In-Reply-To: <87u22tacap.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15096.19782.470107.692088@gargle.gargle.HOWL> <87u22tacap.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "YH" == Yoshiki Hayashi writes: YH> C-u M-x prints YH> subsidiary coding-systems (-unix, -mac, -dos) It should only print YH> base coding-systems. I intently did it that way because print-coding-system reports EOL field. So there is no sense to ignore EOL variations. Thanks, --alexm From alexm@hsys.msk.ru Thu May 10 04:15:06 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA21496 for ; Thu, 10 May 2001 04:15:01 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-132.dialup.mtu-net.ru [62.118.131.132]) by mtu.ru (Postfix) with ESMTP id 9AA34738D for ; Thu, 10 May 2001 12:14:59 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 2011 invoked by uid 1000); 10 May 2001 08:03:54 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.19306.555103.11565@tyranny.hsys.msk.ru> Date: Thu, 10 May 2001 12:03:54 +0400 (MSD) To: Martin Buchholz Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15098.16428.822147.955063@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.16428.822147.955063@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "MB" == Martin Buchholz writes: MB> Oh, Alexey, can't you do everything you need for koi8 without MB> hacking the C code, by doing simply: MB> ;;; koi8.el: (when (not (featurep 'mule)) (keyboard-translate MB> 'Cyrillic_hardsign 'ydiaeresis) ... ) I want to switch by whole arrays. First reason: there is already code `x_keysym_to_character' that works but just needs a clean well-defined hack to solve single simple problem (Stephen, I consider your concerns about overcyrillization). Second reason, more practical about why I want to deal with arrays: suppose we're setting cp1251 encoding for Cyrillic characters. We have (defun set-cyrillic-cp1251-encoding (set-keysym-translation 'Cyrillic_HARDSIGN ?\xDA) (set-keysym-translation 'Cyrillic_DZHE ?\0x8F)) After that we want to switch to koi8-r. We have: (defun set-cyrillic-koi8-r-encoding (set-keysym-translation 'Cyrillic_HARDSIGN ?\xFF) ;; because koi8-r does not have DZHE (set-keysym-translation 'Cyrillic_DZHE nil)) That is, we have to explicitly unset every keysym that could be supported by some other encoding and could not be supported by the encoding we're trying to set. This is very tedious IMHO and is better handled by char *cyrillic = cyrillic_koi8_r; MB> My apologies if this was already considered and rejected. --alexm From alexm@hsys.msk.ru Thu May 10 04:15:40 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA21526 for ; Thu, 10 May 2001 04:15:39 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-132.dialup.mtu-net.ru [62.118.131.132]) by mtu.ru (Postfix) with ESMTP id 51F787369 for ; Thu, 10 May 2001 12:15:18 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 2021 invoked by uid 1000); 10 May 2001 08:04:45 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-ID: <15098.19357.630396.11614@tyranny.hsys.msk.ru> Date: Thu, 10 May 2001 12:04:45 +0400 (MSD) To: Martin Buchholz Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15098.16428.822147.955063@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.16428.822147.955063@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "MB" == Martin Buchholz writes: MB> It would be good if the following worked as expected. MB> (keyboard-translate 'Cyrillic_hardsign ?ÿ) (fixing obvious case typo here) MB> but this has different results from the above. Oh oh oh. TIMTOWTDI =) Results of testing this: 21.1.10 says: "last typed character has no ASCII equivalent: #" 21.4.1 just does not produce any letter after typing HARDSIGN. --alexm From alexm@hsys.msk.ru Thu May 10 04:15:53 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA21539 for ; Thu, 10 May 2001 04:15:43 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.5) with ESMTP id 7812453 for xemacs-beta@xemacs.org; Thu, 10 May 2001 05:15:35 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-132.dialup.mtu-net.ru [62.118.131.132]) by mtu.ru (Postfix) with ESMTP id 156667370 for ; Thu, 10 May 2001 12:15:41 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 2037 invoked by uid 1000); 10 May 2001 08:13:43 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.19895.242941.648569@tyranny.hsys.msk.ru> Date: Thu, 10 May 2001 12:13:43 +0400 (MSD) To: Martin Buchholz Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15098.18923.713533.136527@gargle.gargle.HOWL> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.45842.183634.985129@tyranny.hsys.msk.ru> <15098.18923.713533.136527@gargle.gargle.HOWL> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid >>>>> "MB" == Martin Buchholz writes: MB> This model of computing is a very common one in the world of MB> character sets smaller than 128. MB> It's a very "low-tech" way of achieving a multi-lingual editor. That's exactly what we need. High-tech is already implemented and is called Mule :) MB> You can have a function that sets the font for a default face for MB> a buffer by using specifiers with MB> (set-face-font 'default "*koi8" (current-buffer)) That won't work because your buffer will have one-byte characters in 8859-5, and there is no way in non-Mule to have different font encoding and characters encoding. Moreover, your files will be in 8859-5 encoding. Moreover, you could not open koi8-r file and edit it. Same shi^Wthing happens for some other languages I'm said (AFAIK, Czech have five commonly-used one-byte encodings, that's why Russian Apache is so popular there). MB> This allows you to implement the command MB> (defun toggle-cyrillic-mode (&optional buffer) (interactive) ...) MB> this technique, combined with the keyboard-translate or MB> function-key-map mechanisms (and xmodmap, of course), allows you MB> to have a complete russian (or ukranian, or hungarian, etc.) MB> environment with very little lisp hacking. I just want to reuse code that's already there. Your code :) --alexm From martin@m17n.org Thu May 10 05:04:12 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA23302 for ; Thu, 10 May 2001 05:03:58 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id RAA26879; Thu, 10 May 2001 17:55:07 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id RAA24912; Thu, 10 May 2001 17:55:05 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A8t5U21705; Thu, 10 May 2001 17:55:05 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.22377.528604.801072@gargle.gargle.HOWL> Date: Thu, 10 May 2001 17:55:05 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15098.19895.242941.648569@tyranny.hsys.msk.ru> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.45842.183634.985129@tyranny.hsys.msk.ru> <15098.18923.713533.136527@gargle.gargle.HOWL> <15098.19895.242941.648569@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "A" == Alexey Mahotkin writes: >>>>> "MB" == Martin Buchholz writes: MB> This model of computing is a very common one in the world of MB> character sets smaller than 128. MB> It's a very "low-tech" way of achieving a multi-lingual editor. A> That's exactly what we need. High-tech is already implemented and is A> called Mule :) MB> You can have a function that sets the font for a default face for MB> a buffer by using specifiers with MB> (set-face-font 'default "*koi8" (current-buffer)) A> That won't work because your buffer will have one-byte characters in A> 8859-5, and there is no way in non-Mule to have different font A> encoding and characters encoding. Moreover, your files will be in A> 8859-5 encoding. Moreover, you could not open koi8-r file and edit A> it. I mean that you would combine the set-face-font above with some method (explained in other messages) that would allows input to map keysyms to their koi8 code instead of their iso8859-5 code. A> Same shi^Wthing happens for some other languages I'm said (AFAIK, A> Czech have five commonly-used one-byte encodings, that's why Russian A> Apache is so popular there). Interesting. MB> This allows you to implement the command MB> (defun toggle-cyrillic-mode (&optional buffer) (interactive) ...) MB> this technique, combined with the keyboard-translate or MB> function-key-map mechanisms (and xmodmap, of course), allows you MB> to have a complete russian (or ukranian, or hungarian, etc.) MB> environment with very little lisp hacking. A> I just want to reuse code that's already there. Your code :) Although the key hacking code in C should be rewritten, there's enough functionality available to the lisp programmer that what you want can and should be implemented in lisp today. A .el file is much more shareable than a patch to the C code, that would require a potential user to rebuild their xemacs binary. From hniksic@arsdigita.com Thu May 10 05:18:52 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA23803; Thu, 10 May 2001 05:18:52 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xmaL-0001wl-00; Thu, 10 May 2001 11:18:13 +0200 Sender: hniksic@florida.arsdigita.de To: "Stephen J. Turnbull" Cc: Martin Buchholz , Alexey Mahotkin , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.15341.111749.752653@gargle.gargle.HOWL> <15098.17482.339312.212450@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 10 May 2001 11:18:13 +0200 In-Reply-To: <15098.17482.339312.212450@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Thu, 10 May 2001 16:33:30 +0900") Message-ID: Lines: 11 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA23803 "Stephen J. Turnbull" writes: > mb> It should be possible to define a key as a character, e.g. > > mb> (define-key [(Cyrillic_hardsign)] ?ÿ) > > I like this interface. I'm not so sure about it. What if ÿ itself is bound to something other than self-insert-command? Do we still insert ÿ, or do we call that other command? From martin@m17n.org Thu May 10 05:21:46 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA23952 for ; Thu, 10 May 2001 05:21:40 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id SAA27101; Thu, 10 May 2001 18:21:02 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id SAA25078; Thu, 10 May 2001 18:21:00 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A9L0r22159; Thu, 10 May 2001 18:21:00 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.23932.547155.839867@gargle.gargle.HOWL> Date: Thu, 10 May 2001 18:21:00 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: <15098.19306.555103.11565@tyranny.hsys.msk.ru> References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.16428.822147.955063@gargle.gargle.HOWL> <15098.19306.555103.11565@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "A" == Alexey Mahotkin writes: >>>>> "MB" == Martin Buchholz writes: MB> Oh, Alexey, can't you do everything you need for koi8 without MB> hacking the C code, by doing simply: MB> ;;; koi8.el: (when (not (featurep 'mule)) (keyboard-translate MB> 'Cyrillic_hardsign 'ydiaeresis) ... ) A> I want to switch by whole arrays. A> First reason: there is already code `x_keysym_to_character' that works A> but just needs a clean well-defined hack to solve single simple A> problem (Stephen, I consider your concerns about overcyrillization). It would be easy to add some hack to allow the user to specify the translation from keysym to equivalent character in event-Xt.c. This can be implemented internally using a hash table. But I'm not all sure that doing this is a good idea, since it adds Yet Another Key Mapping Mechanism, when we already have so many. And I don't understand why the ones we have (specifically, function-key-map) don't do exactly what you want. You have to maintain a mapping table from keysyms to koi8 character codes in any case. Isn't it easier to have it in lisp code than C code? A> Second reason, more practical about why I want to deal with arrays: A> suppose we're setting cp1251 encoding for Cyrillic characters. We A> have A> (defun set-cyrillic-cp1251-encoding A> (set-keysym-translation 'Cyrillic_HARDSIGN ?\xDA) A> (set-keysym-translation 'Cyrillic_DZHE ?\0x8F)) A> After that we want to switch to koi8-r. We have: A> (defun set-cyrillic-koi8-r-encoding A> (set-keysym-translation 'Cyrillic_HARDSIGN ?\xFF) A> ;; because koi8-r does not have DZHE A> (set-keysym-translation 'Cyrillic_DZHE nil)) A> That is, we have to explicitly unset every keysym that could be A> supported by some other encoding and could not be supported by the A> encoding we're trying to set. This is very tedious IMHO and is better A> handled by A> char *cyrillic = cyrillic_koi8_r; I disagree about "tedious". The information about keysyms which should be mapped to nil has to be maintained in any case, so there is just as much code to maintain. And I don't think humans will notice the time taken by the computer to do the remappings. I disagree that we should have a specific C-level mechanism for koi8. The C code you are hacking in event-Xt.c is a fallback of last resort. It could actually have been implemented by simply populating global-map, but doing it in C the way we did was a small optimization of space and startup time, and reduces user confusion by not having global-map cluttered with key bindings for keys the user doesn't have. From hniksic@arsdigita.com Thu May 10 05:27:45 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA24326 for ; Thu, 10 May 2001 05:27:44 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xmjY-0001yq-00 for ; Thu, 10 May 2001 11:27:44 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15098.17156.930387.593444@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 10 May 2001 11:27:43 +0200 In-Reply-To: <15098.17156.930387.593444@gargle.gargle.HOWL> (Martin Buchholz's message of "Thu, 10 May 2001 16:28:04 +0900") Message-ID: Lines: 19 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Martin Buchholz writes: > I believe the CANONICAL way to do this is via > > (global-unset-key [(alt a)]) ;; probably not necessary > (define-key function-key-map [(alt a)] [ydiaeresis]) Is that canonical in the canonical sense of the word? :-) Seriously, I don't have a clue about Latin 1 keysyms so I don't grok "ydiaeresis". I do know, however, that my solution will work for all characters, Croatian, Japanese, Chinese, etc. That makes it preferrable or, if you want, canonical. > There are so many wonderful ways to define what your keyboard does > in xemacs. Combine that with xmodmap, loadkeys, xkb, and you can > start your new career as a keyboard-remapping consultant! This reminds me of Dave's "X Keyboard Model Madness" rant. From hniksic@arsdigita.com Thu May 10 05:30:50 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA24523 for ; Thu, 10 May 2001 05:30:50 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xmmW-0001zf-00 for ; Thu, 10 May 2001 11:30:48 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.45842.183634.985129@tyranny.hsys.msk.ru> <15098.18923.713533.136527@gargle.gargle.HOWL> <15098.19895.242941.648569@tyranny.hsys.msk.ru> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 10 May 2001 11:30:48 +0200 In-Reply-To: <15098.19895.242941.648569@tyranny.hsys.msk.ru> (Alexey Mahotkin's message of "Thu, 10 May 2001 12:13:43 +0400 (MSD)") Message-ID: Lines: 9 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > Same shi^Wthing happens for some other languages I'm said (AFAIK, > Czech have five commonly-used one-byte encodings, that's why Russian > Apache is so popular there). In Croatia we're fighting against Microsoft and inertia to replace windows-1250 and 7-bit CROSCII with ISO 8859-2. Given the strength of our opponents, we've been doing pretty well. :-) From martin@m17n.org Thu May 10 05:38:36 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA24839 for ; Thu, 10 May 2001 05:38:35 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id SAA27198; Thu, 10 May 2001 18:38:19 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id SAA25119; Thu, 10 May 2001 18:38:18 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4A9cHp22576; Thu, 10 May 2001 18:38:17 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15098.24969.856318.156455@gargle.gargle.HOWL> Date: Thu, 10 May 2001 18:38:17 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Hrvoje Niksic Cc: "Stephen J. Turnbull" , Alexey Mahotkin , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.15341.111749.752653@gargle.gargle.HOWL> <15098.17482.339312.212450@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA24839 >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> "Stephen J. Turnbull" writes: mb> It should be possible to define a key as a character, e.g. >> mb> (define-key [(Cyrillic_hardsign)] ?ÿ) >> >> I like this interface. Hrvoje> I'm not so sure about it. What if ÿ itself is bound to something Hrvoje> other than self-insert-command? Do we still insert ÿ, or do we call Hrvoje> that other command? Historical note: keystrokes and characters have been confused, since they are somewhat indistinguishable on a tty. The default (fallback) binding of a character should be self-insert-key (except without the need to hack the ascii-character property). This should be overridable by the user, both to change the global fallback binding and to change a binding for a particular character. You need to be careful to make this work with isearch. Of course, lots more thinking should be done before anyone starts hacking on this. From steve@turnbull.sk.tsukuba.ac.jp Thu May 10 06:40:16 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA27063; Thu, 10 May 2001 06:40:14 -0400 Received: by localhost id m14xnjI-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 10 May 2001 19:31:32 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15098.28146.935516.713089@turnbull.sk.tsukuba.ac.jp> Date: Thu, 10 May 2001 19:31:14 +0900 To: Hrvoje Niksic Cc: Martin Buchholz , Alexey Mahotkin , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-Reply-To: References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.11807.418101.695489@tyranny.hsys.msk.ru.> <15098.15341.111749.752653@gargle.gargle.HOWL> <15098.17482.339312.212450@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id GAA27063 >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> "Stephen J. Turnbull" writes: mb> It should be possible to define a key as a character, e.g. mb> (define-key [(Cyrillic_hardsign)] ?ÿ) >> I like this interface. Hrvoje> I'm not so sure about it. What if ÿ itself is bound to Hrvoje> something other than self-insert-command? Do we still Hrvoje> insert ÿ, or do we call that other command? I would say define as self-insert. To get the definition of ÿ, we already have the form (define-key global-map [(Cyrillic_hardsign)] (cons global-map ?ÿ)). which makes it clear what we're doing in that case. Your interpretation is plausible, so someone who hasn't RTFM'd might get a little confused. It's also maybe a little confusing since many insert commands take strings or characters and "do the right thing", whereas here strings and characters would have very different interpretations (keyboard macro and self-insert, respectively). But I still like it. :-) >>>> "mb" == Martin Buchholz writes: mb> Historical note: keystrokes and characters have been confused, mb> since they are somewhat indistinguishable on a tty. mb> The default (fallback) binding of a character should be mb> self-insert-key (except without the need to hack the mb> ascii-character property). ?? Does this have specifically to do with the define-key thread, or are we now talking about the master plan to revamp the keyboard code? In the context of define-key, I see no reason for such complexity. We just decide what we want an object of character type to mean when presented to define-key as the DEF arg. No need for fallbacks, defaults, user configuration or anything. Right? You can have them if you want, but IMHO they'd be really confusing. It would be very straightforward to implement your original two-line proposal as a defadvice of define-key, right? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From awn@bcs1.bcs.zp.ua Thu May 10 07:54:02 2001 Received: from relay1.bcs.zp.ua (bcs-marka.marka.net.ua [217.24.161.217]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA29905 for ; Thu, 10 May 2001 07:53:55 -0400 Received: from relay2.bcs.zp.ua (bcs3.bcs.zp.ua [212.8.35.73]) by relay1.bcs.zp.ua (8.11.0/8.11.0) with ESMTP id f4ABrag46349 for ; Thu, 10 May 2001 14:53:37 +0300 (EEST) Received: from bcs1.bcs.zp.ua (root@bcs1.bcs.zp.ua [212.8.35.34]) by relay2.bcs.zp.ua (8.11.3/8.11.3) with ESMTP id f4ABrTh14127 for ; Thu, 10 May 2001 14:53:29 +0300 (EEST) (envelope-from awn@bcs1.bcs.zp.ua) Received: (from awn@localhost) by bcs1.bcs.zp.ua (8.9.3/8.9.3) id OAA18108 for xemacs-beta@xemacs.org; Thu, 10 May 2001 14:53:34 +0300 Date: Thu, 10 May 2001 14:53:34 +0300 From: "Andrew W. Nosenko" To: xemacs-beta@xemacs.org Subject: Very strange! [Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs] Message-ID: <20010510145334.A17725@bcs.zp.ua> Mail-Followup-To: "Andrew W. Nosenko" , xemacs-beta@xemacs.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15097.11807.418101.695489@tyranny.hsys.msk.ru.> User-Agent: Mutt/1.3.18i Alexey Mahotkin wrote: : >>>>> "Hrvoje" == Hrvoje Niksic writes: : : Hrvoje> I made two mistakes: I misnamed the property, and my `put' : Hrvoje> line contains a case mismatch. It should be: : : Hrvoje> (global-set-key 'Cyrillic_HARDSIGN 'self-insert-command) : Hrvoje> (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) : : Hrvoje> 21.1 should respect that. : : It does. isearch works. Strange... For non-mule 21.1 isearch should not work! (I speak about case-insensitive searches). Changes what made case-insensitive isearches work for non-ascii (or non-latin-1?) characters was made later and included in 21.4. : : Hrvoje> If 21.4 doesn't, it's a bug. : : 21.4.1 doesn't. It keeps inserting ISO8859-5 code for HARDSIGN : (0xca). I could test any patches for that matter. Very strange!!! For non-mule 21.4 it work. With isearch. (Or cyrillic letters in my 21.4.1 exist only in my mind? ;-) Alexey: if you interesting in this, I can send to you my ru-keys.el, what do all need settings for koi8-r. -- Andrew W. Nosenko (awn@bcs.zp.ua) From rendhalver@users.sourceforge.net Thu May 10 09:34:27 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA01991 for ; Thu, 10 May 2001 09:34:25 -0400 Received: from ulthwe.dyndns.org (p242-tnt1.brs.ihug.com.au [203.173.188.242]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id XAA16307 for ; Thu, 10 May 2001 23:34:19 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p242-tnt1.brs.ihug.com.au [203.173.188.242] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15098.38986.624931.622596@ulthwe.dyndns.org> Date: Thu, 10 May 2001 23:31:54 +1000 To: xemacs-beta@xemacs.org Subject: problem with loading pces-xm in 21.5.1 X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII hi all got a problem with xemacs beta my init file works fine with 21.4 but 21.5.1 complains about not being able to load pces-xm could it be a mule thing my 21.4 instalation doesnt have mule and ive got a separate packages tree (from experimental) for beta version all packages for beta are current um i had problems installing leim could that be it ?? my init.el file is almost the same as the sample one plus a couple of included files for vm customisation let me know if you need it my instalation details and output from -debug-init are below -debug-init output Signaling: (file-error "Cannot open load file" "pces-xm") signal(file-error ("Cannot open load file" "pces-xm")) load("pces-xm" nil t nil) si:require(pces-xm nil) require(pces-xm) byte-code("..." [product find-coding-system raw-text-dos copy-coding-system no-conversion-dos raw-text-mac no-conversion-mac raw-text-unix no-conversion-unix featurep mule require pces-xm pces-20 apel-ver put provide pces-xfc product-find-by-name "APEL" product-run-checkers (10 2) product-add-feature product-version vector nil] 12) load-internal("pces-xfc" nil t nil binary) load("pces-xfc" nil t nil) si:require(pces-xfc nil) require(pces-xfc) byte-code("..." [emacs-major-version product require poe fboundp open-network-stream tcp featurep xemacs file-coding pces-xfc pces-raw mule 20 pces-e20 pces-om boundp NEMACS pces-nemacs apel-ver put provide pces product-find-by-name "APEL" product-run-checkers (10 2) product-add-feature product-version vector nil] 12) load-internal("pces" nil t nil binary) load("pces" nil t nil) si:require(pces nil) require(pces) byte-code("..." [emacs-major-version product current-load-list require pces featurep mule xemacs poem-xm 20 poem-e20 poem-om boundp NEMACS poem-nemacs poem-ltn1 fboundp string-as-unibyte # byte-optimizer (nil byte-compile-inline-expand) error "%s already has a byte-optimizer, can't make it inline" put byte-compile-inline-expand defsubst-maybe t string-as-multibyte # charset-after # defun-maybe char-octet # apel-ver provide poem product-find-by-name "APEL" product-run-checkers (10 2) product-add-feature product-version vector nil] 12) load-internal("poem" nil t nil binary) load("poem" nil t nil) si:require(poem nil) require(poem) byte-code("..." [mouse-button-3 mouse-button-2 mouse-button-1 emacs-major-version running-xemacs current-load-list require poe running-emacs-18 boundp 18 featurep xemacs running-mule-merged-emacs MULE mule running-xemacs-with-mule running-emacs-19 19 running-emacs-19_29-or-later 29 20 running-xemacs-19 running-xemacs-20-or-later running-xemacs-19_14-or-later 14 button1 button2 button3 [mouse-1] [mouse-2] [down-mouse-3] nil fboundp tl:make-overlay defalias make-overlay make-obsolete tl:overlay-put overlay-put tl:overlay-buffer overlay-buffer poem mcharset invisible emacs-minor-version] 3) load-internal("emu" nil t nil binary) load("emu" nil t nil) require(emu) byte-code("..." [require emu tl-str autoload add-path "file-detect" get-latest-path file-installed-p] 3) load-internal("tl-misc" nil t nil binary) load("tl-misc" nil t nil) require(tl-misc) byte-code("..." [require tl-misc call-after-loaded tm-view #] 3) load-internal("tm-setup" nil t nil binary) load("tm-setup" nil t nil) require(tm-setup) load-internal("mime-setup" nil nil nil binary) load("mime-setup") load-internal("vm-conf" nil nil nil undecided) load("vm-conf") load-library("vm-conf") load-internal("/home/rendhalver/.xemacs/init.el" t t t undecided) load("/home/rendhalver/.xemacs/init.el" t t t) load-user-init-file() load-init-file() command-line() normal-top-level() --end -debug-init --Instalation---- uname -a: Linux ulthwe.dyndns.org 2.2.17-14 #1 Mon Feb 5 16:02:20 EST 2001 i686 unknown configure '--with-mule' '--prefix=/usr/local/xemacs-beta' '--with-prefix' '--srcdir=/Hacking/src/xemacs/xemacs-21.5' XEmacs 21.5-b1 "anise" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /Hacking/src/xemacs/xemacs-21.5 Installation prefix: /usr/local/xemacs-beta Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: pgsql/libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- --end Instalation---- From hniksic@arsdigita.com Thu May 10 09:55:53 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA02939 for ; Thu, 10 May 2001 09:55:53 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14xqv2-0002sA-00 for ; Thu, 10 May 2001 15:55:52 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: [BUG] Font-lock refuses to turn on in some buffers X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 10 May 2001 15:55:52 +0200 Message-ID: Lines: 38 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii XEmacs font-lock has a "feature" where it refuses to start in buffers whose name begins with SPC. The idea begind the feature is to prevent accidental fontification of various temporary buffers. As accidental fontification goes, the argument stands. But I consider it really evil that it refuses to work even when turned on *explicitly*, and the same even when its own code turns it on. Here is a weird bug I've been seeing: Gnus tries to fontify part of the buffer by effectively doing the following: (insert (with-temp-buffer (funcall desired-major-mode) (font-lock-fontify-buffer) ... some code that forces all text-prop extents to be duplicable ... (buffer-string))) This works, but leaves everything except strings and comments unfontified. This bug had me baffled for a long time, because all my attempts to repeat it in "laboratory conditions" failed. Finally I tracked down the problem to this: font-lock-fontify-buffer temporarily sets font-lock-mode because some of its magic depends on font-lock-mode being on. But since the buffer name begins with SPC, font-lock-mode silently (which is evil!) refuses to turn itself on, and fontification fails in a random way. I think the optimization should be changed to only affect turning on font-lock with font-lock-auto-fontify and friends. If somebody explicitly turns on font-lock, either through `font-lock-fontify-buffer' or otherwise, it has to just work, regardless of what the buffer happens to be named! If that is for whatever reason undesirable, we should at least implement a `force' argument for font-lock-mode which you can call and be sure that font-lock will be used. From Valdis.Kletnieks@vt.edu Thu May 10 10:33:22 2001 Received: from foo-bar-baz.cc.vt.edu (foo-bar-baz.cc.vt.edu [128.173.14.103]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA05646; Thu, 10 May 2001 10:33:19 -0400 From: Valdis.Kletnieks@vt.edu Received: from foo-bar-baz.cc.vt.edu (valdis@localhost.localdomain [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.11.2/8.11.2) with ESMTP id f4AEVYr22638; Thu, 10 May 2001 10:31:34 -0400 Message-Id: <200105101431.f4AEVYr22638@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4+dev To: Alexey Mahotkin cc: Martin Buchholz , xemacs-beta@xemacs.org Subject: Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs In-reply-to: Your message of "Thu, 10 May 2001 12:04:45 +0400." <15098.19357.630396.11614@tyranny.hsys.msk.ru> X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <15097.8052.613253.195665@gargle.gargle.HOWL> <"15097.11807.418101.695489"@tyranny.hsys.msk.ru> <15098.16428.822147.955063@gargle.gargle.HOWL> <15098.19357.630396.11614@tyranny.hsys.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 10 May 2001 10:31:33 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id KAA05646 On Thu, 10 May 2001 12:04:45 +0400, Alexey Mahotkin said: > Oh oh oh. TIMTOWTDI =) Huh? ;) From xemacs-announce-admin@xemacs.org Thu May 10 11:22:06 2001 Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA09077; Thu, 10 May 2001 11:22:05 -0400 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14xs8g-0002sW-00; Thu, 10 May 2001 08:14:02 -0700 Received: from boudicca.tux.org ([209.50.235.253]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14xs7l-0002g9-00 for ; Thu, 10 May 2001 08:13:05 -0700 Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) by boudicca.tux.org (8.9.3/8.9.1) with ESMTP id LAA03083 for ; Thu, 10 May 2001 11:13:03 -0400 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA08441 for ; Thu, 10 May 2001 11:12:57 -0400 Received: by localhost id m14xrzd-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 11 May 2001 00:04:41 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15098.44553.175264.5933@turnbull.sk.tsukuba.ac.jp> Date: Fri, 11 May 2001 00:04:41 +0900 From: "Stephen Turnbull, XEmacs 21.4 Release Manager" To: xemacs-announce@xemacs.org Subject: XEmacs 21.4.2 "Developer-Friendly Unix APIs" is released. X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Sender: xemacs-announce-admin@xemacs.org Errors-To: xemacs-announce-admin@xemacs.org X-BeenThere: xemacs-announce@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Announcements List-Unsubscribe: , * XEmacs 21.4.2 "Developer-Friendly Unix APIs" is released. "Developer-Friendly Unix APIs" is the second in the OXYMORON series. Relative to XEmacs 21.4.1 "Copyleft", it contains a few typo fixes in the documentation and some fixes to critical bugs (including a nasty hang in menus on the Windows platform). More detailed information about the changes is presented below. The first release in this series, Xemacs 21.4.0 "Solid Vapor", contained a large number of improvements and extensions to the current stable version, XEmacs 21.1.14. For more information about the OXYMORON series, see etc/NEWS, the initial release announcement http://www.xemacs.org/Releases/21.4.0.html and the release planning page, http://www.xemacs.org/Releases/Public-21.2/. For general information about XEmacs, the developers, and the user community, see our home page, http://www.xemacs.org/. * XEmacs 21.4.2 is "gamma" software. Besides the usual "no warranty" disclaimer (see etc/WARRANTY, sections 10 and 11), we are now experimenting with a level of stability intermediate between "beta" and "stable", dubbed "gamma". At this point all the developers and most of our beta testers trust the 21.4 code base with all their editing needs. However, for several reasons, for users who absolutely must minimize risk, we continue to recommend the 21.1 series. Nevertheless, almost all users will get very high reliability from XEmacs 21.4, and in return, access to many new features and improved functionality. No new destabilizing code will be added; each release in the 21.4 series should be strictly more stable and bug-free than the preceding one. We also recommend the 21.4 series to distribution packagers (such as Linux distributions and the open source BSD "ports" or "packages" maintainers) for their "testing" and "development" distributions. * Changes included in XEmacs 21.4.2 "Developer-Friendly Unix APIs" User-visible behavior changes are flagged with (**). The first two rarely manifest, the other three are feature additions to platforms whose support is still maturing. (Critical bug fixes are not flagged, since you'll be too busy continuing to work to notice the change.) - (**) Stop shifted motion from making active region persist if no motion. - (**) kill-line reverts to same behavior interactively or not. - (**) MS Windows: Printer support now (optionally) adds headers/footers. - (**) MS Windows: Critical-quit works. - (**) GTK: Face editor changes can apply to GTK too. - Fix hang in Customize menu on Windows platforms. - Fix crash with xlc -O3 on AIX. - make-charset handles short-name correctly. - Trivial sign-compare warning fix. - MS Windows: nt/*.mak version string fix and assorted build cleanups. - GCC 3.0 link error from cruft fixed. - make-stds.info builds again with makeinfo 1.68 - Remove CVS keywords from build-report.el. - Miscellaneous documentation fixes. - Add photos, update descriptions in about.el. - Update copyright notice on splash screen. - FTP mirror site updates Thanks to Adrian Aichner, Martin Buchholz, Karl Hegbloom, Yoshiaki Kasahara, Jason Mastaler, Hrvoje Niksic, Andy Piper, and Ben Wing for patches. And thanks to the Fates, I had time for a one-liner. * Getting XEmacs 21.4.2 XEmacs 21.4.2 is available in source form, including pre-compiled "core" Lisp libraries and pre-built Info files, from ftp.xemacs.org and mirrors (http://www.xemacs.org/Download/index.html#mirror_index). See http://www.xemacs.org/Download/ for general information about downloading XEmacs. For those wedded to their old command-line FTP client, the following URLs may be useful: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4/xemacs-21.4.2.tar.gz or build the Lisp and Info from source, saving download time, with ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4/xemacs-21.4.2-src.tar.gz In either case, you need the "packaged Lisp" for more than the most basic functionality. You may use packages previously installed for use with XEmacs 21.1 or later without change. For new installations, the "SUMO" distribution of (almost) all packaged Lisp is available as ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz The latter should be installed only if you are building XEmacs with the MULE multilingual support; it contains Lisp files that cannot be correctly loaded by a unibyte XEmacs. See README.packages. XEmacs 21.4.2 is also available via anonymous CVS. To get the latest in the 21.4 series, check out (or update) with the "release-21-4" tag. This should be sufficient for almost all users; from now on patches will be carefully screened to ensure that every release is more stable than the last. If for some reason you specifically want this release, use the "r21-4-2" tag. See http://cvs.xemacs.org/ for general instructions on getting XEmacs via anonymous CVS. Binary kits are not planned at this time, except for selected releases for the MS Windows platform. Setups based on the Cygwin "netinstaller", Wise installer, and Installshield are in various degrees of readiness. The adventurous can subscribe to the xemacs-nt mailing list to learn about prerelease tests. The current public release for Windows is based on 21.4.0 "Solid Vapor". http://www.xemacs.org/Download/win32/setup.exe We are considering providing binary kits for important platforms that lack independent distributors (a la the Linux "distributions" or the FreeBSD "ports" maintainers) for at least some releases once 21.4 is accepted as "stable". Volunteers should contact the Release Manager, "Stephen Turnbull" , and let me know what platforms you can build for. * Important notice for CVS users: The CVS Repository structure has been rationalized thanks to Michael Sperber. The development code is now on the trunk. There are several active branches, each with per-release tags of the form "r21-4-0" (major-minor-patchlevel), and a branch tag which always gives the tip: Branch Branch tag Release tag Development trunk (21.5): none r21-5-xx "Gamma" branch (21.4): release-21-4 r21-4-xx Stable branch (21.1): release-21-1 r21-1-xx The trunk has a special "moving" release tag, "r21-5-latest-beta". This is updated with each release to reflect the most recent beta release. (The Beta Release Maintainer makes some effort to ensure that beta releases at least build; there is no way to make such a guarantee for the tip of the trunk in our development model.) There is no "moving" release tag for stable versions; just use "-r release-21-1" if you need the current release of version 21.1, and "-r release-21-4" for 21.4. To update an existing CVS checkout to the trunk (development), use the -A flag to cvs update. For a fresh checkout, simply use no -r flag. To checkout or update to one of the other branches, use the -r flag with the appropriate branch tag. http://cvs.xemacs.org/ has more information. It is in the process of being updated, so some information about tags may be inaccurate for a few days. * Thanks ... to all the developers, reviewers, and testers; to the Electrotechnical Laboratory and BeOpen.com for financial support; to Tux.org and SourceForge[tm] for hosting services; and to our users. May 10, 2001 XEmacs 21.4 Release Manager Stephen J. Turnbull -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From rendhalver@users.sourceforge.net Thu May 10 12:50:44 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA14577 for ; Thu, 10 May 2001 12:50:40 -0400 Received: from ulthwe.dyndns.org (p242-tnt1.brs.ihug.com.au [203.173.188.242]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id CAA11371 for ; Fri, 11 May 2001 02:50:33 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p242-tnt1.brs.ihug.com.au [203.173.188.242] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15098.50760.362929.389846@ulthwe.dyndns.org> Date: Fri, 11 May 2001 02:48:08 +1000 To: xemacs-beta@xemacs.org Subject: Re: problem with loading pces-xm in 21.5.1 In-Reply-To: <15098.38986.624931.622596@ulthwe.dyndns.org> References: <15098.38986.624931.622596@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Peter Brown writes: hi again got this one solved, well kinda think it was a mule thing maybe cause i dont have some additional libs for mule not sure anyways guess my forray into mule testing has been cut short :( will stick to stuff i have got (like gtk and gnome) but if someone would still like more info about the problem like my init.el file let me know > hi all > > got a problem with xemacs beta > my init file works fine with 21.4 > > but 21.5.1 complains about not being able to load pces-xm > > could it be a mule thing > my 21.4 instalation doesnt have mule > and ive got a separate packages tree (from experimental) for beta version > all packages for beta are current > um i had problems installing leim could that be it ?? > > my init.el file is almost the same as the sample one > plus a couple of included files for vm customisation > let me know if you need it > > my instalation details and output from -debug-init are below -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From rendhalver@users.sourceforge.net Thu May 10 13:24:30 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA16565 for ; Thu, 10 May 2001 13:24:29 -0400 Received: from ulthwe.dyndns.org (p242-tnt1.brs.ihug.com.au [203.173.188.242]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id DAA15094 for ; Fri, 11 May 2001 03:24:25 +1000 Date: Fri, 11 May 2001 03:24:24 +1000 Message-Id: <200105101724.DAA15094@new-smtp1.ihug.com.au> X-Authentication-Warning: new-smtp1.ihug.com.au: Host p242-tnt1.brs.ihug.com.au [203.173.188.242] claimed to be ulthwe.dyndns.org From: Peter Brown To: xemacs-beta@xemacs.org Subject: toolbar problems in gtk xemacs Reply-to: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.5 (beta1) "anise" [Lucid] (i686-pc-linux) of Fri May 11 2001 on ulthwe.dyndns.org configured using `configure --with-gtk --with-gnome --prefix=/usr/local/xemacs-gtk-beta --with-modules --with-site-modules --with-site-lisp --with-prefix --srcdir=/Hacking/src/xemacs/xemacs-21.5' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: hi all got a problem with the toolbar in xemacs with gtk enabled the open file button doesnt work it prints "Wrong type argument: stringp, nil the M-x find-file comand works tho if you need anymore info let me know Recent keystrokes: misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user misc-user button1up button1 button1up misc-user Recent messages (most recent first): Loading emacsbug...done Wrong type argument: stringp, nil Loading emacsbug... Wrong type argument: stringp, nil Loading sh-script...done Loading sh-script... Making completion list... Wrong type argument: stringp, nil Loading permanent-buffers...done Loading permanent-buffers... From Adrian.Aichner@t-online.de Thu May 10 17:21:01 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA31920 for ; Thu, 10 May 2001 17:20:59 -0400 Received: from fwd04.sul.t-online.de by mailout02.sul.t-online.com with smtp id 14xxs0-0007ZY-02; Thu, 10 May 2001 23:21:12 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.77]) by fwd04.sul.t-online.com with esmtp id 14xxrz-0vIDmiC; Thu, 10 May 2001 23:21:11 +0200 To: XEmacs Beta List Subject: [Failure] XEmacs 21.4.2 "Developer-Friendly Unix APIs", i586-pc-win32 From: Adrian.Aichner@t-online.de (Adrian Aichner) Date: 10 May 2001 23:20:38 +0200 Message-ID: Lines: 77 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net I am seeing this problem also: src\event-msw.c does not compile. Adrian > XEmacs Build Report generated by emacs-version > 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid > with system-configuration > i386-pc-win32 > follows: > Contents of c:\Hacking\xemacs\xemacs-21.4\Installation: > (Output from most recent run of ./configure) OS: Windows_NT XEmacs 21.4.2 \"Developer-Friendly Unix APIs\" configured for `i586-pc-win32'. Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-21.4\\nt\". Using compiler \"cl -nologo -W3 -Od -Zi -MDd\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4.2\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for TIFF images. Compiling in support for JPEG images. Compiling in support for X-Face message headers. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Using minimal tagbits. Using indexed lrecord implementation. Using portable dumper. Using system malloc. Using DLL version of C runtime library Compiling in extra debug checks. XEmacs will be slow! > Contents of c:\Hacking\xemacs\xemacs-21.4\nt\xemacs-21.4-make-install.err > keeping lines matching > "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" > and then deleting lines matching > "confl.*with.*auto-inlining\|^Formatting:" cd c:\Hacking\xemacs\xemacs-21.4\nt\ nmake /f xemacs.mak INSTALL_DIR="c:\Program Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)" HAVE_XPM="1" HAVE_PNG="1" HAVE_TIFF="1" HAVE_JPEG="1" HAVE_XFACE="1" DEBUG_XEMACS="1" USE_PORTABLE_DUMPER="1" GUNG_HO="1" MAKEINFO="c:\Hacking\texinfo-4.0\makeinfo\makeinfo.exe" ZLIB_DIR="c:\Hacking\libs4xemacs\zlib" XPM_DIR="c:\Hacking\libs4xemacs\xpm-3.4k" TIFF_DIR="c:\Hacking\libs4xemacs\tiff-v3.4" PNG_DIR="c:\Hacking\libs4xemacs\libpng-1.0.2" JPEG_DIR="c:\Hacking\libs4xemacs\jpeg-6b" COMPFACE_DIR="c:\Hacking\libs4xemacs\compface" install Compilation started at Thu May 10 23:18:05 2001 WARNING: Compiling without dependency information. Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4.2\". 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. c:\Hacking\xemacs\xemacs-21.4\nt\..\nt/minitar.c(27) : warning C4013: 'exit' undefined; assuming extern returning int c:\Hacking\xemacs\xemacs-21.4\nt\..\nt/minitar.c(64) : warning C4013: 'mkdir' undefined; assuming extern returning int c:\Hacking\xemacs\xemacs-21.4\nt\..\nt/minitar.c(28) : warning C4716: 'Usage' : must return a value c:\Hacking\xemacs\xemacs-21.4\nt\..\src\event-msw.c(2227) : error C2065: 'XEMACS_MOD_SHIFT' : undeclared identifier c:\Hacking\xemacs\xemacs-21.4\nt\..\src\event-msw.c(2263) : error C2065: 'XEMACS_MOD_CONTROL' : undeclared identifier c:\Hacking\xemacs\xemacs-21.4\nt\..\src\event-msw.c(3105) : error C2065: 'XEMACS_MOD_META' : undeclared identifier c:\Hacking\xemacs\xemacs-21.4\nt\..\src\event-msw.c(3116) : error C2065: 'XEMACS_MOD_BUTTON1' : undeclared identifier c:\Hacking\xemacs\xemacs-21.4\nt\..\src\event-msw.c(3117) : error C2065: 'XEMACS_MOD_BUTTON2' : undeclared identifier c:\Hacking\xemacs\xemacs-21.4\nt\..\src\event-msw.c(3118) : error C2065: 'XEMACS_MOD_BUTTON3' : undeclared identifier NMAKE : fatal error U1077: 'cl' : return code '0x2' Compilation exited abnormally with code 2 at Thu May 10 23:18:32 c:\Hacking\xemacs\xemacs-21.4\nt\xemacs-21.4-make-check.err not found! c:\Hacking\xemacs\xemacs-21.4\nt\xemacs-21.4-make-check-temacs.err not found! -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From alexander@reinwarth.de Thu May 10 18:11:00 2001 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA04342 for ; Thu, 10 May 2001 18:10:59 -0400 Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14xye6-0003Fp-00 for xemacs-beta@xemacs.org; Fri, 11 May 2001 00:10:54 +0200 Received: from mnhm-3e365f56.pool.mediaways.net ([62.54.95.86] helo=lea.reinwarth.de) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 14xye1-0003vT-00 for xemacs-beta@xemacs.org; Fri, 11 May 2001 00:10:50 +0200 Received: from [192.168.110.66] (helo=nagus.connector.de) by lea.reinwarth.de with smtp (Exim 3.12 #1 (Debian)) id 14xycY-00060r-00 for ; Fri, 11 May 2001 00:09:18 +0200 Received: from nagus.connector.de (127.0.0.1) by nagus.connector.de (192.168.110.66) with esmtp ; Fri, 11 May 2001 00:09:00 +0200 To: xemacs-beta@xemacs.org Subject: XEmacs 21.4.2 does not build under cygwin From: Alexander Reinwarth Organization: None. X-Face: $7{qD Hi out there! Today I downloaded xemacs-21.4.1-21.4.2.patch.gz to patch up my 21.4.1's sources, which I got by patching 21.4.0 and ran into problems building it on one of my computers. The beta-versions from 21.2-b45 onward, 21.4.0 and 21.4.1 as well as 21.5.0 and 21.5.1 built smoothly on this machine, nevertheless 21.4.2 does not. The machine runs win2k and cygwin1.1.8(0.34/3/2). After running ./configure '--with-xpm' '--dynamic=yes' '--with-x11=no' '--with-msw' '--with-dragndrop=yes' and seeing no obious errors, make dies. The last messages I get are as follows: ,---- | make[1]: Leaving directory `/usr/local/xemacs-21.4.0/lib-src' | cd ./src && make all | make[1]: Entering directory `/usr/local/xemacs-21.4.0/src' | gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arit | h -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves event-msw.c | event-msw.c: In function `mswindows_dde_callback': | event-msw.c:1676: warning: implicit declaration of function `cygwin32_win32_to_posix_path_list_buf_s | ize' | event-msw.c:1678: warning: implicit declaration of function `cygwin32_win32_to_posix_path_list' | event-msw.c: In function `mswindows_wnd_proc': | event-msw.c:2227: `XEMACS_MOD_SHIFT' undeclared (first use in this function) | event-msw.c:2227: (Each undeclared identifier is reported only once | event-msw.c:2227: for each function it appears in.) | event-msw.c:2263: `XEMACS_MOD_CONTROL' undeclared (first use in this function) | event-msw.c: In function `mswindows_modifier_state': | event-msw.c:3105: `XEMACS_MOD_META' undeclared (first use in this function) | event-msw.c:3106: `XEMACS_MOD_CONTROL' undeclared (first use in this function) | event-msw.c:3115: `XEMACS_MOD_SHIFT' undeclared (first use in this function) | event-msw.c:3116: `XEMACS_MOD_BUTTON1' undeclared (first use in this function) | event-msw.c:3117: `XEMACS_MOD_BUTTON2' undeclared (first use in this function) | event-msw.c:3118: `XEMACS_MOD_BUTTON3' undeclared (first use in this function) | event-msw.c: At top level: | event-msw.c:3620: warning: no previous prototype for `debug_process_finalization' | make[1]: *** [event-msw.o] Error 1 | make[1]: Leaving directory `/usr/local/xemacs-21.4.0/src' | make: *** [src] Error 2 `---- If further information is needed, just kick me into the right direction :) Alexander -- To boldly frobnicate what no newbie has grokked before. - http://my.gnus.org From yoshiki@xemacs.org Thu May 10 22:21:20 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31626 for ; Thu, 10 May 2001 22:21:17 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4B2LBE05334; Fri, 11 May 2001 11:21:11 +0900 Mail-Copies-To: nobody To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org Subject: Re: [PATCH] fix for (list-coding-systems) from mule-diag.el References: <15093.49523.736978.443168@gargle.gargle.HOWL> <87vgnc3rb3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15096.19782.470107.692088@gargle.gargle.HOWL> <87u22tacap.fsf@u.sanpo.t.u-tokyo.ac.jp> <15098.18156.526293.520167@tyranny.hsys.msk.ru> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 11 May 2001 11:21:11 +0900 In-Reply-To: <15098.18156.526293.520167@tyranny.hsys.msk.ru> (Alexey Mahotkin's message of "Thu, 10 May 2001 11:44:44 +0400 (MSD)") Message-ID: <871ypw39t4.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 25 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Alexey Mahotkin writes: > >>>>> "YH" == Yoshiki Hayashi writes: > > YH> C-u M-x prints > YH> subsidiary coding-systems (-unix, -mac, -dos) It should only print > YH> base coding-systems. > > I intently did it that way because print-coding-system reports EOL > field. So there is no sense to ignore EOL variations. Well, that's why listing subsidiary coding-system is redundant. :-) If EOL of base coding-system is nil (automatic detection), then it has all three subsidiary coding-system. If EOL of base coding-system is non-nil (LF, CRLF, CR), then it has no subsidiary coding-system. This is how FSF Emacs's list-coding-systems works and I prefer their behavior. (I just prefer it, there's nothing wrong with your version.) -- Yoshiki Hayashi From yoshiki@xemacs.org Thu May 10 22:47:05 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA01815 for ; Thu, 10 May 2001 22:47:01 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4B2SiE05403; Fri, 11 May 2001 11:28:44 +0900 Mail-Copies-To: nobody To: karlheg@hegbloom.net (Karl M. Hegbloom) Cc: XEmacs Beta Subject: Re: Found on comp.emacs.sources: ibuffer.el References: <87k83sms72.fsf@bittersweet.intra.hegbloom.net> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 11 May 2001 11:28:44 +0900 In-Reply-To: <87k83sms72.fsf@bittersweet.intra.hegbloom.net> (Karl M. Hegbloom's message of "07 May 2001 20:32:17 -0700") Message-ID: <87y9s41uw3.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 24 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) karlheg@hegbloom.net (Karl M. Hegbloom) writes: > This is a really neat mode! We've got to have it. Yeah, it's really cool. It would be really nice to have it in our package. Steve? > (define-key ctl-x-map [(control ?b)] #'ibuffer) > > > ;;; ibuffer.el --- operate on buffers like dired > > ;; Copyright (C) 2000 Free Software Foundation, Inc. > > ;; Emacs Lisp Archive Entry > ;; Author: Colin Walters > ;; Created: 8 Sep 2000 > ;; Version: 1.9 > ;; X-RCS: $Id: ibuffer.el,v 1.115 2001/04/18 04:56:23 walters Exp $ > ;; URL: http://www.cis.ohio-state.edu/~walters > ;; Keywords: buffer, convenience -- Yoshiki Hayashi From steve@turnbull.sk.tsukuba.ac.jp Fri May 11 02:51:01 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA27956; Fri, 11 May 2001 02:50:58 -0400 Received: by localhost id m14y6dC-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 11 May 2001 15:42:30 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15099.35274.58358.614502@turnbull.sk.tsukuba.ac.jp> Date: Fri, 11 May 2001 15:42:18 +0900 To: Alexander Reinwarth Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: XEmacs 21.4.2 does not build under cygwin In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Alexander" == Alexander Reinwarth writes: Alexander> The beta-versions from 21.2-b45 onward, 21.4.0 and Alexander> 21.4.1 as well as 21.5.0 and 21.5.1 built smoothly on Alexander> this machine, nevertheless 21.4.2 does not. This is in part patchup lossage; an incorrect patch to that file was submitted, had to be reverted, and a new one applied. I probably screwed up the application. I've spent a couple of hours installing Cygwin, and I just installed VC++ last week. The first patch following allows me to build native under VC++, but the Cygwin build doesn't run to completion because of a conflict in the sound support. The second patch was submitted by Paul Stodghill and should fix the sound conflict. I'll release 21.4.3 early next week when the Windows team confirms these fixes. Index: src/event-msw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-msw.c,v retrieving revision 1.47.2.1 retrieving revision 1.47 diff -u -r1.47.2.1 -r1.47 --- src/event-msw.c 2001/05/09 09:54:05 1.47.2.1 +++ src/event-msw.c 2001/04/12 18:23:41 1.47 @@ -65,6 +65,7 @@ #include "sysdep.h" #include "objects-msw.h" +#include "events-mod.h" #ifdef HAVE_MSG_SELECT #include "sysfile.h" #include "console-tty.h" Index: configure.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v retrieving revision 1.152 diff -u -r1.152 configure.in --- configure.in 2001/05/05 08:26:04 1.152 +++ configure.in 2001/05/10 12:58:32 @@ -4040,6 +4040,14 @@ esac fi + dnl Win32 Native uses native sound + if test -z "$sound_found"; then + if test "$with_msw" = "yes"; then + sound_found=yes + native_sound_lib= + fi + fi + dnl Check for Linux/BSD native sound if test -z "$sound_found"; then for dir in "machine" "sys" "linux"; do @@ -4050,14 +4058,6 @@ [AC_DEFINE_UNQUOTED(SOUNDCARD_H_FILE, "${dir}/soundcard.h")] break) done - fi - - dnl Win32 Native uses native sound - if test -z "$sound_found"; then - if test "$with_msw" = "yes"; then - sound_found=yes - native_sound_lib= - fi fi test "$sound_found" = "yes" && with_native_sound=yes -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From schaffer@optonline.net Fri May 11 04:14:01 2001 Received: from mta4 (mta4.srv.hcvlny.cv.net [167.206.5.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA03941 for ; Fri, 11 May 2001 04:14:00 -0400 Received: from optonline.net (ool-18bf1659.dyn.optonline.net [24.191.22.89]) by mta4.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GD5001M5QJ1X9@mta4.srv.hcvlny.cv.net> for xemacs-beta@xemacs.org; Fri, 11 May 2001 02:11:26 -0400 (EDT) Date: Fri, 11 May 2001 02:12:32 -0400 From: Les Schaffer X-Face: [V?bWTh\+_V")"gXxY9KGQozO(|>ggwp;\Ds6@YGoS$wreQaSLmhWUp%V;okpj4C^i$FQWK Q:/luO.Zh=VP"U5M.%m1cK:v9DgiQp^JK47nxE^=e3~HPoLmY,igNBZo)LUT3a2CFm*chsyaq7~=dU _IX>v[h$BZsa*yn5;?{|3Z@ZI@FL(e`-@wq`f?~{1){A%o:/t"39M@}ER]6.62NbfxrD%!{9!So^\9 c Subject: [Failure] XEmacs 21.4.2 "Developer-Friendly Unix APIs", i586-pc-win32 To: xemacs-beta@xemacs.org Message-id: <15099.33488.359000.854654@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 6.92 under 21.4 "Developer-Friendly Unix APIs" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT > I am seeing this problem also: src\event-msw.c does not compile. i handled this by adding #include "events-mod.h" and all is well. i guess it should really go in event-msw.h??? les schaffer From Dr.Volker.Zell@oracle.com Fri May 11 04:38:18 2001 Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA06163 for ; Fri, 11 May 2001 04:38:17 -0400 Received: from gmgw02.oraclecorp.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4B8XFD09087; Fri, 11 May 2001 01:33:16 -0700 (PDT) Received: from vzell.de.oracle.com (shivapppd55.de.oracle.com [140.84.22.246]) by gmgw02.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4B8ba614085; Fri, 11 May 2001 01:37:40 -0700 (PDT) X-Mailer: 21.2 (beta46) "Urania" XEmacs Lucid (via feedmail 8 I) To: karlheg@hegbloom.net (Karl M. Hegbloom) Cc: XEmacs Beta , walters@cis.ohio-state.edu Subject: Re: Found on comp.emacs.sources: ibuffer.el References: <87k83sms72.fsf@bittersweet.intra.hegbloom.net> <87y9s41uw3.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Face: I-*}xvwusAv%MlABo'jVNP7TDXf5bb*L[q,r{DnsR1GoL07^Wf)sAu%>!LjXAFlZZN+`OQu }?#du]C)[*%ERKR#+l#sX'EoNbSO~|.x@ogoS5|"-u? Date: 11 May 2001 10:38:11 +0200 In-Reply-To: <87y9s41uw3.fsf@u.sanpo.t.u-tokyo.ac.jp> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Urania) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Yoshiki" == Yoshiki Hayashi writes: Yoshiki> karlheg@hegbloom.net (Karl M. Hegbloom) writes: >> This is a really neat mode! We've got to have it. Yoshiki> Yeah, it's really cool. It would be really nice to have it Yoshiki> in our package. Steve? I also vote for it. The last CVS version has an Xemacs fix for a popup-menu problem. o http://www.cis.ohio-state.edu/~walters/ibuffer.cvs.el Ciao Volker From alexander@reinwarth.de Fri May 11 04:40:52 2001 Received: from connector.de (smtp.connector.de [212.120.63.35]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA06427; Fri, 11 May 2001 04:40:51 -0400 Received: from nagus.connector.de ([192.168.110.66]) by connector.de with Microsoft SMTPSVC(5.0.2195.1600); Fri, 11 May 2001 10:40:41 +0200 Received: from nagus.connector.de (127.0.0.1) by nagus.connector.de (192.168.110.66) with esmtp ; Fri, 11 May 2001 10:38:52 +0200 To: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: XEmacs 21.4.2 does not build under cygwin References: <15099.35274.58358.614502@turnbull.sk.tsukuba.ac.jp> In-Reply-To: <15099.35274.58358.614502@turnbull.sk.tsukuba.ac.jp> From: Alexander Reinwarth Organization: None. X-Face: $7{qD X-OriginalArrivalTime: 11 May 2001 08:40:41.0403 (UTC) FILETIME=[0FA508B0:01C0D9F6] "Stephen J. Turnbull" writes: > >>>>> "Alexander" == Alexander Reinwarth writes: > Alexander> The beta-versions from 21.2-b45 onward, 21.4.0 and > Alexander> 21.4.1 as well as 21.5.0 and 21.5.1 built smoothly on > Alexander> this machine, nevertheless 21.4.2 does not. > The first patch following allows me to build native > under VC++, but the Cygwin build doesn't run to completion because of > a conflict in the sound support. > The second patch was submitted by Paul Stodghill and should fix the > sound conflict. I have now applied the two additional patches against the sources and now 21.4.2 compiles, although I still get warnings concerning event-msw.c: ,---- | gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves event-msw.c | event-msw.c: In function `mswindows_dde_callback': | event-msw.c:1677: warning: implicit declaration of function `cygwin32_win32_to_posix_path_list_buf_size' | event-msw.c:1679: warning: implicit declaration of function `cygwin32_win32_to_posix_path_list' | event-msw.c: At top level: | event-msw.c:3621: warning: no previous prototype for `debug_process_finalization' `---- Thanks for your efforts, Alexander -- To boldly frobnicate what no newbie has grokked before. - http://my.gnus.org From yoshiki@xemacs.org Fri May 11 04:47:06 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA07059 for ; Fri, 11 May 2001 04:47:05 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4B8l3E10753 for ; Fri, 11 May 2001 17:47:03 +0900 Mail-Copies-To: nobody To: xemacs-beta@xemacs.org Subject: Bignum support From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 11 May 2001 17:47:03 +0900 Message-ID: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 34 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Recently, I just wanted to write some program and thought about bignum support in XEmacs. I borrowed some code from librep and implemented +. It was fairly easy and I put them at http://www.sodan.org/~penny/XEmacs/bignum-sample.tar.gz It is written as an external loadble module so your XEmacs must have module support enabled. It also requires gmp version 3. Since a module can't modify lisp reader, it's only provided as a sample and you can't just have bignum support. I'd like to implement all numeric functions with bignum support and eventually incorporate it into core (of course it will be possible to disable big num support). However, before I spend some time to hack it, I'd like to ask some questions. 1. Do pepole want bignum support? If 1 is yes, then: 2. What range should be accepted as (point)? I think current 1GB max of buffer size is sufficient but it can be extended to 2GB by allowing bignum which is in 32bit range. 3. Should DEFVAR_INT'ed variables accept bignum? My opinion is that it should be enough to have 31bit integer for those variables, at least for now. As an aside, should XEmacs support rational, too? It won't be hard, either. -- Yoshiki Hayashi From simon@josefsson.org Fri May 11 06:06:42 2001 Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA15230; Fri, 11 May 2001 06:06:36 -0400 Received: from sjosefssonlap (slipsten.extundo.com [195.42.214.241]) by dolk.extundo.com (8.11.3/8.11.3) with SMTP id f4BA6cq27605; Fri, 11 May 2001 12:06:38 +0200 Message-ID: <003901c0da34$58135370$8300a8c0@sjosefssonlap> From: "Simon Josefsson" To: , "Yoshiki Hayashi" References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> Subject: Re: Bignum support Date: Fri, 11 May 2001 12:06:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 > Recently, I just wanted to write some program and thought > about bignum support in XEmacs. I borrowed some code from > librep and implemented +. It was fairly easy and I put them > at http://www.sodan.org/~penny/XEmacs/bignum-sample.tar.gz Cool! > It is written as an external loadble module so your XEmacs > must have module support enabled. It also requires gmp > version 3. Since a module can't modify lisp reader, it's > only provided as a sample and you can't just have bignum > support. I'd like to implement all numeric functions with > bignum support and eventually incorporate it into core (of > course it will be possible to disable big num support). That would be extremely nice, the emacs integer limits has bugged me for quite a while. From youngs@xemacs.org Fri May 11 06:15:01 2001 Received: from mail007.syd.optusnet.com.au (mail007.syd.optusnet.com.au [203.2.75.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA15981 for ; Fri, 11 May 2001 06:14:59 -0400 Received: from slackware.mynet.pc (wdcax13-076.dialup.optusnet.com.au [198.142.220.76]) by mail007.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4BAEtS29504 for ; Fri, 11 May 2001 20:14:55 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4BA9MwS012849; Fri, 11 May 2001 20:09:22 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Found on comp.emacs.sources: ibuffer.el References: <87k83sms72.fsf@bittersweet.intra.hegbloom.net> <87y9s41uw3.fsf@u.sanpo.t.u-tokyo.ac.jp> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 11 May 2001 20:09:21 +1000 In-Reply-To: <87y9s41uw3.fsf@u.sanpo.t.u-tokyo.ac.jp> (Yoshiki Hayashi's message of "11 May 2001 11:28:44 +0900") Message-ID: Lines: 16 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "YH" == Yoshiki Hayashi writes: YH> karlheg@hegbloom.net (Karl M. Hegbloom) writes: >>This is a really neat mode! We've got to have it. YH> Yeah, it's really cool. It would be really nice to have it YH> in our package. Steve? I was planning on it, just hadn't gotten around to it. I'll do it shortly. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From hniksic@arsdigita.com Fri May 11 06:21:04 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA16563 for ; Fri, 11 May 2001 06:21:03 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yA2h-0006rD-00 for ; Fri, 11 May 2001 12:21:03 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Bignum support References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 11 May 2001 12:21:03 +0200 In-Reply-To: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> (Yoshiki Hayashi's message of "11 May 2001 17:47:03 +0900") Message-ID: Lines: 21 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Yoshiki Hayashi writes: > 1. Do pepole want bignum support? How are you planning to add it? Is (* 1000000 1000000) just going to work? I'm also thinking about compiler declaration to force fixnum arithmetic, but that's maybe not necessary in XEmacs because we don't generate native code. Most importantly, how much of a slowdown to you expect? Every XINT will need to be reviewed and changed into one of: * XINT_FIXNUM: convert fixnum to integer, argument must be fixnum. Caller should have run CHECK_FIXNUM. * XINT_COERCE_FIXNUM: convert fixnum or bignum to integer, but throw an error if the bignum is not representable as integer. Caller should have run CHECK_INT. * XINT_ANY: convert fixnum or bignum to a C object that represents bignums. From yoshiki@sanpo.t.u-tokyo.ac.jp Fri May 11 08:56:44 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA31388 for ; Fri, 11 May 2001 08:56:43 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4BCufE12062; Fri, 11 May 2001 21:56:41 +0900 Mail-Copies-To: nobody To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Bignum support References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> From: Yoshiki Hayashi In-Reply-To: (Hrvoje Niksic's message of "11 May 2001 12:21:03 +0200") MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 11 May 2001 21:56:40 +0900 Message-ID: <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 48 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Hrvoje Niksic writes: > > 1. Do pepole want bignum support? > > How are you planning to add it? Is (* 1000000 1000000) just going to > work? Yes. > Most importantly, how much of a slowdown to you expect? Every XINT > will need to be reviewed and changed into one of: > > * XINT_FIXNUM: convert fixnum to integer, argument must be fixnum. > Caller should have run CHECK_FIXNUM. > > * XINT_COERCE_FIXNUM: convert fixnum or bignum to integer, but throw > an error if the bignum is not representable as integer. Caller > should have run CHECK_INT. > > * XINT_ANY: convert fixnum or bignum to a C object that represents > bignums. Not really. If index ((point) etc.) is not allowed to have bignum representable as integer, XINT_COERCE_FIXNUM is not necessary. That's why I asked in previous post. I don't think people want to do something like (make-string (* 2 most-positive-fixnum) ?a) If people really want to have 2GB buffer, it's possible to implement it but they must accept some slow down. I cannot be sure about performance because obviously I did no benchmark. However, my guess is that slow down will not be severe. Every XINT will need to have one more check to signal better error when argument is bignum. This won't be a big issue since additional check is called only when XINT's argument is not a fixnum. Every XINT in numeric functions will be converted to something similar to XINT_ANY. But my sample implementation doesn't convert everything into bignum. If arguments are all fixnum and the result fits in fixnum range, all operations are performed as fixnum. I think fixnum operations won't slow down much except a few more check for bignum and a few more function call (you won't be able to call just + in C). -- Yoshiki Hayashi From npak@ispras.ru Fri May 11 09:14:55 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id JAA00813 for ; Fri, 11 May 2001 09:13:59 -0400 Received: (qmail 5119 invoked from network); 11 May 2001 13:12:37 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 11 May 2001 13:12:37 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f4BDD5U27478; Fri, 11 May 2001 17:13:06 +0400 (MSK) Received: tid RAA22442; Sat, 11 May 1996 17:13:25 +0300 Received: from kazbek.kazbek.ispras.ru (kazbek.kazbek.ispras.ru [194.186.94.130]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f4BDDag79755; Fri, 11 May 2001 17:13:36 +0400 (MSD) (envelope-from npak@ispras.ru) Received: from HOOKAH.kasbek.ispras.ru (hookah [194.186.94.160]) by kazbek.kazbek.ispras.ru (8.11.2/8.11.2) with ESMTP id f4BDDYX24746; Fri, 11 May 2001 17:13:34 +0400 (MSK) To: , xemacs-beta@xemacs.org Subject: [Failure] XEmacs 21.5.2 "anise" i586-pc-win32 From: npak@ispras.ru (Nick V. Pakoulin) Date: 11 May 2001 17:13:33 +0400 Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Compiling on Win2000 native. Updated from CVS May 11 2001. Nick. -------------------------------------------------------------------- OS: Windows_NT XEmacs 21.5-b1 \"anise\" configured for `i586-pc-win32'. Building XEmacs in \"c:\\SRC\\xemacs-beta\\nt\". Using compiler \"cl -nologo -W3 -Od -Zi -ML\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b1\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Compiling in extra debug checks. XEmacs will be slow! -------------------------------------------------------------------- sysdep.c bscmake -nologo -oc:\SRC\xemacs-beta\nt\..\src\temacs.bsc @bscmake.tmp del bscmake.tmp link.exe @.\nmb01380. device-msw.obj : error LNK2001: unresolved external symbol _Qpages device-msw.obj : error LNK2001: unresolved external symbol _Qselection c:\SRC\xemacs-beta\nt\..\src\temacs.exe : fatal error LNK1120: 2 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. From hniksic@arsdigita.com Fri May 11 09:41:45 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA03968 for ; Fri, 11 May 2001 09:41:45 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yDAu-0007Wv-00 for ; Fri, 11 May 2001 15:41:44 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Bignum support References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 11 May 2001 15:41:44 +0200 In-Reply-To: <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> (Yoshiki Hayashi's message of "11 May 2001 21:56:40 +0900") Message-ID: Lines: 64 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Yoshiki Hayashi writes: > Hrvoje Niksic writes: > > > > 1. Do pepole want bignum support? > > > > How are you planning to add it? Is (* 1000000 1000000) just going to > > work? > > Yes. Cool. Normally I wouldn't even ask this, but experiences with Python and Java teach us that you never know how someone might choose to implement fixnums. > > * XINT_FIXNUM: convert fixnum to integer, argument must be fixnum. > > * XINT_COERCE_FIXNUM: convert fixnum or bignum to integer, but throw > > * XINT_ANY: convert fixnum or bignum to a C object that represents > > Not really. If index ((point) etc.) is not allowed to have > bignum representable as integer, XINT_COERCE_FIXNUM is not > necessary. So you plan to disallow any bignums smaller or equal to most-positive-fixnum? That never crossed my mind, probably due to exposure to Python. > I don't think people want to do something like (make-string (* 2 > most-positive-fixnum) ?a) You're probably right. In the general case, something like that might be desirable because it would allow us to lower the fixnum size without visible penalty. (Why would we want that? Perhaps to reintroduce small conses.) > Every XINT will need to have one more check to signal better error > when argument is bignum. You mean CHECK_INT, right? XINT does no error checking. > Every XINT in numeric functions will be converted to > something similar to XINT_ANY. But my sample implementation > doesn't convert everything into bignum. If arguments are > all fixnum and the result fits in fixnum range, all > operations are performed as fixnum. I see. Here it would be nice to have compiler support for that, so that the compiler can generate fixnum-only opcodes where it can prove that fixnums are used. But that's not really possible without lexical scoping, so we can forget it. I guess the all-fixnum check is not too expensive, especially since all these functions already check whether their arguments are numbers, etc. With a little cleverness, the all-fixnum case might remain as fast as it is now. > I think fixnum operations won't slow down much except a few more > check for bignum and a few more function call (you won't be able to > call just + in C). Of course. OK, you've convinced me. Your bignum plan makes sense and I would very much like to see bignums in XEmacs. From karl@charcoal.com Fri May 11 09:53:35 2001 Received: from cinnamon.vanillaknot.com (MESQUITE.SLIP.CS.CMU.EDU [128.2.207.11]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA05765 for ; Fri, 11 May 2001 09:52:21 -0400 Received: (from karl@localhost) by cinnamon.vanillaknot.com (8.9.3/8.9.3) id JAA19967; Fri, 11 May 2001 09:52:24 -0400 To: xemacs-beta@xemacs.org Subject: 21.4.2: toolbar and overall window size damaged by toolbar placement X-Face: ?=p^Gj2JkX~UU_@W}[q/'Dxn19x-zfIQ](y<&ky/?1-&Nz&,!W}R.Gp+"LeGojoR =RF>?!XVs{a:`Yt(gqM<#$Zy(C@]'dR4Hy4S1.I(n3:2"R:=Uy!)K9>U!gNTyH{p +_w#F[gt).$Vyvo5=9LF^PeQ(@H#}QLAbfyYxX/8t:TDR5nA\|RmJO"EwjL8tWyvM From: Karl Kleinpaste Date: 11 May 2001 09:52:24 -0400 Message-ID: Lines: 15 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= In 21.4.2 under RH6.2, moving the toolbar to the bottom and back via "Options -> Display -> Default Toolbar Location -> Bottom" and then back to "Top" does some damage: 1. When the toolbar is moved to the bottom, the overall size of the window shrinks by about 4 lines. 2. When the toolbar is returned to the top, the window remains shrunken, and the toolbar itself has gained a white bar. --=-=-= Content-Type: image/jpeg Content-Disposition: inline; filename=2001_05_11_093924_shot.jpg Content-Transfer-Encoding: base64 Content-Description: startup /9j/4AAQSkZJRgABAQEAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CADxAgUDASIAAhEBAxEB/8QAGwABAAIDAQEAAAAAAAAAAAAAAAUGAQMEBwL/xABfEAABAwMC AgILDAQKBggEBwEBAgMEAAURBhITISIxFBUWQVFVVmGRlJUHFyMyUnShstHS09Q2cYGzJDM0 NUJTYnWTwTdFVHOEkiVDZXKCg7HwhaPh4yZGZHaitMLD/8QAGQEBAQEBAQEAAAAAAAAAAAAA AAECAwQF/8QAMREBAAIBAwMCAwYGAwAAAAAAAAECEQMTURIUITFSQWHwBCIycZHRBYGhscHh QlPx/9oADAMBAAIRAxEAPwCJttvt7lsjOvxuI65vKlF1wdTigOQUB1AVLqs2m4cATbmEx2Sc Jw86So+YbqhYz3DtkEZ/oLP/AM1yusXZhT0TspmG+3HJCmZiUlC0nGcKVySoY5Hzmvo3rFfs /XSmbY9OXji0zq9MziG7sDTkhlL8FtL7KjgK4zo5+AjdyNau1tq/2JP+M79+uSfdIz00ogsx GEKcCy3ESkNtpSCACU8lKO7mfMKmNPXdiBMfW6tttxbJQy66XAltW5JJJb6Y6IUOj4cHkTWt CK30ovfTxPCXtMXxFvDi7W2r/Yk/4zv36drbV/sSf8Z379WpjVdtS6hD7yVNuS9zoaaXw8fw cKWQolSgpKHxk5UoKOQNxFaYF+tMe1MtSHm347XBWIrnGW7vDqFOdE/AgEcTGMEggHmVVvFP +tOqfcrfa21f7En/ABnfv19JtNuWlak2/clA3LIddO0ZAyenyGSB+0VMM3ss3Blx6/NS3koW BIcQ8UpBxhJcAS8OpXxRgZx1LXjWLkXF3xce/BhpTIylwEKmcwNvJIyevpEBSskkAKXjXRp+ yPr+SdduUW3abc64htu373FkJSlLrpKieoAb+utj9ihRQgvW3YlYCkqLzuDlKVDnv+SpJx3s iuWFcUxZ0eQpKlpadSspS4UFQBzgKHMHzjqq2S9ci73SLIWpuI4yyUhxfF2FRSjcOgorR0gv CkcyClKuWaW06xPikYIvMx5sq/a21f7En/Gd+/Ttbav9iT/jO/fqdN8jkOiPeVRyJClvOLaU oy2ylACcBOHCClf8ZtCt+TgqUBxzdQIkyY0ZyQ4q2BmMh5DSADlLaAspBHxwQoBXXjlnbypF KT/wj6/kTefc4mLNb5DhQ1ASpQQpZHHdHRSkqJ+P4ATWvtbav9iT/jO/fq0PaoYRIhupuTXZ JRJZdfirknYlbaQ3uU70yEryrAzjGQM9cexd2W4622r2ppwSFuSXVNrJmJKUcgnBC8EOcnNo O8ZxuUBIrT2QvVPuR71ggsym4wgJcdcQ2pCW3niTvSFJAG7r6QH66+X7FCihBetuxKwFJVxn cHKUqHPf8lSTjvZFSw1PHDpDjqnY7MSIWWUlTeXkcHfggZC8JcTv68cgcYFaNUavOo3Iq1M8 NTKMEhRAJKU7sJyQOkFc+sgpz1UrSszETSME38fiRjdqtbjqUCEnKjgfDu/fqbd01p9BkhEA q4ZSyjMh3pOHrJ6fe8FV2JNDcxhZPJLiSfTU0m4BLqtx5IuCXVfqrGtp0i0Yhql7THquLPuf aTSyhLltUtYA3K7KeGT+xdffvf6Q8VK9bf8Av1jtr5/pp218/wBNfLexn3v9IeKletv/AH6e 9/pDxUr1t/79Y7a+f6adtfP9NBn3v9IeKletv/fp73+kPFSvW3/v1jtr5/pp218/00Gfe/0h 4qV62/8Afp73+kPFSvW3/v1jtt/a+mnbb+19NBn3v9IeKletv/fp73+kPFSvW3/v1jtt/a+m nbb+19NBn3v9IeKletv/AH6e9/pDxUr1t/79Y7bf2vpp22/tfTQZ97/SHipXrb/36e9/pDxU r1t/79Y7bf2vpp22/tfTQZ97/SHipXrb/wB+nvf6Q8VK9bf+/WO239r6adtv7X00Gfe/0h4q V62/9+nvf6Q8VK9bf+/WO239r6adtv7X00Gfe/0h4qV62/8Afp73+kPFSvW3/v1jtt/a+mnb b+19NBn3v9IeKletv/fp73+kPFSvW3/v1jtt/a+mnbb+19NBn3v9IeKletv/AH6e9/pDxUr1 t/79Y7bf2vpp218/00Gfe/0h4qV62/8Afp73+kPFSvW3/v1jtr5/pp218/00Gfe/0h4qV62/ 9+nvf6Q8VK9bf+/WO2vn+mnbXz/TQZ97/SHipXrb/wB+nvf6Q8VK9bf+/WO2vn+mnbXz/TQZ 97/SHipXrb/36e9/pDxUr1t/79Y7a+f6adtfP9NBn3v9IeKletv/AH6e9/pDxUr1t/79Y7a+ f6adtfP9NBn3v9IeKletv/fp73+kPFSvW3/v1jtr5/pp218/00Gfe/0h4qV62/8Afp73+kPF SvW3/v1jtr5/pp218/00Gfe/0h4qV62/9+vh7Q2i40Z2S/bVJaaSVKPZb/If89fXbXz/AE1w 3iYJtplRSo7XkFBx4CD9tBEswdFOFl1em5DUJ9YbZkrnO4WSfAHMjq74qyN6D0Y4grFsVsAy T2W/3v8Ax1THH3ZVtjQJS7Y200sF11paSSkd9todJKzk9YGO918rJHuThgvKWClTxWrZnq3H OK46NtS0TuRjz4/Jq0Vj8KEdRoNLjrjenJi4DTnCXMEl7YFf4mcefvftFWiPoXRkpAW3bDtP /wCsf5f/AM6qCH32bG5akS4yQFbG3XFNJCGyRkFs9JR+NnonJPXVgtNxDMZ0N7w0QlDW/kdq UBIJ85Az+2mlbUtNuuMYnx8y0RGMSjJ8PREaeqNF0zOmpQ5w1usyHyArGSkdPmcY5Dnzqbg6 P0RcYzciPbSpC0hQxLf5g9/49VuNLetqpTEcRVtSnlLdL03sdSUqBykDw5OdwycYGKkrA+mE w2y04XGWGUtBwgp4hypRUAeoZUceYU07ak3tFq4iPSeSYriMSpWs7VDsurJUKA0pqMlCClBc UvGc99RJ71K7vdKGNcyfOyg/SqldWVeKHpPaCAw+GHJj6I3FKN4RxJK0ZxkZxnOMjqq6r9ya SlSkL1kzkHBBtJPP/FqFj2dhmBoi7h55T796ZaKFFOxKRLV1YGe93yeuvStV3J60WyfOjpbU 60sbQ4CU81gc8EeGu9tW3iKz8HONOPOYU4e5O+n4usmR+q0H8Ws+9VJ8s2fZB/FqXl6heiBJ RPgzeI0+pBjxzt3Nt78KVxTjvd4/s663NasjJhodkMuktsMOS3GkjYyXQCORO49feBrO7f3S u3ThBe9VJ8s2fZB/Fp71UnyzZ9kH8Wr/AFW3b68L7cYK7hbYTUbh8MyUEqc3Jyf+sT1f5im7 qe6f1NunEIT3qpPlmz7IP4tPeqk+WbPsg/i1OztThEphiG0pQNxRCdccbOw/LCSDyIyOvr54 zg40xNTSJUixobY4jM/jb3OGEHoEjojecYxk5JyOrnyDd1PdP6m3TiER71UnyzZ9kH8WnvVS fLNn2Qfxav8AVX7o5naj+LY7Z9sO1/xTweJu6+vdt29/rz3qbup7p/U26cQiPeqk+WbPsg/i 096qT5Zs+yD+LU3F1bHcgNOlp+Q6Y7klwNNJb2NpWUlRClnwHkCTy71dD+qrfHZkuqS+UMNN PjCAC625gBSASCQCQDnGDTd1PdP6m3TiFc96qT5Zs+yD+LT3qpPlmz7IP4tXOJcmZsyZHZS4 exVhC3MDYpRGSEkHmR1Ed6vm8XJFntMiettTgaA6CTjJJAHPvcyKbup7p/U26cQp3vVSfLNn 2Qfxae9VJ8s2fZB/FqyruM+2KYN07GdRIKWm+xUqSoPEE7MKJBBxgKyOfWAOYNamiOONJVHk thckw1LWE4Q9z6BwonvDmARzHPrw3dT3T+pt04hWveqk+WbPsg/i1uV7mk9W/OtmcrxuPac8 8f8Am1Jq1a05Nt5ZQpMB8SFuPOtnmhtJO5GD4QrkRnzDIzKWu8tXVKVNRpLaFthxDjiUlCxn GApJIBBHNJIPmqTqXn1lYpWPSEEnQt6SkAa8awOX8yj8Ss9w178vGfYo/Eq1Ph5TKhHcbbd/ oqcQVpH6wCM+mq7Fv0tEW4zri9GTFgSXI60sx1b3NuACCVkDJUOWP298Yac/cNe/Lxn2KPxK dw178vGfYo/EqUXqaI2p1p2PJRKbfbY7GISVqW4MowQrbzGetXe/Vnlc1U32fDQlPDjlclEs Ooytoso3EDaSD+zNBy9w178vGfYo/Ep3DXvy8Z9ij8Spy13lq6pSpqNJbQtsOIccSkoWM4wF JJAII5pJB81dkuSiHDflOBRQy2pxQT1kAZOPRQVfuGvfl4z7FH4lO4a9+XjPsUfiV2NXue03 a5kxEYxbi4ltLbIVvaK+beVE4Vy6+Scd7NboWqYc/sbgx5YMpDhYC0AcRSPjJBzjOOefi97O QQAje4a9+XjPsUfiU7hr35eM+xR+JWy3arW9DtkiclLAkiQpZQ1uSUtAnIO/KeXhBJIPVyJ6 l6ugsxlvPRpbe2OiSlCkoKltrUEhQwojrI5Eg86Dh7hr35eM+xR+JTuGvfl4z7FH4lST2qrf HS/xUvtuMuttFtaAlRKxlJ5kAAgE9IgjByAalIcrstlSzHfYUlZQpt9G1QI9II84JFBWe4a9 +XjPsUfiU7hr35eM+xR+JUtqG6vWqPDWyphHHloYW4+CUoSoHKuRHVjw1xxNTYkusyeHJa7L ZisSoicNuKcTnHNR+LjngnrHKg5e4a9+XjPsUfiU7hr35eM+xR+JXVcNUKQyBAiOLdNw7AKn AnalYxnA3DOe9zHnI7/yrUj8a4XFMxtLcS2to4y0t5U6tQ5ben0ckjAIVyzkig5+4a9+XjPs UfiU7hr35eM+xR+JUhI1ZAhBwS2ZLC2n0MuoUlKijekqSo7SQRgHqJPLqozqqM++plEC4cVs JU80WQHGgTjJRnce8eiDgEUEf3DXvy8Z9ij8SncNe/Lxn2KPxKt1RcG5PSb7doK0thqHweGU g7jvSSc86CF7hr35eM+xR+JTuGvfl4z7FH4ldUPVsd6NFHCfkyn2lvBtlpKFbUqI5JUs5PRP IFR5E4FdD+qoMZ6ShxmWExuEXnOFhKEuYwTnmMZGRjd4AcHARvcNe/Lxn2KPxKdw178vGfYo /Eq3UoKj3DXvy8Z9ij8SncNe/Lxn2KPxKt1KCo9w178vGfYo/Ep3DXvy8Z9ij8SrdSgqPcNe /Lxn2KPxKdw178vGfYo/Eq3UoKj3DXvy8Z9ij8SncNe/Lxn2KPxKt1KCo9w178vGfYo/Ep3D Xvy8Z9ij8SrdSgqPcNe/Lxn2KPxKdw178vGfYo/Eq3UoKj3DXvy8Z9ij8SncNe/Lxn2KPxKt 1KCo9w178vGfYo/Ep3DXry8Z9ij8SrdSgpvcBdt27u4Yz4e0g/ErZ3DXry8Z9ij8SrdXLcpK 4dqmSmwkrZYW4kK6iQkkZ9FBVzoC7KOTrhgnw9pB+JWwaGvQGBrtn2KPxK3I1Y2pyzjjxFIk R3HpvDO5TJS3v5AEkc88jk8qXHVyWbU+9GjONykx25LSJKQUrbWsJ3dBR8PUSDzFBzK0Bdln KtcsE+eyD8SoLVttu+krMJo1e3McLiEIjptKW9wK0pJ3FZxjd4D3v1i6I1PCXKLBakpAmGEX FNjYHe8M555werq7+MjNY91r9H2P94n963QcHumjGt3vm6PrLpT3Tv03e+bo+sulQdCf0T9z /wDv9r/+2urrq6I7cYUuA2w+vjr5raCDs2rB5hS05zjvVUoVvmXPSuh2IAYVJbui5KEvuFCF cJ110pKglRGQgjOD11NSUazVKeK7lphpZWSpvtiobDnq5sZ5eeqN1wtbt/faccbfg8Bp5sB1 KF7+KgoyNqzjHXz66506OQhe4SGF7mmG3FPREuKHDSEko3EhO4AZyFV8BnWJ6rtpn2kfwKzw NZeNdNe0T+BQWqqulq7R7vPnxIb6OzOHuQ6y0vbsTgYIfHnrHY2tPGmmvaJ/ArU0jWjz8ppE 6w4ihBddM1QQCvOBu7H6+X0ig6hplTjyHhMcaaNwTcSwtpJUF8tySoH0Y6sn43Ij6i6XMSLa kNz1B63l3a6Gh0kuZ3ciTgjIweY5cwequYM6xPVdtM+0T+BX2iJrVxRSi5abUQCcJuBPIcyf 5PQWZxRQ2pSUKWQCQhOMq8wyQPSarvYz/dB207W3LZsz2PxGtvFxt4n8bjOzo4xWrsbWnjPT ftE/l6+XWdZssrdXc9ObEJKlET1E4HmEfJoMNaKSwxHSiUw461HWwVSIgcTgrKwpKSrkobiO eR5qkJmmIsyRFU4rLLcfsZ5vbjjNggpHRwE4UM9EDPV1VGpTrMx47ztx07H47SXkIeuBQrao ZHLgVnbq8/640v7S/wDsUE7Z7Z2qhrbW9x33XVvPPbdvEWo8ztyQOWBy8Fbrjb2Lpb3oUkKL TowdpwRg5BH6iAar3D1gf9b6Y9pH8Cs8HWR6rrpn2ifwKDZcbXdHnLeqRKdmiM+29sjx22wS jOSrc4DlWe8cDB5dVcvamV/sM7+de2XxWP8Ak/jfp+ivoo1oZsaI3OsLr0gqCA1NUrG1JUSS I/Lq+n9eN/YWt/GGnfXz+XoPuJpRUN6AUXJzhQeOGUhpO4BzPPJz0hnrxg4HIc89VqsK7fcp E92Ulx19tKHEtNcJC1A81qTuIKj4Rgczy51x9g64/wBv076+fy9Z7X65/wBv096+r8vQT8l5 xhsKbjOyCTjY0Ugjz9JQH01W27M5Kt9ztr8aYyi4SVyeMoNYaJIUAQHCTzSO9zz3uutva/XX +3ae9eV+XrnYb1q+iQ4JthQ2w+Y6luTVJSVgAkAmPz6/oPe50HW7phb8h6Y7NT2auSzJSpLO GwWhhIKdxJyCc9Id7wczGlyzNYmdnqDyH5D7hQ0BlbqQnogk7cYHXuzXOWNZgZN001jw9sT+ BWODrE9V20z7RP4FBI2qwrt9ykT3ZSXHX20ocS01wkLUDzWpO4gqPhGBzPLnUhcAFQ3GlRHZ SHQW1ttKSk7SCDzUpP0HPOoDsfWZ/wBaaa9on8CtMw6ygw3ZTlw0+tDYztbnKUpXgAAj0H2z AnDsFmVDnPw4CwuO0EsIVlPJBWoO89o5cgM9/NfOlrE+mFaJcxx1tUMP7I62tqkqWog5PXjA yBjOT14wK2vRtaR3iy9c9NtujrQu4kEfsMevnhawP+t9Me0j+BQfbejkpTEZXcHFRYyJDaGw 2ArY6CD0vlDd14wcDkOefl/Ry5URbT9wTvENuG2pDGAlCFhWSCo5JwO+P1V8ITq9xRSi8aXU oHBAuWSP/kVsEbWh6rnps/8AxE/l6Dvcsbpm3KUzNSgzS1ubWwFo2oSUlKgT0goHvYPnrosd pFlt5ipeU6C4pYHMJRk/FSCSQB5yeeT36hEo1qucYiJthUtLCn1qTNUUIQCBzV2Pjv8A0c8c s/fA1l41017RP4FB3ahiyZvYaI8d9So8hElLiEtqSSnPRIU4g9+o9uxSZ0x+VJS/HmLkMyUu qbb4QLQ2pTsS4pRyCrPMfs7+wRdaq6rnps/quB/L1nsPW5OO2OnPaB/L0G1vS5Q2lKp6lkXQ XErU0Mq/snBA/aB+ytk3TKJyrzvlKSLkGuSUfxZbHLv88nHg/wA65uwtb+MdOe0D+Xrnj92U iE1L7P0+0y8VhsvTlIK9qikkAx/N9IoO0aXBU0rjxmi3Mak7Y0NLSMIB6OAc8yScknzAVuvG n3LvIQpc7Y0haFt4a+EZIPMtrBGM8vjBXMZ8GODhawP+t9Me0j+BWeBrI9V1017RP4FBaqq6 WrtHu8+fEhvo7M4e5DrLS9uxOBgh8eesCNrQ9Vz02f8A4ify9apCdaR+CDOsDinnkMoS1NUo lSjjvR+Q79BuVpFw2Ji0m4NrYbQoEORsjcVFQWnCgUqGSOsgjvddco06/Oud6huvyW4jgiIL riNxfShIyQo46WU9fMczkHljoWzrJtxTa7rplK0khSVXEggjvEcCscLWJ/1tpn2kfwKC10qq 8DWR6rrpr2ifwKz2PrPxppr2ifwKC00qotp1o6/KbTOsATFCC66qaoIBXnA3dj+b6R36+tmr /HGmPaX/ANigtlKqnC1j420z7SP4FZEfWZ6rppr2ifwKC1UqqONayaZW6q56c2ISVK2z1E4H PqEfJr5QjWZjx3nbhp5jjtJeQh6eUq2qGRy4FBbaVUw3rA9V30x7SP4FfXA1l410z7RP4FBa qVVux9aeNNNe0T+BWtTetezYsRE2wuvSSoIDc1SsbUlRJPY/Lq+n9dBbaVVOFrE/620z7SP4 FZ4Gsj1XXTPtE/gUFqpVW7H1p40017RP4FZEXWp6rnpv2gfy9BaKVUY6NaSW33EzrClpl8sF xc1SUqWACcEx+fX9B73OtnA1l41017RP4FBaq4bwhx61SI7bDrpfbU18Ftynckjd0lJBx+uo URdanquWm/aB/L1kQ9bnquOnD/8AED+XoNTloemC0x3oc5tqHHXGWv4HpBbYbKuThxjr6jX0 dGhVsehmVGbK2G2Q4zCSg9FQUVKOSpRO0d8Dv4rXORrSBDdlOzrCpDaclLc1SlHvAAdj+Gtr 0bWkd1TT1z0224n4yF3Egjv8wY9BqtliflSpS5LjrDLV5cloaU1jiY+KpJPeOefXnAxjmTGe 61+j7H+8T+9bqWQzrJxQSi66ZUT3hcSf/wDhVf1jZ9TT7ZwJ8qyu7ULfHY8ta1JQ0OKvkGUj mEYGT1keeg1e6d+m73zdH1l0p7p36bvfN0fWXSoLRov+btEfOZv1ZNbpkLN7nSpWGYTUlS3V ucgpJWRgeEnmBWnRf83aI+czfqyagNaQZT0m+mE9IQh51RnRkLPwiEKO1aSeeAOsd7JI5fFl p6fOGqV6pxlW7tqVliYpce4PiWSSpiGEuI6yQdqwoI5YHLA5d7Na7Jq64R3j21y+wtXNQSN7 Y5c8J6x3yB5+vqHFFs7S2GmLY/GXIUnKoKcodCh8nOA55ikk+EA8hxOtrZcUh1CkOIOFJUMK BHWCOv8A9+jy3+0znxD1V0K48y9djrbfYQ6ytDja0hSVpOQoY6x4a6oSc2zUg+bdX/eNeTWT Uj+npCuiX4SlZcjjAIPhQT1HnnHUefV116rZZ8OfY9QTWJLRiLTGVxlqCEpAJBKirG3GDnOM YOcV6aXi8Zh57ac1tiXE2lJ3negJbBU4pSgEoABJKieSQBzJPIDnVNuWpbXqCc/aDclwrYyg uLPDcSuUUp3hRISdqAE5Sk88gKVggBvbIet961k/ZZF8MCzTGm3VuOKS02paWwcqKuY54ISr BKgncAUp290bTek9SS5lwmargWaQj+BrZRJa2OFLIbU6jKh0SSrb18kj9VJtNo8Glet/jiHD Y9flm2Pw1vNPPNufAXF6PlLqUIJKFJUnO/mjIGMgcjVptLrknRsOS+sredt6HFrI5qUWwSfp qARp3Sy0zrA3qK3KYhOqldmuzW2+y1rQjYlB3Y6HwnPnghGT4GmdQsoYd0w/JYkPR4qhEfjr CkuNJTgBWM7VAD9tKzMT5W8xMYhadRJyLMf+y2P8659K6et9/v8AdWrkJK0R4sVTSWpjzISV qf3HDak5J2J6/BXbfU5RZj/2Yx/nXnGmdcXrROqrvGkxRcWCG44U+4EubEFRa6aQRkhzJJSS cjqr0aOjfWt0Ujz+zjM49Xoc7RRbkqRCs10U0lSgFdmOqChuOCMz0HG3b1jOQTyzgQ8uy3zT rD92VabgYjMUOSGhKQ42lKHHuIs8V9a0L4XBUAhS0npJPMhSZxnWqtRtx1bLK0rhF3YjUshn hgltJC1NsBOdzjYAJOSro5511XyOXdHaklNFDkNNrlll5q+SJW9JZygqQobekhW7rOOjjOcj M2iYxhmK4nOSxp26stX/AJ37s1IdjJYbQ7MdEZC/ihQJWv8A7qBzNV7QIx3H+eCP3Aq73a2s T5LhnQGJQbUUpdR0HUcgev8Ab4f2VhtUrxetUxikWKzSI8FGSt2VGK1P/rTjKR+oVps+um58 tES62QMKIO6RDXhLYAyVLQrBSB3yc1Yl2+R0YUTU1whslQ3NSG0qc2+BK1J3DwZ5/bG3XU8L Rr6ozIXMuak5ALhcUQeeVuK5gHGcD0AVr1H2vU+ne59V6ZuCzFSUpLa2lBzJGcYxz5c+Xn74 rndUE6anZGc3lwdf9ivNNRXOdfI8yTOUhWG3FIZYRsabyCSQB1kk8zz72Sa9McTnTk7++l/U pNcQkfNFsvlOMI8/M+f/AOtfF1fQ5YZQTNYS46jZhDickc8g58Oa3Nt8udRsqND4K47XZDqm hleMEDPexyz+yuN79Lrp0i0+XbaJzdyY34CXEjppBzj9vg5Gum6Ixanj4Nv1hUXpFtJbkhJy Mp6//FU5eE4sz5/7v1hW48sTGJc2t3uxb7cJAbKygIO0d/oI81QNsft1wbKpl0DT3V2MrLKE nwKOQVekfqqc90METLqpPI7UEEf91NV3Stltd8QtUqQ4qQACuOnoggdSu+T+zFJznwR048uq Rp6M08p1h6MpwIBLy3kstNJPfCUcz+vNfUZi5w2mpDcp6TGDiEOLfb2pUFKCRsJO49fXyFWh zStp7GQGY6IrjJ3tvIHSSR1Ek/G/bmo2XfEy4ztsdcZelNuMq40c5bWA8j0K8I5/rqspO2px dbkPDaHfrCo5CaloAxergP8Aslz61QaHTJuJht4w0kKcKesk9SasK+ripxu1nhrUgl1IIT3x hVfWn1Kdgtbs9BBAJ666bm2DapIVnKdpOf1gf51p060o29BUVIQokBSfPVkTLacnNREoZ0nY P+I/eCpKFIUbg9b3VFTjaQ4hR61oNcamy7pWwISCVEyAAO/lysiGjRnlxY7ipyEreZbdKUwi oDckKxnijPX4K7ERHBzFwQf+AP41ccq6W20vwLU5K40xDbUd/hpy00tKAnG/PM7hjkOvz8qm kqjQ4j9ym57EjJ3rA61n+igedR5ek96riTKLv94Y0haxKlOsy5j6d7EdbKmwhGT01gLJOepI yMmo7Sl3u94ucGVdNieJOYU2y2ylCGE7uSeQyVHOTnNU9tU7W+rUXKTgsmY2lAAwhR3pSMD5 KRyH6q9Si29u3u2dtCRns9nJ8POrbEeIEbqacm1zpsgMpflPTXGYrCj0VLySSrHPakczjzDv 1qkaduMOA3LvWqLgy+8OizEfLITy6glJCeXLw/rNcmunFsahhykjCWp8lor+Spwp2fS2oftF Xa62mNqBEKcpw44edh8B59XeI5/+xUVR41zchTGY82aJ0WQvhx5ikBLja8ZDboHI5AJSrrJB z4aszTeOvr/9Krmu7bCtNshx45/hcuW2Wk457WzlSv2ZA/8AFVrjp3NIOOsUPi1xko7XajC8 7MxN3hxuqgPT71LkHhh+O2FdFsL2JR4OQ6/116EynELUqfmv/rVciL7LmvhHRbjqCFEdal45 g+Ycv10icIh0I1E18IHnFgDqLu8ehXKpCBe5DTqUT2VNkdTgTtwf2f5VJSnTCKJBUeCVhDgP 9HPUofZ/7PHdpj4kLZdtaVxxgJUAokjwg5PP9lXOfVG+FJcVFnQ3173I6FbXM/HSQcH/AN97 FSN/RuTZjy/mxj/OqrbHiqc+Nx5xVjwnAAx9Aq43lOWrOcf6tY/zqWjEqqGp7q9p7Tr1xjpQ X96WWuInKQpWTkjqOADyP+VUix681HOnLQ/OZLTSCshMNkbjkAA9HqyRnzZq7a2aWdNMNtoS txdxZSlCsYUSh0AGqHbobxviIr0YxnHmhggAkhTiQCAOvqrrpViZiZSZeg6Ou026qnImLQ6p hSClxKQnO7PeHIdVXS0J26ttPLH8d+7NU3RcNEW73mOjfhKYxIXjKSpsqIOOXIkjl4Ku9uTt 1ZZ//O/d1nVx1z0+iqvIkx4MZciS6lppHNSlfsqGiX653uYmLY7UHDtKsyF7TtHfI6kj9Z8F R2r31SLrHhH+Ijth5Se8XCSBkeYA/wDNUtoGM5Iub3Yc9ceWGFFaVRA62pvcgYJ4iTncRyA7 3X3q7aehG3OpZJnzh9Mameizlw7vESw4hexa2l7gk+ceDzgmrWxscbS4hQUlQyFDvjFeb6kj PRNU3FiVMMuQl1BdeLXDBKm0KACcnAAIHWeqrboeSt+2Px3FEmO4Nufkqzy/YQfTTV0axpxq VSJ84T7SFL0tJCevtuv6lRVwnItjW3YrjEBaSsdEgEZH6+VTEdSUaXmKUplIF1Xze+L8Tv1V rdBFyvhSWmyhILmxvOxWOrr54515J4dKw+2LlcHXkvNR3lNpkLfT0CoDPez4B1/trug3JbSU IWhwltKujsJW84o5GT3gPBXc/c0x31MRo3FQyBxF5ITyGPRXCHH7mt6StsltlHxtuE4zjA9P 01z6sSTKSvCc2SSokEjaFAf0TuGRWNT8PuycS4h1xLjrKChkZWQUpB2jw4yf2VxKUlNgmsIM RKUBBCGSSr445qz3/wD6VF+6BcLzB1TfIVvZZWJ4aCJagA7E+CQlQSrrKCBnaO+T4TXWvll3 6p1DdItqZZ08WLah95LRdZxvQg/2jzUonAzUXERcUxphuM+dMWbdMIVKkrdx/B3M7QokJz5s d7zVAC1TrFJi3KM12XwQUqiyiXEPJUNquv4qikkbhjr72c1YmLrBusSUuBIU40m2zSWnc8Zh RjuZbc5cyCPjd8deDmrKREub3Tv03e+bo+sulPdO/Td75uj6y6VlVo0X/N2iPnM36smvu6oW L1LcaUUPJkLUhaesHca+NF/zdoj5zN+rJr7uEuKu5S1oksKSp5ZBCwQRk1RRdU6ZQ4w9cYjC OGjnLi4/ijn+MR/YJ8HxTy6sGq+m8yuElm4NoucdKdo7IWUvtjn8R7meWepe4fqr1MvRt4dT IYDiQQMqSQR3wQeRBBIIPXVBlaWbnX99ayxHtyl7kMtukgjvpJPPb5uvvZNee+h1W8ej0V1v H3vVBtwU3J/ZZH0rSokbZA+EZSD3wOSu8MggZz4K9Q0zANo0RqOKt1JUyy2srfAKc7lqyoYP R58+RwO8eqt8BvTun7cxu+FcUpaAiMrIQkBOOQSrryevHVXJFmJvujtUuSmFQ1SVtoaa3gLB S4vYQVAZOEBWcecV0jTisT0uGrebQoD0u3Na7tcqeW3IqnUl9h2O4lexzduUpIBUVHORnJwW xuOCa59ZQ40XVMxphLCUIixCNiNyVKLfSwcYOTz3cgcZHeFc87TV5lzn3XeLKClhwKdlNjeo /GJ9GM8sVZGrAJS5M+88OXKWnmXpjq1LUAcdRyeZwMqGBnlXOsTEYcdCZ046Zh26Fg2h3S7z kmJHfk9nSW0I2qU4pRThpISBg5IVgbknKeRPxTZLFHbj6QkNs44SVywnarcCOM5g57+fDgfq HUKNK0i0HQu3y32m1pzsMlJKSTnnlIwScE4J5jr6qmNLwXbA3cGFvqXHlNL5LdQrYvCiMAeE k+n09Kzj1hvrtM+i53hOWbOf+zWf/Q15rp3T7Mu83qNMkWldkDzm8cfatglakpQQcbAnYfB1 gpJxXpd0fj8K1JL7QUi3MBQKxkHGcH9hB/bXn72lVxJN2ftsm0TEXR4Lej3PiAIHSJ2qbWM8 1HkR1Y58ufq0da2lMzX4rMZd18RY7JfNJx9Nu2p9O5xD3BKHi2dzGFEg8lkIwFHnyNej6mau qdAX9U6bDfb7TSQUsxFtKK+EeeS4rl18sd8c+XPxwaRmkAG2aLIG0YMqZjkAB/T/ALI/XjnU 20xqmPZrrbYo0Ywi6tLblv8AHkuPubklOS4tSiSAo4zkDPVXK1uqcyYWjQowjRvngD9wKlF3 qfElSH7nFddS4vf2VbldJACQMKbVnIwnPLPMnlXDpdDVulaYiOSo61Qoim3ltuAoBSzgnPg5 HrxUg3rWBZW+H2DLecUcqdZW2sKx+pZI/bipCuhu6xrihrseXGmMqeQlxKQULRuUB02zn/L9 Vee6zCW9QSlqWlqOhtAUerPLvk5z4B+yp663y3ainLkuRnY0hlgNQ1LTsWHVq/jOInO0IAB5 nvn9u2Npuwm6i43G7puLyAEtCS82UoAGOodZ6+Z51qPHlFasuk5+owFPpXCtSk8844kgHvY/ ojH7edXjbmwTx/2y59SpdFytiQEifEAHeDyR/nUMiTG7Rzdz7QDl3dWjKx0htHMeEcx6RUmZ lXIhGeZFcFwjvNMEobSvBUtp5BHLcclKhnqyT6R1VIokxe/JY/xB9tV+U02mOGEKUvHNJC28 fXrjqVmfEOujNYnzLr0Yg7ZgJ57knA/8RqdvqcWSTy6tv1hUDpdfa3jiQWgh0jnxk5HM9Yz5 6nL3Mhu2OQlqSypw7cJS4kk9IHqBrpHoxaYmfD51rCVOuNxjoUEqcSgAnmB0Un/KvP4rjkO1 MOqJbcBU5DkIVzQoHpIP6+vHn89elX+VFN/lHshkkFKT8IORCQCP15qm3y3NdiOrt8hgtqIW 5GCxjcP6SR3j+rrFVl8vXCZc2ULmSXHEqSDw87Uf8owD+3Nfdthrk3WK20pDaE81ZH9EKSrA HhyB9NcMVZLbLIbUV7UghXRA5d8nAqx2SIiNMTLl3CEgJQQGm3QTkjvnl4K9V7acU6Y9U8rB ET/09OHhtDn1qrtmTtvd3C+ivcgJPmOasEaXF7eTnUyWS0LUtJWFjaCVjAz4eY9NRpXDbnpm tSY+SNjqeKnpDvHrryqi5CHILUiMR8G8lJSfB0hz+it8NZlT4bUc4YhICc/KWR0j6c133VEW ZFAanxEuoOQS6K+7OiBBaTvmxSoDOOKkZPpqzI+1IUdYRwjvROl+rKsURuGlLGpOQRxyCO98 JXfBkW9t96a/OiGQ+NuA8noIHUOuo5uRHRpeyocebSsB5W1SwDguHBx+w+ioPN9V2RMViBJZ Rw2ZkNpXR/oOhtJVg9ffSrJ75NaNR352/wAe1adglxLLbQXIcI6SlkYcWcdXyU+b9dXa9wYV wsC4MWRGZdGwtuOurd27BgAJK8DlkcsVX9L6WjQrg69cpTLq1KyXA8psHvAYSvqHX6a7TqRN Y5FisNjbtlvhq4aUq7KjBCR/RAeQP/SrFLTiZaDzx2wZ/wDWtTKbI242vshB4a0uJC57ihuS cg7SvBwRmtkqVFfm2hDEll1QuDJ2oWFEDJ8H664iI1Fb25824suNJcQ484lbas4Wnccg/wDv vA9dQDUzVNtZ7Gi3lK2gMJ7OjhxxH/jHxv1qzVsmyoa7nKcTKYUlTyykhxJBGTzr4D8E43SI 5/WsVVh53Pi3KPOVfpanrnM4akLUs80p+MktgchhWDtAwQVcicV6PaJ7E6Kytp5t1Dje9l5v kh5AwCpIPMEZAUknKSR1gpUrLi7a+wWlyY2097iJ+2qZLt860ynRYbjFbakuBxxKzuS24P8A rkY+KvBII6lBRB5Eg5tNonMNV6cTEr0wn4DUyfmtVPSrahFmJVyWmWvcPAcD/wCtWqPKjlnU LhkNBDhihCt4wo8zgHvnkfQaiWOxY0xx1qQzsfILg4g6KsYyOff79Vhp1GkDT0k/9z6wqahM q7EYDqQVpbTuyO/gZrikGJNcbaeksCOhYcOXU9MjmB19VSiJsJI/lkf/ABR9tBzTbdFRFlSE MoS9wV5WkczyPWazdU5jWggAntaz1/qNb506Eq2SkomR1LUysBIcSSTjq66j77KKIlqTHdY4 qbeyFAuAFJxkZH6iDQVLXgkps9vTDGZKrkzwk8ukvCto5+c1SODfG7uns62uxpAjFuOhDZSX CHEnonPM5V3vCKtd5ZuVx7GBcbAjPofRsUDkp6q0Lj3mTc4D5LJ7H3dJxxIwSpBz1/2K6ado rMJMZS/ubRJUWZe2JjBZfbLGWyclIKCoZ8+D+yr/ABBjVtm/8/6hqsWRjsebJnvy4qJMpSOM Q+MHakJHL9VWSLLiq1PZ3EyWFJbS+pxSXAQgcPrJ7w5Gs2t1TlXnOr7etMtq4JBKFthpeB8U gkgn9e4+ipv3KIchV6mSuA72MYqmuNsOzfvbO3PVnHPFSxdhOtFt11haFDBSpaSD6agJWkLB KVlExDXXhKlpcSnq6gTn6a9FNeNrblnHnLk13AlMa1uT7rDrbDzjZZcUghLgDLQVtPUcHwdV WHRttVEtCn3UKS5KWlaQeXQSMA/tJP7MVy2vS+mre+HlPMSFjqCyhCe91gHn1dROP11aEz4S jlU2P/ipGfprnfU+7FYXDVES4rTc4NKQlXbVzprTuCeh1479VdwPtuuFlTm148lrTww55yPB VohS4zdillchlPEurikblgbhtHMekemuKW3BkhS0zowdUEpLi3QSlAVkgDPXXntXLUThph6b dfZC1yshfNYYRyx4M/51ITVx4cBMOMCrqSoJyvA8/nzUYhLYkIxIihC31DJeR0W8ciefWTmu iHGhuBCpk6LgoWlSRISkpyeXMHqwBSIR8vsuNaWlqW4SFlPRLRRg7xmu7U8Zp3UUlS0BR6HP H9gV93+bCcsEllmaw4voBKEuhROFJ8/Os3+VFN/lfwlrkQk/CDkQkAj9eRWhHdjocbLa05SR 1eCq+LG1aZ13kNAjsq2ysnvHbGdA/bg/+lWZuVEHXKZ/xB9tcV2eZdZe4TrbmLdOzsUDj+Dq 8FBXvdO/Td75uj6y6U9079N3vm6PrLpUFn0a2h226JbcQlba5M1KkqGQoFMnIIr0g2exBZSb XbwU9eYyAPTivOdE/wAh0N86mfVk16PP+P8A+M/VTWNW80rmG6V6pwx2nsHi62/4Df2U7T2D xdbf8Bv7Kp2otZMacuCYT0KS+6+wlyOWWXFpUsupb2qKUHaMrRzTuPMjbkoC9/dhbE3K5xHd 7QtrC5Ehxa28hCMbjwgou455BKACMEEhSSeG/f1w3t15WrtPYPF1t/wG/sp2nsHi62/4Df2V VXtUiKGESrLdmJMh8MMxy02tS1FC1pIUhakYPDUD0ujyKtqTurXdtaW6xxYcm5MvRm5G/eH1 tNrZ2EBeUKWFOYz/ANUF5xlOcpy7i/Bt15W7tPYPF1t/wG/sp2nsHi62/wCA39lVGJqdzszU PbGA9FgWl1X8LOwp4aWW3DkJWpRUd6lDCcbcA4VkV8TdUyortuQqy3BhyRM4C47rSVuLSWXl pLam1qRkrbAOVdEZKtoIVTuLcG3HK49p7B4utv8AgN/ZWp6BpqOppLsK1pU8vY2kst5WrBVg DHM4So/qBqkXH3QocBbaOwJjjj7R4KUsOKw8l8MLbcKEqA2uKSMoK888A5bDmj3Sf/yh/wDu WH//ALqxr2zjBtxyv/a3T3i2B6qn7KdrdPeLYHqqfsrRSufc34hrZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t094tgeqp+ytFKdzfiDZq39rdPeLYHqqfsp2t09 4tgeqp+ytFKdzfiDZq39rdPeLYHqqfsqO1JbbS3o6+yIkCI24i3yQHG2EpUPglZwcZ6jXVWm /foFqD5jJ/dGumlrWvbEs304rGYeQ+6d+m73zdH1l0p7p36bvfN0fWXSvS4rTon+Q6G+dTPq ya9IuCSFgkdaiR6E15von+Q6G+dTPqyavWo5s+Fc9PCLcGI0eRcOBIZXDcfXIBbWQlJR8TG0 qKjgDG4nCSledSnXXDVbdM5aXYUV/j8aMy52Q0GXt7YPEbG7oKz1p6SuR5dI+GuE6cti5Tsh 9p6UXd+W5cl19obwQra2tRQnIUpPIDoqI6iRUpGmz+76fAduDDkEW9l9mGiG4FtErWkqU98T pFJwnrO3kBsUV69fNFWhb1IRIlx34kJ+Sy5FkuMKS4hpRSSUKBIzz2nIPLI5Vw7afc6bvyR8 XTlsiPNPoaecfad4qHpEl15wKCFoA3rUSUhLjmEk4BWSBk5pdtOWy97uzmnjvaLLnBkus8Vv n0F8NSd6easBWQNysdZzx3Gbc9M3a9qtr3FttqsjE5xqfJekLXhyWpSEFSiQpYTjiKKtuxI2 KGNsoNRJZ1jqSCufbVLhWyPKbackqa4Y+F3h3KlBIHQUVhAIS4jIVhNO2n16jdjhresNrkzX Jb8NDrjqSlxDhKm15TsKi2TsKijobsbtvRzjlWuLpy2RHmn0NPOPtO8VD0iS684FBC0Ab1qJ KQlxzCScArJAyc12aI1I7qO3SXJD7D7zLu3fGaQG9pAwNzb7yCrOcjfuAKcpAKSqH1JqefY9 ZXBuO+wW02qM+1FkcRXZLock/wAHZAwlLzuAAclXQGG3ADtdtPuN2OEmzZrawzJZRCZLcrfx wtO7iha1rUlWc5SVOOHB5DccDnVS9095qOzpR591tplvUcRa3HFBKUJAWSSTyAA75qzDWclU +Fa2m4i7s7c5kZ2KrejhtNokLYK1AK4ZcS00oEg7kqUpKSByg4srUifczg3Tib5l3dt/FC7o 4QUvrbStaVcLcypfE2lCOi2Ok3hQwq1+z4nMyTq5jGEz3XaY8p7H7SZ+9Tuu0x5T2P2kz96u K86nvmmJtssseM2+6uOhaBLktLMp1S1DsZt511kkowlO/Y6shaCpOfj2CwXK/XV52U+m2pt6 JsuIG0BYd2tPONpc3EkZ6ASUY8K94/i6vbU5lN6yM7rtMeU9j9pM/ep3XaY8p7H7SZ+9Uvrm 4rtGhr1cGpDDDjERa0qfUpKVHHJAKFoUFK+KkpUCFKBGTyMXqHWotl5tDMWdbVw5aEPHYtt9 95tSsAtt8ZtRBHxS2l4qOQEZSAt21OZN6z47rtMeU9j9pM/ep3XaY8p7H7SZ+9VzfLyY7qo7 bbj4QS2hxZQlSscgVAEgZ7+DjwGvO7JeLxb9EWq8T5jEZy78Fb02bJXJjRgplThfWFcPh71B LfCSsNpKkbeZIU7anMm9ZI912mPKex+0mfvU7rtMeU9j9pM/erFp1JqS+T3Y8Ju1JbjxG5Bd dS5iXl+Q2kt4J2NupZS4leV7AocnQciyaluT1m0rd7pHS2p+FCekNpcBKSpCCoA4IOMjwinb U5k3rK53XaY8p7H7SZ+9Tuu0x5T2P2kz96sXDVN4tcx23z3bVEc/g7q7gtCzGgtuiRgOZWnf hUcNhe5sKLyeiCNquNWorqq72G6yblEh2tyPLZX/AAVxaJq0vtpQWgHOa3m0lbKQFkArxxM5 Dtqcyb1nb3XaY8p7H7SZ+9Tuu0x5T2P2kz96uaPrm7O6ouUFUSC3Hh9klxuTIaYVHbaCtr7i uKpzhrIQf4hICXQrcoJBXMaI1I7qO3SXJD7D7zLu3fGaQG9pAwNzb7yCrOcjfuAKcpAKSp21 OZN6zg7rtMeU9j9pM/ep3XaY8p7H7SZ+9XXqzU9y05Hu77VuckNs2wyIS0MKWkvIDpdDqgQl CEpDSuZSVZUE7lchFz9aXhp+4twUQZU5vsxDdnQytUtjhIdLTzmF5U24W28DYj+UN4UeW521 OZN6zp7rtMeU9j9pM/ep3XaY8p7H7SZ+9UvZtTx77qG5RLe+xJgRYkZ1uSzkpcW4t4K2r+Kt I4SRlOcK3gnIIFf90fU8+0267xIj7ERSbUt1lS+IHpS1BxKuApHNKmQlLijtVyWnJbHTp21O ZN6zp7rtMeU9j9pM/ep3XaY8p7H7SZ+9XFdtd3KALq4yq2uPxUTf+iy2rsiKlht1Tch4heS0 4WkYGxHJ9GFHlunEPXi6u3fT82SxElGIw+JMELBZbfU6hSEknJcSGlbXeiMqSeGNuFO2pzJv WcHddpjynsftJn71O67THlPY/aTP3q+75Km2LVViUm6txbKmE8ytElp2Qp90LZ2thXEy4+tI Vs5KX0XOS93KyX2VMg6eucy3R+yJzER12OzsK+I4lBKU7RzOSAMDmadtTmTesrHddpjynsft Jn71O67THlPY/aTP3q1T9fK7FusuDw24cdDCI8p5lK0F1TroVuUXm2wgtIacQVOIyHmzzLiE mPhe6DerjaZ90jx7aIlsthnv7srVIKHpTakI2LKEhYjbgrcsIzj4UHcHbU5k3rJXuu0x5T2P 2kz96nddpjynsftJn71b7JcZ7Gtr7brldGHEuy98KEIzgdDXAaIcB3qCWQQtBO0JLu7pAq2V 2a4cuTGnUP2ya3DW1NirfecbUtKGQ+jiFW1acICcqWScbErBxncHbU5k3rIzuu0x5T2P2kz9 6nddpjynsftJn71arrraTEQ2uLMtqwmEmQzxWFpN5d3LSWYgKwQSW04I4uQ+2QCMFd0nyew7 dJlbmE8FpbmZDvCbGAT014O1PLmrBwOeDTtqcyb1lQ7rtMeU9j9pM/ep3XaY8p7H7SZ+9XFF 1++7o6dcVy4ipbMhDSH24zRjpCsHClplqaB5K+M+gglA25UgL2W/XV0uFljymoTC3ri05Hty m0721S231sqLhQtQ4ZGx0BClkIbfO5QQCXbU5k3rOnuu0x5T2P2kz96nddpjynsftJn71YtG sLtcdcybOqEwiOy68hxkraS8w2gkJePwxcUlZCMDgoGHUncQAV2y3XSJdUSFw1uLQxIcjLUp paBxG1bVhO4DcAoEbhkZBGeRp21OZN6yqd12mPKex+0mfvU7rtMeU9j9pM/erHuga4d0fwFs lg7WlvusvpQnjpTjCG3FvN9LkQdiXVDKSU80heter79Fjrnrt8SWwubcIMWFFSvjuqjiSpCi rmMqEfZsCTzUFBX9AO2pzJvWbe67THlPY/aTP3qd12mPKex+0mfvV96Rvcm76qvSXLlEuEdi FD4MiCFpjulS5O5aEqKgDyCCUrWCW+ZBBQnZqQ3iZrKz2mIrhQXIj8lbrU5bDiVocZTvwG1B ewOZDayULKjuHRGXbU5k3rNHddpjynsftJn71O67THlPY/aTP3q4rtru5QBdXGVW1x+Kib/0 WW1dkRUsNuqbkPELyWnC0jA2I5Powo8t10tnbj4Xtt2Cd2Ft9ibxsznLZ3fG28vhBt3ZPQRj m7anMm9ZWO67THlPY/aTP3qd12mPKex+0mfvV1ydS22za6uMe73uJBYVbIa2G5cpLSSriyQs pCiBnAQCR4E571BqJLOsdSQVz7apcK2R5TbTklTXDHwu8O5UoJA6CisIBCXEZCsJp21OZN6z k7rtMeU9j9pM/ep3XaY8p7H7SZ+9UUx7oN3kWiG5DREnS3rn2K4tiOFIbZLDjhWkMyHg4tHD Ki2F71ABO1JWhRvlklTJtnYkT4/AkK3ZGwo3pCiEr2K6SNyQFbFdJO7aeYNO2pzJvWVjuu0x 5T2P2kz96nddpjynsftJn71c0fWGorjqi5WeDCgoeZ7JQ2zJW2lTGwKDTzmHi6ptag3y4KOi 6CFEAFfRN1vINjnXeOz2HERwGY6pscbkvnpPBzc622lKQpLfScTh1DiOatqVO2pzJvWZ7rtM eU9j9pM/ep3XaY8p7H7SZ+9XFG1azdhoe5yJzcN+Zc5URTSJgS3JSlt9vOxK1IWC4hkjmvaV pAUc5VIDW5bnwoD6W+zFXOYxLjssOOOMx20SFtK2pyQtaWm1JB5rBUUAjqdtTmTes+O67THl PY/aTP3qd12mPKex+0mfvVXka2vOoLLcERZ8Fl63S7fIemsoQpsMLfIWFBmU4EpSGypZLgyg qBSkdM2ibqVpudo4m6wVM3GW4ypWFsdkKDLgDjQLnNsrCQAQ4lXFbKTnaou2pzJvWaO67THl PY/aTP3qd12mPKex+0mfvVxXbXdygC6uMqtrj8VE3/ostq7IipYbdU3IeIXktOFpGBsRyfRh R5bpxGp12h27jU78GMzAiMTlvs7ghtDqnUhrnkuKBawFAJ37wAhJ5F21OZN6zg7rtMeU9j9p M/ep3XaY8p7H7SZ+9VzYfZlR2pEd1t5h1AW242oKStJGQQRyII55rZTtqcyb1lI7rtMeU9j9 pM/ep3XaY8p7H7SZ+9V3qie6G2h6XZkLGUnj5GfMinbU5k3rNnddpjynsftJn71dNwuMC5+5 3qF63T4k1lMOSguRX0upCuETglJIzgjl5xVSu1hi25yIC2MLRsd6XxXeZxnd4OX60+erZMhx 4PuW3VuM0ltK7W84rH9JRZJJJ79apo1pOYZtqTaMS8r9079N3vm6PrLpT3Tv03e+bo+suldW Fp0T/IdDfOpn1ZNehXaa7CvFn4FifnqkurjOS2dn8DbKdxUoqIO0lCcgcjt76tiVee6J/kOh vnUz6smr1qBenxeLA3fJjCHlSybdFfKdrkkJ6KwCM7kgkJ543ODkVbMUdESa73UXG3JsT8eO GmpJufQDclxQ2FPI7ioJQkZPPCeeBsK2q7hMtGkrtc4BYEqFEckoD7ZWhWxJUUkBSTzAIznl nPPGDzxF6fXrm4huYw/qJERoOtqKS5HjZylCcDkkqJWes5WnJxwwGs5tiiacca1G9w7bMdah uASSwV8RYTjcFJO0DKlYPxEqyCMig47zqO4W682ixR0tu3CTHU+68YEhTDhQpCNgKN3CClLJ LhKw2ANyVbkmrBdrkzZrNOukhLimIUdyQ4lsAqKUJKiBkgZwPCKh2bppxu8wkGW2H2ITLcKW 9L3JfblKO1CFqUS6tRig5OScAgnJqQl3m1Fc+39vIkaZHjqdfCZDfFio2g8VSVZCQApJyoY5 jOQaDjm6vgRLw/aGWn5tya4IEaMWypa3EurCMqUkJUEMrWdxT0duCSoCtada21UC6y+BLAtc IzJTZQncnat5C2x0sFaVR3EnntPIhRBzUfY9K2iQiZulW2QtpaIm2yIMJENTSnFbU8NxS23c yHQohYyFYIGVbui76f0WlES2XfsRnstCozUd+aptUzKs4UN4LywtwqClblBayoEKVkhYLtcm bNZp10kJcUxCjuSHEtgFRShJUQMkDOB4RUXcdYWy3puSs8ZNvaadeWh9lCDxHXGdoW4tKQpK 2lghRGOoZPKuyTdrDJRKhSrhbXUCO6uSw68hQDKVFtwrST8QKCkqJ5Agg1W7X3DXLSQvUeQx HgOcJ12Wu4Ft6M4U8kreDm5tz4VW4BYJU84TkuKKg6GvdHs8hhUiNGnSI7UQTZL7KEKbjs73 ULUpYVtVsUyvIQVFQ5thYyRIWS/Tbnfr7b5FqfYYt8vgtSSW9ihwml4OHCrceIVDogbSkHCs iuNm26LhwHYSZUTgXeOiMri3FS1Sm3lvLQApSypRWpx8hQOVZOCdvKYftdoiz3b7IQ2y40gu OPOOlLSMI2l0pJ2BYR0eJjds6OdvKg59V3qXYbSzLhwHJri5saOW0FHJLjyEE9JaRkhW0c/j KST0cka7hqxi2Z49unHgREzZ+3hHsFlW7pOdPpfxbnJreegeXNOeM6s0zqDTlvlLkNu2+5L2 KWHkjsRaWFSfhFJV8EtCW85BylW0jHWEm26LCLWh+VEaRMQERU9sVIFxSpW7C8LHZQUpwkhe /JdUTnechZJ86PbLdJnzHOHFitLeeXtJ2oSCVHA5nAB6qg39XiII6JlhvLEqTIEdmMWm3FOK Lbi0kKQtSMHhKByro8ivak7qnJ/Yfa6T2x4HYPCX2R2Rjh8PB3b88tuM5zyxVTsMjRciwxdT x5zfY7S0PmXPuSnVxnFNlAbdcW4raUpfUOGVYBcJAyc0Gy7e6RZLG6w1ckvxXltcZ9p9TTS4 6NykklK1guc0L/iQ5nbkZCkFXY/rS3sand09wnHLgEEstNyI6lPrDfF2BHE3oJSD0nEoTy+N zTnokt2CdIbvCpzaVxo7cpUiPPU0ksZUpC3diwFtcnCN+U/Hx1qzF2ruRumr5qYMjddrVLcU qMm4LLaXC2A46hgOFA5vKSpWwHeV555JDXD1+0xoW1agvsJyE7NQylDanWW0vrW1xCpClO7E IICyOItJ6OMZIBslkvMPUFnYucBe+O9uAOQcKSopUMpJScKSRlJKTjIJBBMPdLHpqyWOXKkM djx2trgcE1TC2inKUNtOqcTwU9NSEoSpCBxFDkFKzMKuFrtXY8B+4sMuDhMtIkysuLKtwbGV ncpStisZyVFKusg0Ef3YWxOr+5lw7JyuTZ47Kt6uHxMbErLieiCcrQlPLr5pzs1Zfjp2yCWh pxx12QzFb2x3HghTiwjepLYyQnOduRuICQQVCjun7HCn9vHuIwYq3JW5c11MdlRQoOOcIr4S SQtZKtvWpRPMk1H91mmb/YbTOXIbdgTZDa93GSBFdabMscYpVhBQGckZODgHkTQc89hi4ytO G7wnFP3Ja47zjHFZafQlpx1DbzRcQrCglSuG4l0Jy4g/G3GUXflwL5f27k6wi2W63sT0uIZV vbQrjBzdzO/HByNqR14wcZK6r01OmWGVPujCXi6HrUU3FTIfWoAAoSlYDuQsDqVyWR1KOeO3 PaUvWrL+2w+3JuiUdgz4zkwuodaSlJIDBWU7ElwoJ2jCi4O+ch2aY1hbNVdlJgna9F2F1vjs vYSvO07mVrRzKVct24YyQAQTYKrd3tlstmk5sJ9y5Ow5S0suNqluSHXy6pLYZSt5SikOEhHx kgbycpPSHZEu0CO1aYKI3YK5W5mPBc4bK2g0k7gEFQ3JTtCfg9w5pIyg7qCPtmpZV11fcrdH Z2Q7e6Y7oehvoUohtC+Il4jhnmsJDeMlPwgUU4BM6xQmzwpkiBOcfm3CRAaissJ4iXW1PdBQ Dik/9SUle7bnpHYnO2Qt0iGjUd6t7MJ9iUOBNkOrIKJHEQW0qThRIwI+0ghPxc4OcmHh9yNu 08q52mR2yiW6W5LbMe4LmLMpaFJKEFTh3OL4pAQTzU5nG5WaDsk6zhRJtrhyIctiRcFhCW5C mmC2rfsI+EcTxCFZ5NcTltIyFoKtlkv02536+2+Ran2GLfL4LUklvYocJpeDhwq3HiFQ6IG0 pBwrIrXdmbBMkW9V+kuQ5E1CWmrfJuimkvnIy0plLnDdOVhKhhQOQOYxUp2kt3bjtr2P/C+v dvVs3bdnE2Z28TZ0N+N23o528qDZPuTNuXDD6XNkqQI4cAGxtSkqKSsk8gpQCB4VLQO/UWnU yJL9jMZh8RbnLfYQ+ptKkKDaHVJIO8EJWG96FgLBSOYG4EdHbDT+pLdwWrjBnRX3eClUeUlW XUjiAIUg5DiQneNp3J27hjGa45belHpFpQ7OiMLtshLcBlieWEodJW0lAQhYCj8G62EkH4ri cfGFB0QNUwrhqWZY2W3EyIiCpalutAnBSD8Fv4oHSGFKQEkYIJCkkxcrV81rSbF3jWt999y6 pgrjFDaFtDsvgKB+G2lQxtCgsgqKVEBOdshcIFpsDU/UshE6QqG09MUlyY6+EYSoqLTbiyhC tu5I2hOAopyASK12626Xbtcizw5Tb8d2a4haFXFby0yh8IsJWpZWh0FJcwCFJIK+RyaCwMOK ejtOrZcYWtAUppwpKkEj4p2kjI6uRI8BNU+VrC5sxNaOC0ONdo0PKjPu8MtLKI7bqUrCXCsl RWVDAA2EAkKyKlDdrXYmIkC3Rn5aVcZWyF8MtKW1gPurJVlakrWNwG5xSlHoqO6uOXCsF51F PhP2mXIK0KiS5CSrscOrYGUqSFdF0sLA420dFQRxMkIoOh/WcKNAnypEOXHMNDTqmZSmo6ls urKG3AXHEpQFFK+itSVjaQUgkA8cTW5ul6srVqtr8u23CJIdXIbWyeGtt5tpXPigFKCpW4pC t2UFBUM10SV6OvbTt2VdILqVbWTOjXHYUFlLjmEuIWNikoceJ2kHYpWejXRH0vp2VZ4bTDPZ EEb3mnBLcc4yXlcRYU5uJdbcJ3KSoqSrlkHAoJx95MaO6+sOFDaCtQbbUtRAGeSUglR8wBJ7 1Ue0arkj3OZeoEQG2oceEl+KxHgraMdHD3bOG6pCXUNp2niIWkOAKCUpIGb5UW9p62P6aGnl sOC1iOmLwUPuIPCSAAjelQVjAwefMZBzk0Gu7XCZBvVgYZLBizpbkaQlbZK+TDrqVJUFADBa wQQc7u9jnHw9fWSdqhVgZdzKDrjCFcVo73WworTwwsupxsX0lISk7eRO5O6Uk6ft8tdrW/2W pdrWFxVdmvAhQTtyvC/hDtyCV7shSgfjHOyLZYUG4vzYyX23HtxW2JLnByo7lKDW7hpUTzKg kEkqJOVHILpeYdnVD7NXw25Tq2g6ogIb2tOOqUskjCQlpXP9Xe5iPGpkPzLS3HYfSzNuEqCp xbaSAtgPAg9MFO4sqIUEq5JwQkqBEpcrVBu8dMe4Rm5DSVhYSvw4IP7CkqSR1KSpSTkKIPGr S9pV2s+BfT2sdU/G4ct1GHFZ3LXhQ4ilZVkr3E715zuVkIOVrC5sxNaOC0ONdo0PKjPu8MtL KI7bqUrCXCslRWVDAA2EAkKyKsFqvjN1kSI4iy4r7KEO8OU2EKWysqDbgAJKQooWNqtqxtO5 KeWdc/S1mub8l6ZD4ipTS2nk8VYQoKQW1K2g4DhQSjiAb9vRzjlUgiDHbuL09LeJTzTbLi9x 6SEFZSMdXIuL9PmFBDzbheH9Qv220mC32HEZlOCW2tXZHEW6kICkqHCxwT0trnxx0ejhXQdR xVTHobMK6vSm94CBbX20OKSCcJdWlLXPGASsJORz51suWnrZdpCX5jDilhAbWEPuNpeQCSEO pSoB1HNXRWFDpK5dI5kH2UyY7rCy4EOIKFFtxSFAEY5KSQUnzggjvUEXElW7UT7MlqO+4iA7 xWJDiFNpDxQttaQk4UVJStSVApwFKKfjoUE8824Xh/UL9ttJgt9hxGZTgltrV2RxFupCApKh wscE9La58cdHo4VKQrVBtq3FQYzcYOIbQptnoowhO1OEDoghOE5AzhKQeSUgc9y09bLtIS/M YcUsIDawh9xtLyASQh1KVAOo5q6KwodJXLpHIazqWAJj0Ux7rxGt+4i0yig7ASdq+HtV1HGC d3IDJIzx6Lv03UtmTdJDTaGJCEOspEd1lTe5IUWzxBhwJBTh5B2rycJTt52Sot6wQXdNDT6E uM20R0xOEhWSWAAkt7lZOCkbSfjYJIIOCAlKVrYYZix2o8dptlhpAQ222kJShIGAAByAA5Yr ZQKUpQK1vsMyo7seQ028w6gocbcSFJWkjBBB5EEcsVspQKUpQKqmqG3HdR6fSyltTv8ACFI4 hISFBCSCcc+RGcd+rXVbvn6W6c/4n92KCuS7DeJEdxMq/wAEtnpLJwnqOc5x5s1PXTHvX3HD gdHad3DgBAV8CeeD4ai7n/NUz/cL+qakJv8Aonm/3Kv9waDyn3Tv03e+bo+sulPdO/Td75uj 6y6VBadE/wAh0N86mfVk16NdLfLnz7Upl9uOxEkGS65w0LcVhBSG0hSSEhQWrcsEKAG0fHJT 5zon+Q6G+dTPqya9aqiLYt8salmXN19tEdcduM1HbbQSvaVK4i17QvOVqSlAUUgZVzK8J2Xq 2dt7YYoe4LiXWpDThTuCXGnEuI3JyMp3ITkAgkZAIPMSFKCpy9FquCLy7NuDb0+52ftWZXYq QWQVPKUUAHOzLqQEZzhpO5SjzqPl+5q3KXdkKuThjzETFRkLU+oxnpKXAte3jcIgcZ0ABtJw oZUTkm+UoIuFZGbfeZE2Pw2mHIUaG3GbbCUtJZU6RjHLGHcYwMbfPyh9RaIbv95E1U1xth+O iJNjFx9KX2UqWdo4TzYyQ44CVhY5jAHPdbKUFbh6RZhLhraebSti8Srq6pLASXlPJfTtVz60 peSNxzkNgYGeUe9oWS7YYNs7eOJFrW2LapDa2g2httbQ4hbcS4tZQ4oKUlaASlOEgbgq6UoK vZ9EW61yn33W2JXZFvTCdS62pzdl15147nFrUUuLeyUqJ+KMlXetFKUFTiaLU0zY4su4Ny4d lkNuQ2FxUgBDTLjTe4kkl0FxKivkMtp2oQckx8n3NW5MtxxVycUxKW8mawVPtpeZckPPbBwn kDOJDiSVhYPIhI5hV8pQKpb2hZLthg2zt44kWtbYtqkNraDaG21tDiFtxLi1lDigpSVoBKU4 SBuCrpSgqadEpRFhNtS20OQUFxhRZU6DJU6HXHHC6tS1oUsJOwryD0txWltbcpHs0iJfpc1i 4bIct0SX43BBWt0NJaHTJ5N7UJO0J3bhnftympilBF6ktT1801crSxJbirmx1xy8touhCVja o7QpOTtJxz5HB59Ri7lpDtr23flSmOzrlZE2kvoi44X8aVrSConaoupOzP8A1YyT1i0UoFVO JotTTNjiy7g3Lh2WQ25DYXFSAENMuNN7iSSXQXEqK+Qy2nahByTbKUFDvfuezbpaX7cxqByO w+uYpxJbdCR2Q844cJbebCiA5tPE3pO0YSnKgqyR7NIiX6XNYuGyHLdEl+NwQVrdDSWh0yeT e1CTtCd24Z37cpqYpQQ+pdOw9T2xqDNaYcbblsSQHmQ6Pg3EqUnB+UkKQT4FnrHI67jYXn5V gVbpESFEtMji9j9iFQWnhKaCEbVpCAEOLxyPPbywCDOUoK3O0u9c7pfXJc9vtfdrYm3KYajl LraU8TpBwrIJ+Gc/ofJ8B3bNMaaVYeyn5MrsydJ2IW/vkK+DRkoTh550jBWs8iB0urv1YKUF bvmm5t1vMadEubdvDaEpWtlt0PrwokdJLyUKAydqXG3EglXIhRBmLtbWbzZp1rkKcSxNjuR3 FNkBQStJSSMgjOD4DXZSgp8vRcy6PrnXC9bLmdiESLfHMdLbaUPt9FJWtQc2yniF7sBQbO07 SFax7nzPYt7SuY2qXdbY7BVI7GGWVOuyHXVI6WdhXI5Iz1NpypR51dKUEffbZ2709c7TxuD2 dEdjcXbu2b0FO7GRnGc4yKr6NFSGX2ZrV0YTPh8FuErsEJZQ00h5tCXGkKTuVtku5KC2nOzC UhJCrhSgp9t9z6BEulvuE1TFylQuyyH5MNviLW9JD6F7hyCmzvAwBzWogJziugaEs5VqVRjs NuX7iIdfYjobebbcaQhaQvBzlSFOc+W5WSCeZtFKCl2/QDbMqFMuEtubLjTUSlOLD7gWltp5 LSMPvulJSt9SwoHrxyzzqcnQboiZaxZJEGFBRLW7cGVxtxfQoKJ2kEYUVq3E98ndk4KVzFKB SlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBVbvn6W6c/wCJ/dirJVbvn6W6c/4n 92KCGuf81TP9wv6pqQm/6J5v9yr/AHBqPuf81TP9wv6pqQm/6J5v9yr/AHBoPKfdO/Td75uj 6y6U9079N3vm6PrLpUFp0T/IdDfOpn1ZNQGpv9PTH94QvqtVP6J/kOhvnUz6smr5K0Xp+Zf0 3yRb99yS4h0PcZwdJGNp2hW3ltHe71ctbTnUiIjl9L+GfbKfZb3teJnNZjxzOE9SlK7PmlKU oFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKU oFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFKUoFVu+fpbpz/if3YqyVW75+lunP8Aif3YoIa5 /wA1TP8AcL+qakJv+ieb/cq/3BqPuf8ANUz/AHC/qmpCb/onm/3Kv9waDyn3Tv03e+bo+sul PdO/Td75uj6y6VBadE/yHQ3zqZ9WTXrVeS6J/kOhvnUz6smvWqoUpSgUpSgUpSgUpSgUpSgU pSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgUpSgU pSgUpSgUpSgUpSgUpSgUpSgVW75+lunP+J/dirJVbvn6W6c/4n92KCGuf81TP9wv6pqQm/6J 5v8Acq/3BqPuf81TP9wv6pqQm/6J5v8Acq/3BoPKfdO/Td75uj6y6U9079N3vm6PrLpUFp0T /IdDfOpn1ZNetV5Lon+Q6G+dTPqya9aqhSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlK BSlKBVbvn6W6c/4n92KslVu+fpbpz/if3YoIa5/zVM/3C/qmpCb/AKJ5v9yr/cGo+5/zVM/3 C/qmpCb/AKJ5v9yr/cGg8p9079N3vm6PrLpT3Tv03e+bo+sulQWnRP8AIdDfOpn1ZNetV5Lo n+Q6G+dTPqya9ZKgOsiqM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM 0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5 Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6 abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/ KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpo M0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG 5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh6abk/KHpoM0rG5Pyh 6abk/KHpoM1TtZtsPXqxMynHG2HOOham1bSAUpHX4OfPzZq4bk/KHpqsaqs0q8TraqMWghgO lalqwOe0Acsnw+iggJmndNwWXXXkT8N8iEqBJOcYH7eVWG8paR7ml0SwFBlNpdDYX17eCcZ8 +K4rlp243FELe9HKmkku5Uo71jklXME9XX1c67b4kNe53eo+9CnGLY825tOcKDJ5egg/tFB5 F7p36bvfN0fWXSnunfpu983R9ZdKgtOif5Dob51M+rJq1e6FMmwNMXGXAmOxJLER19txsJJC kJ3DkoEEHGDy6icYPOqron+Q6G+dTPqyatWo4UvUFzkWdtu0PsssNPOx5qFr3JWpW1RG3b8Z pWBzI25OMiqKxe7teLc+Cm7TexYcRLzzzPAWpOCrc5JQraotkIyAzhRw4Bjo1xTNT3qHEVde 2ygl2XOi8B9OY7KWEyClfQTxCfgElXSV8ZWAOjixuaLurvYfEg6cX2FjsXc0o8DGMbOj0fip 6sdQ8FfaNI3pq4OXBuNp9E11OxySltYcWnlyKtuSOQ9A8FBE2e93puTMiyjdZK2kNOJakrji QkLLgKiW1BrZ8GAOe/IVkY21MKvFwSlBEC4qKhkgOtdHmRg5c82eWeuuG0WWfGipRZ2bExHd lOslMWM8hHFbKkL3bUADBaUnccAkAAnKcy3aPVH9ZZ/S79lTDcWiPh/f92k3afxlo7DnlKd2 HOK3tVjOMdPPPvZA6+eK+ReLgW1K7AuIIIARxWsnOef8Zjljw98efHR2j1R/WWf0u/ZTtHqj +ss/pd+ymPmdce2P6/ugbrf7qw46luW7GD0UbuIQo2871J469u4FJBzgnHwfeTxFI4Y1/vbU e73aTKu7seCqatLalx0x3UtOOJSgEAug4SOZ76T1jkZ6bZbu0+0zL7RFy5HsRIUh1XGwhxzY ro9W0OHny6++efPI0RLj9k3By1abU5scW643DW44sEHfySgqUVAkYGSc455r001dOK4mPr6+ suc+Zy5U63kLjyxwlJmMKShDPHcWHVcRxtQTsQpZIUw8eSD0UhRxlQSj61mTY6no0ZW2MyXp okSiyW0hxxB2bk8zllz4/D5bc4ydsvJ0le5iHUSo+n30vJShwOoWoLSkkpByOYBJI8BJrSND 3JKIqBb9NBMRRXGAZVhlROSUdHonIB5d+nXo4/D9fX18Dy+Y+o5rl+dt8hp2M2MhlxxxwF1Q 54HQ4ZyncrCXCrA5pBCgndZLpd5kFx24llp5Mh1tKYskup2pWUjJwOfLBHm5hJykYj6Nu8SY 7MjQ9Osync8R9tpaVrycnKgnJyedLbo682eMqPbmLFGZU4p1SGg4AVKOSer9nmAAHIAVi1tP GKxx/v4nlF6h1bdrRNcYixX5TYipdU8ladsYlzbucysdHBKue0fBq6WNym90nWEiDLnpnMvs RorLjqFlbm97YncQnKA2SUhSgA4TgcwMKCZKRA1BEfiMvyLOhyW6WWB8Md6whThHIcuihR5+ Dw4rXH0bd4kx2ZGh6dZlO54j7bS0rXk5OVBOTk861F9PGLVMS4X9UXiLIjw3oSFzn3ktobYu G5ASpt1QUoqSlQALKs9Hq5p3EFNfF31jNs8Zt1+M6paG1Oy2m3XHFNIST0k7EKGFbVFJcLec c8YVtkYujbvBbQ3Eh6djoQ4XUpaaWgJWU7SoAJ5HaSM+DlSdo273Th9sIenZfDzs7IaW5tzj OMpOM4HopF9LqjNfH18zyi29U3KFJ1A9dHECDCeWGeHJJdUEx0O7EpKUgkp3r+NkHI5gbqTd R39ibb4pZQmW5KCVMsTQ4hxtTL5TuUpKVIAU3knb1J6O45TU13MX/szszh2Lsrh8Lj7XN+zO du7GcZ54rTF0bd4LaG4kPTsdCHC6lLTS0BKynaVABPI7SRnwcqu5p+vT8P8ABiVfna7uzO/s aA+8Esq4y0OpKIriHyytSiVp3I5KUCQjIQTkDeW7l2TI/r3f+c1zNad1Iygoa7SNpKlLIRxA CpRJJ6uskknzmvvtHqj+ss/pd+yuepetvFa4IbuyZH9e7/zmt0y7txo9tiv3Nq3mVxVrlvLQ khCDjCSsFO8qUjkQeiF9RArj7R6o/rLP6XfsrrRF1i1CMZp2yt9EhLg4hUknPMZBGRnvgiuU +jppzEWzMZdlpkvt2idOfdk3BhLjjkU8JHGdaSkDkEJSlW5SVFJHWlSefPlLSpEWFHXIlvMs MIxucdUEpTk4GSeXWQKrSbZqZNvjwAzYexY/C4SNz/R4ZSUc85OClPX14511/wD4y/7B/wDn UiJiFvatrZiP/HLGuSY702e1eXrtaoUJbr6wlhSS51hKFNoSCoJQvcCeW9Hh5LXLfm3OD2Pf m7gdqnZ7cYsuRmhtxsSpKN4JWoFO45KULySRzzFh6uiKkLQqyKckPF5xai7knASOrkAEpSke ZPPJySah6uanSJm6yKefShBKi7hKE52pAHeypZ55OVHngADPTLrOrTziP7ft/Xx8EXe7lO01 aX1zrmqZLbG1LuwNBxZ+KNiTjlkZx3gTVd0Fd7lM7YdlXGW/s4e3ivKVjO7OMnzVPag0dqLU i0Kmv2xASd2xlx1KScAZIIPg+k1ps+hL7Y+N2I7bDxtu7iLcPVnGOj5zVz5xh5ZvM28x/bH1 /J9X+7XmL2vZtbyTIlSFNnipLnRSy66QlO9AKjw8DKgOfMjrrlcud9TCaks6jhyA+rYw23aH Qt1fPKAlUoYUNqtwVjZtVu2hKsSE/SOo7guKp2RbUdjOqcTwnXUE7m1tkZAyOi4rmkgg4IIx WtWh7qriYjWJvehDfwRdb2BO3bs2gbCNjfNOD8E3z6CcaVusV0uM2ztvTZCVSQ9IZcUxuShR bfcaBSFEkAhAPM9+pDsmR/Xu/wDOa4IOl9SwInY7b1qWniuulSy5kqccU4rqSBjcs45dWK6e 0eqP6yz+l37KDd2TI/r3f+c1H3u8TLbaXZTLqtyVISVuKJQ0lSwlTisEdFAJWeY5JPMdY6u0 eqP6yz+l37Kdo9Uf1ln9Lv2UHNFmzkXJ6I5OfeQzFYUFrIClKJcClHaAMnaOoAeACspuk3tl NZKnlBlhtxtKHc79xX3iBg5Tjmojq6udal6KuriGkrg6bUlpAbbCmlEIQOpI6PIDwVtVpS+K edeUxYC68jY4soXuWnqwTjmOQ5HwVnEu3VT+n7fNHr1ZKZjNrdQsOrf4Rb4ridiShSgtW9CS E5ScnGAATzwRUtBuciZDbf4jqd2eQcJBwSMpPfScZB74INcqNH3xosdjoskdLLpeShkLQkqK CjmAnwK+gV2do9Uf1ln9Lv2UrFviattKYxSMI2Tdp0OddHlTJDrEaEmQmOVAJz8JnnjP/Vjr J6z5sa5t+uyG1NtJLUlLsc7VyCRw3HNoBIScK6JBAyADkE13K0pfFPOvKYsBdeRscWUL3LT1 YJxzHIcj4K2L03qJzib02RXERsXuDh3J58jy5jmeXnNTE8tRqacTEzXPp/j/AGj5Wp5Ud9LL bb0laWwt4MLcc281JKUlKCCQUKHS2dQ8+OiNfJrxddcQtmI2462p5Unq2KUCojvJ6PXnIPex 0q2K0pfF8DexYFdj44OULPCxjG3ly6h1eAVuRp/UraSlBsqQSVYTxBzJyT1d8kmrEWz5lLX0 unFa+UWxqia8vsbgupmKWlKELccQggpWrJK0BQ5Nr6kkdXPrx9Lvtz7YxRxG0Riw8qRul8kl C0JUchJ6snGSM5OdpFdCNG3ZtlxlEPTqWnccRCWlhK8cxkbeeK3K0xf1NstqbsRQyUqaSUuY bI6ikY5Y72KmLfGWpvo5+7Xx/r82l29yYsq5F9x7gxYyHwEO53J6eeWBg9AjrI6urnWlzUNy Zktw3GCqWtaQEtyiUYUlwglRSD1tKyMdXMZPKuxOmL+iUuUluxJkLG1ToS4FqHLkTjJ6h6K+ WNKXyMlKY7FgaSle9IbQtICsYyMDrxyz4KuLcsxfSx5r9Y/P6+TilX6chqBLZfd3Ll9huQ9+ 7iEubFqSevKNql56ihK8gclI6DfrmJLrXai7FCN+17jMbV7QSMfC7ulgAZA6xnHPG9OmdQId S6lFjS4kLCVgOAgKIUrBx3yAT4SBW7tHqj+ss/pd+ytQ42xMzj0R41DdSwtw2O8BSVJSGy/H 3KBByR8NjAwM5OekMA88F6huqENqTY7wsrTuUlL8fKDkjBy8OeADyyMEc85AkO0eqP6yz+l3 7Kdo9Uf1ln9Lv2URBC9Xd3Rt4mNzlJmsquCWHVrShKC266lvJVhIACU81cuWT3602y9XyG/M jyxeLjKSll1LHHjFTbSy4EkkBpIVltQUkFYHR2qOTiTa0LcGLgbgzbdMtzSpSzJQwoOFSs7j uCc5OTnw5NboOkb1a2FMW+Np+I0pW8tx21tpKsAZwEjngD0UGleobqhDak2O8LK07lJS/Hyg 5IwcvDngA8sjBHPOQImFrKbI1A1HLsrhSJsiEGTHdS23weLhwPEbVqVwlZSDyCk4wUKK7N2j 1R/WWf0u/ZWhOl7+nh7WrCOG4p1GEudFat25Q5clHcrJ6zuPhNBAOXm8o9z27zBeJXZ0Ps7h ysI3HguuBORt2cwgA9Ed/qPOpyderlEfS2xbbnNSU7i5HeZCQcnl03EnP7Mc+utKNC3Bq3uW 9u26ZRCdVvcjJYUG1q5cynbgnkPQPBXYzp3UcdhthgWRpptIQhtHESlKQMAAAcgBQcxv1zEl 1rtRdihG/a9xmNq9oJGPhd3SwAMgdYzjnj4GobqWFuGx3gKSpKQ2X4+5QIOSPhsYGBnJz0hg HniQ7R6o/rLP6Xfsp2j1R/WWf0u/ZQR69Q3VCG1Jsd4WVp3KSl+PlByRg5eHPAB5ZGCOecgf Zv1zEl1rtRdihG/a9xmNq9oJGPhd3SwAMgdYzjnjt7R6o/rLP6Xfsp2j1R/WWf0u/ZQaIF3u EziceFcIOzGOyHWzvznq4biurHfx19+tTBKvc+1mSSSTOJJ/3VdnaPVH9ZZ/S79lYkWmXaPc 81Q3NWwp5+PLf+BJKRua6uYHfBoPMfdO/Td75uj6y6U9079N3vm6PrLpUFp0T/IdDfOpn1ZN XaZDv0XVUu6WuHbZbEqFHjqTKmrYUhTS3lZG1lYIIeHfHUa8501d7ZH07YFdvoEGdbnZDmyQ niDpKdThSQtJHRXnr8FWfu7Hlbp31Ff5iqO9jSlyY1AqcyLay+mRIkdtTuXIlJcDnDYeQAkl psuIwOKciOjATkbIO2e5/eYbUlD7Fqegl1h0WhbyOxpJSl5K+IG4raBzcaWDwlklhIJGElPb 3djyt076iv8AMU7ux5W6d9RX+YoN9v0fdbajTA2W2W/a7nMkvynHnEr4T6nhhG5K1EkPJUoK X1tgFSs7gXoqTCjrmQg32zVNuD77rTq+K6w8JKm2UK3IIAW4yooC2070lQUFdI6O7seVunfU V/mKd3Y8rdO+or/MUHf7nMZMW1yUdqHIbiVhJeU0psOp5kJShTDBSElSjhLQRlZUCpanMa/d A0redS8A2tcFDjDSww88UNuR3TjDiVqYdV3kkcMtKBTncSRs5O7seVunfUV/mKd3Y8rdO+or /MUH3J0A/Pvzbs1uC7BMuU5Le4rokTWX2n0JQvGAOEHQ2nJUdmSkt80K6LjpC6XHSV+iz3YN yvNyiIhpefHDaCG04QshKThQWpx/knkpewKIQlVcnd2PK3TvqK/zFO7seVunfUV/mKCTvem5 93uLU12DapLi4jbIEp9w9rHQVlT0dSUBSlHenmCyr4FHSBI2c9o0VNg65k3uTL4janXnkPIc bS46Fk7WXBwA4W0BWAC8oZabISAAlPJ3djyt076iv8xTu7Hlbp31Ff5ign0zdXnSdxkLtFtT fm1vCHFTLUppxIUeGVKKRzKeeOWeWS3uIR2TZOoEP2UQ7dBcbddxcyqUodjo2E5bOwb+lgZI GeQwAoqRVO7seVunfUV/mKd3Y8rdO+or/MUGLhoK6zLsX2JcSGvsiY6bm2tzsp0PMvoaKgMD LHFShGVKO0dFTfNCtjWglyZ0RyRbbVbbaiWh161W91RYUEsyEKXybbClLL7aVJKcFDWCVA7R 8d3Y8rdO+or/ADFO7seVunfUV/mKDmne5zc5cuJumt9iNLdbaQ062hUBoyHVoVHLkdwpWGlt pAQWtvBQAogJKfTK887ux5W6d9RX+Yp3djyt076iv8xQeh0rzzu7Hlbp31Ff5ind2PK3TvqK /wAxQeh0rzzu7Hlbp31Ff5ind2PK3TvqK/zFB6HSvPO7seVunfUV/mKd3Y8rdO+or/MUHodK 887ux5W6d9RX+Yp3djyt076iv8xQeh0rzzu7Hlbp31Ff5ind2PK3TvqK/wAxQeh0rzzu7Hlb p31Ff5ind2PK3TvqK/zFB6HSvPO7seVunfUV/mKd3Y8rdO+or/MUHodK887ux5W6d9RX+Yp3 djyt076iv8xQeh0rzzu7Hlbp31Ff5ind2PK3TvqK/wAxQeh0rzzu7Hlbp31Ff5ind2PK3Tvq K/zFB6HSvPO7seVunfUV/mKd3Y8rdO+or/MUHodK887ux5W6d9RX+Yp3djyt076iv8xQeh0r zzu7Hlbp31Ff5ind2PK3TvqK/wAxQeh0rzzu7Hlbp31Ff5ind2PK3TvqK/zFB6HSvPO7seVu nfUV/mKd3Y8rdO+or/MUHodK887ux5W6d9RX+Yp3djyt076iv8xQeh0rzzu7Hlbp31Ff5ind 2PK3TvqK/wAxQeh0rzzu7Hlbp31Ff5ind2PK3TvqK/zFB6HSvPO7seVunfUV/mKd3Y8rdO+o r/MUHodK887ux5W6d9RX+Yp3djyt076iv8xQeh0rzzu7Hlbp31Ff5ind2PK3TvqK/wAxQeh0 rzzu7Hlbp31Ff5ind2PK3TvqK/zFB6HUNq/9Cr9/d0j92qqr3djyt076iv8AMVy3LVrN0tcu 3v6vsCWpTK2FqRCUFBKklJxmQeeDQUn3Tv03e+bo+sulc+vbhCuurXJUGS1IZMdA3tqChncv ly79KYTKtnqr5pSksFKUqBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKDKa+qUqwFKUqhSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSlKBSl KBSlKD//2Q== --=-=-= Content-Type: image/jpeg Content-Disposition: inline; filename=2001_05_11_093947_shot.jpg Content-Transfer-Encoding: base64 Content-Description: move to bottom: window shrinks /9j/4AAQSkZJRgABAQEAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CADMAgUDASIAAhEBAxEB/8QAHAAAAgMBAQEBAAAAAAAAAAAAAAYDBAUHAQII/8QAYhAAAgED AgIDCggJBwcICAYDAQIDBAURABIGIRMUMQcWIkFRU1WSlNIVMmGVodHT1BcjNlZxdIGRsjM0 QlJisbMkNUNUcnXBJTdFc4OEoqNGZWaCk6XD4SZjZJbC8Ha04v/EABgBAQEBAQEAAAAAAAAA AAAAAAABAgME/8QAKxEBAQACAgEDAgUEAwAAAAAAAAECERJRAyExQQRhE3Gh0fAiUrHBFCMy /9oADAMBAAIRAxEAPwClaLVbJ7RTTVFL0k0m8sxmkHZIyjkGA7ANa8li4YoaAVtzQU8JOF/H zEk/IN2TrHt83RWWgGf6Eh/86TU9TX01S1KtUlO6wbh0dQBsYNjsJ5Ajb4/KdBYW18MVMCz0 MQnhY4DdPMOfkxuzr5+BrN/qA9ol9/WZLW0wqRDQrToGkEjinUbECggDI5Endzx5BrbtVyjp qiRnZFZo9sbvuARsg5JTwhyBHLy+TOgr/A1m/wBQHtEvv6Pgazf6gPaJff1tx36jDqssgKtP l9iNtx+KBbBJJyqyDPacnIG4jUdNdqGKiRJZEkiTo2ELdIz7g6l+R/FgY34xzwRntOgyPgaz f6gPaJff16LJaGDFbfkKMsRPNyGcc/D8pGtCO6GOqjaS6JPIFbErLIVXOOW/k47D2D6GbHwK 7e1yaK5iNDGOTggz8wMchzPbzIBOckDLYCktktDuqJb9zMcACeYkn19fclgtUIUyW3aGAIPW JcHIB/r+Qj9+oaeuENTFKwLBHDFQxUnB8o7P0625+JxX1sMrFIGjjIDtv2kkLkeCdy8w3NeZ GAeWdBjfA1m/1Ae0S+/o+BrN/qA9ol9/WmbpEd4iuBixKzSMyEmdcKAMAYfsb4+3O7Jxk4r1 F3WWaGJpWNGI4VkVFGeSqGIz/S5EZ8nLONBXjsVplYqlvBIUt/OJewAk/wBPyA6+Pgazf6gP aJff1tSXyJZadxWJ0pWaN5IWlO0MoCZL+FgNk4GcYyBnVWO5RpEyJcijCVnmcox6wCF5Y/pc w3J8A7vFk4CpJw/akmSL4PDO6qVCzzHO4AgfG7eY15JYLVCFMlt2hgCD1iXByAf6/kI/fq98 ORBzukLxRwQdHGMrmRej3cwOTYDjd248fZqO88QfCzQsY9hjXBIJwSQM8snHhbufjGM9mgpp ZLNJIqCgGWOP5xL7+tWThbh1TOEt5JQrEmambwnPafj6xoKzZUROTyVwfp1pLcAs2WbktYsh 5+LQNUXc+4TWJRJbWZwPCbrUwyfX19/g/wCEPRTe1z+/rz4V/tfTo+Ffl+nQe/g/4Q9FN7XP 7+j8H/CHopva5/f158K/L9Oj4V+X6dB7+D/hD0U3tc/v6Pwf8Ieim9rn9/Xnwr8v06PhX5fp 0Hv4P+EPRTe1z+/o/B/wh6Kb2uf39efC39r6dHwt/a+nQe/g/wCEPRTe1z+/o/B/wh6Kb2uf 39efC39r6dHwt/a+nQe/g/4Q9FN7XP7+j8H/AAh6Kb2uf39efC39r6dHwt/a+nQe/g/4Q9FN 7XP7+j8H/CHopva5/f158Lf2vp0fC39r6dB7+D/hD0U3tc/v6Pwf8Ieim9rn9/Xnwt/a+nR8 Lf2vp0Hv4P8AhD0U3tc/v6Pwf8Ieim9rn9/Xnwt/a+nR8Lf2vp0Hv4P+EPRTe1z+/o/B/wAI eim9rn9/Xnwt/a+nR8Lf2vp0Hv4P+EPRTe1z+/o/B/wh6Kb2uf39efC39r6dHwt/a+nQe/g/ 4Q9FN7XP7+j8H/CHopva5/f158Lf2vp0fCvy/ToPfwf8Ieim9rn9/R+D/hD0U3tc/v68+Ffl +nR8K/L9Og9/B/wh6Kb2uf39H4P+EPRTe1z+/rz4V+X6dHwr8v06D38H/CHopva5/f0fg/4Q 9FN7XP7+vPhX5fp0fCvy/ToPfwf8Ieim9rn9/R+D/hD0U3tc/v68+Ffl+nR8K/L9Og9/B/wh 6Kb2uf39H4P+EPRTe1z+/rz4V+X6dHwr8v06D38H/CHopva5/f0fg/4Q9FN7XP7+vPhX5fp0 fCvy/ToPfwf8Ieim9rn9/R+D/hD0U3tc/v68+Ffl+nR8K/L9Og9/B/wh6Kb2uf39fE3A3BVN TS1E9tZYol3Metz9nr6+vhX5fp1RvFYK201VKWO2ZChx2jkRn6dBkQ0fBEskTvw5URUczhIq h62XDH9HSZHZ4xpkj4D4MkQyfBrbACSetz8h6+khzNU0dPSVUltjhicGSSJ1LMo/qRDmrnn4 gBn9zRT3KRqGdnBBmLvsz2bjnGgw5e8JZZHj4dq3oY36N6vrU2wH184+XxaaqfgXgyqQPHbD tP8A+sm9/SUhmitD25aumUA7UkdowFTlkFD4THGc+Cc57dMtpuHQU8vRlxEVWOLd27VQKCfl OM6DLuFPwJR3BqWn4crKsI+x5IqmcgN4wPD5n5Bz7Nb1DwfwRcaaOop7aWSRQy4q5+w+P4+k 8pNTT1KQPSmKolZ5OnqxCyhs5GDz7SfCGeXLHl3bBOtFDHDFKXhghEQkIx0jZLMwHkyxx8g0 CVxnaqOy8WVVFQRNFTKiFUMjPjOfGxJ8WjV7ulDHHNT8sKH6W0agxSKiem4foaacQSVlQlN0 pTeEElS65xkZxnOMjs04Sdymr3MknGcJKnBBtBPP/wCLrFgtMUNt4Huglmaaa9wxlGI2Koq2 7MDPizzJ7ddI4ruU1otlfXU6xtLE42iQErzcDngjy6oUF7ldSgwvGcC/os5+119/gxrfz1h+ Zz9prTq+IZqQKUr6Gt6SKdkNPTnbujj34ZulOPF4j+zt1NFxZTLRpLUQykxwQSVckSjZCZQC ORO49viB0GN+DGt/PWH5nP2mj8GNb+esPzOftNPeluW+zC+3Ghe4W2iipuj6M1KEtJuXJ/0i 9n/EaDI/BjW/nrD8zn7TR+DGt/PWH5nP2mtmu4nCVUEFHEzA3FKKWSSM7D/XCkHkRkdvbzxn BxDScTVFVUWNI4Okhr+m3ydGEPgEjwRvOMYyck5HZz5AMz8GNb+esPzOftNH4Ma389Yfmc/a ae9K/fHWfBH8nB8J/CHwf8U9D0m7t7d23b4+3Pi0GZ+DGt/PWH5nP2mj8GNb+esPzOftNa9L xbTyUEUpinqJTTyVMgiiWPZGrlSxDOfIeQJPLxasT8VW+nhqZWWcpBFFOMIAZY5MAMgJBIBI BzjB0GB+DGt/PWH5nP2mj8GNb+esPzOftNN9Jcoa2srKeFZD1VwjyYGxmIyQpB5kdhHi183i 5JZ7TUV7xtIIgPAU4ySQBz8XMjQKX4Ma389Yfmc/aaPwY1v56w/M5+00wvca+2NAbp1aVKgr FH1VWVhMQTswxIIOMBsjn2gDmCLiakkkiVqepjD1Jo2dwuEm5+AcMT4hzAI5jn24Be/BjW/n tD80H7XX0e5pcDu//G8XhAA/8kHnj/tdabcWxSVtvMKMtBOKh5JpYzzSNSdyYPlDciM/IMjO pa7zFdVVoqapjR4xIkkiqUcZxgMpIBBHNSQfk0GEvAt6VQo48iwBjnZgf/qa97xr3+fkPzKP tNNU4maFhTyRxy/0WkQuo/SARn9+l2lv1WlLca64zUy0tBUyU7rDTtvk24AIJcgZLDlj9vjA V+8a9/n5D8yj7TR3jXv8/IfmUfaa1H4mpI2lilp6lKqOeODqxCl2eQZTBDbeYz2t4v0ZqycV R9fo0Vejpy9SlWJUy8RhTcQNpIP7M6Cr3jXv8/IfmUfaaO8a9/n5D8yj7TW5a7zFdVVoqapj R4xIkkiqUcZxgMpIBBHNSQfk1cq6lKOjnqpAxSGNpGC9pAGTj92gV+8a9/n5D8yj7TR3jXv8 /IfmUfaauRXuvijtdZWJTGluMixrHCG3xF+ceWJw3Lt5LjxZ1NRcU0df1boaerBqkkMAdAOk ZPjKDnGcc8/F8WcggBm9417/AD8h+ZR9po7xr3+fkPzKPtNSW7it5qO2VFcqwCpFQzlItylY gTkHfleXlBJIPZyJtPxdQw0zzTU1XHtp0qVRlQs8bsFDDDEdpHIkHnoKPeNe/wA/IfmUfaaO 8a9/n5D8yj7TWlNxVb6dZ+lWeOSGWOIxugViXGVPMgAEAnwiCMHIB1qUdV1uFnNPPAyuUaOd NrAj94I+UEjQLPeNe/z8h+ZR9po7xr3+fkPzKPtNa3EN1mtVPRvC0CdPVpA8k4JVFYHLciOz Hl1TpOJsVMsNT0dTF1uGlgqqRcRyNIucc2Pxcc8E9o5aCr3jXv8APyH5lH2mjvGvf5+Q/Mo+ 01auHFDJCBQUkjym4dQLSBdquMZwNwznxcx8pHj+W4knprhcVrI1jpLbGnTOseWldhy2+H4O SRgENyzkjQV+8a9/n5D8yj7TR3jXv8/IfmUfaa0KjiygohIKuGpgeKdIZUZVYpvUsrHaSCMA 9hJ5dmiHiqmnnaFKC4dLGFaaIwgSRAnGSmdx8R8EHAI0Gf3jXv8APyH5lH2mjvGvf5+Q/Mo+ 003ay6G5TVN9u1C6xiKj6HoyoO471JOeegxe8a9/n5D8yj7TR3jXv8/IfmUfaatUfFtPNTUo 6Kepqp4nmEcMSo21WI5KznJ8E8gWPInA1Yn4qoaaapSSGrC03RGaTosKiyYwTnmMZGRjd5Ac HAZveNe/z8h+ZR9po7xr3+fkPzKPtNN2jQKPeNe/z8h+ZR9po7xr3+fkPzKPtNN2jQKPeNe/ z8h+ZR9po7xr3+fkPzKPtNN2jQKPeNe/z8h+ZR9po7xr3+fkPzKPtNN2jQKPeNe/z8h+ZR9p o7xr3+fkPzKPtNN2jQKPeNe/z8h+ZR9po7xr3+fkPzKPtNN2jQKPeNe/z8h+ZR9po7xr3+fk PzKPtNN2jQKPeNe/z8h+ZR9po7xr3+fkPzKPtNN2jQKPeNe/z8h+ZR9po7xr3+fkPzKPtNN2 jQJveBdt27v4gz5fgQfaak7xr1+fkPzKPtNN2qtyqXo7VWVUYUvDA8ihuwkKSM/u0CueALsz bjxxAT5fgQfaakHA16AwOPIfmUfaamTiyNpLOOnpGSop5Jq3ozuaErHv5AEkc88jk8tFx4uW G1TzU1NJHVLTx1MSVKgq8buF3eAx8vYSDzGgrNwBd3OW45gJ+WyD7TWFxbbbvwlZhWji+Osk MiIlOtpWPcC6qTuLnGN3kPi/SHROJ6J6owGKpUCsNEZGjGwS+IZzzzg9nZ48ZGVjutfk/B/1 i/4segod00Y43m/V0/ifRo7p35bzfq6fxPo1BYX8k+5//v8Ai/8A9t9OvF1JLcaKroI4J36d +bxBDs2uDzDOuc48WlOht1ZdOFuBoKAQNVJdHqUWeQojdFLLKVLBWIyEIzg9umeaxd0WaeSX pLCm9i21ayTAyewZp86or3C1y3+eKSSOeh6CKaMCVUff0qFMja5xjt59uq68HIj7hUQPuigj kaakWRh0ahSU3EhdwAzkNq73u90Xz1j9rf7vo73e6L56x+1v930G3pXWK7U93r6+ko50650e 5JYYn27FwMETj5dXe93ui+esftb/AHfR3u90Xz1j9rf7voKw4ZaSZJhWSRRG4LcTA8Slg/Lc pYH92OzJ+NyI+qXhc0lLakjr2E1vMu2URDwlkzu5EnBGRg8xy5g9mp+93ui+esftb/d9He73 RfPWP2t/u+g2ZGKRsyozkAkIuMt8gyQP3nS71afvg+FPg25bNmer9JFt6XG3pP5XGdng4xqz 3u90Xz1j9rf7vo73e6L56x+1v930GdFwUsEFOqVUEksVO8BaopBIuC5cMqluTDcRzyPk1oVn DFLWVFK0jZhjp+rTR7cdNGCCo8HAXDDPggZ7OzXve73RfPWP2t/u+jvd7ovnrH7W/wB30Fuz 2z4Ko3jebp55ZXmmm27ekdjzO3JA5YHLyamuNvgulvmoqkMYpRg7TgjByCP0EA6zu93ui+es ftb/AHfR3u90Xz1j9rf7voKlxtd0mkt7VFVLWimnjm2U9PHGCUzktukBy2fEcDB5dmqvwTVf 6jXf51+Eviwep/K/T9GtXvd7ovnrH7W/3fR3u90Xz1j9rf7voK1Jwo1HNQFLlJ0VD04hURLu Akzzyc+EM9uMHA5Dnm1arC9vuVRXy1SySzxqkixRdEjsDzdl3EFj5Rgczy56873e6L56x+1v 930d7vdF89Y/a3+76DVqZpIIw0dNLUEnGyIqCPl8JgPp0tx2aSqt9zts9NWQpcKl6npmEWIi SGAIEhJ5qPFzz4u3V/vd7ovnrH7W/wB30d7vdF89Y/a3+76CCXhh56iaslrV669TDUqyw4jB iGFBXcScgnPhDxeTmQcLmGtgrOvsJknqJ5CkQGXlUL4IJO3GB27s6n73e6L56x+1v930d7vd F89Y/a3+76D21WF7fcqivlqlklnjVJFii6JHYHm7LuILHyjA5nlz1oXABqOSJqSWqSUGN44m VTtIIPNmX6DnnrO73e6L56x+1v8Ad9He73RfPWP2t/u+gzoaCuHUYaqjrp6OgcPTxBYEbK8k LsJee0cuQGfHnXzwtYp1orRV1kksbUYn2U7xbWVnYg5PbjAyBjOT24wNafe73RfPWP2t/u+j vd7ovnrH7W/3fQUo+DlVaSF7hI1LTJURpGIwG2Sgg+F/WG7txg4HIc8/M/Bz1VI8U9wXeKOO jjZIMBURw2SCxyTgeMfo1f73e6L56x+1v930d7vdF89Y/a3+76D2SxymtuVVDWqhrTFujeAO m1FKlWBPhBgfFg/LqxY7SLLbzSrM0oMjOBzCpk/FUEkgD5SeeT49Vu93ui+esftb/d9He73R fPWP2t/u+g84hpamt6mlPTzs1PUJUrIixspK58EhpEPj1nx2KprqyeqqVnp6x6iGpWVo4+iB iG1V2LIzHILZ5j9nj0e93ui+esftb/d9He73RfPWP2t/u+ggj4XKRqrV7ORdBcS7RDLf2Tgg ftA/ZqSt4ZSua876plFyEXJU/kzGOXj55OPJ/wAdffe73RfPWP2t/u+jvd7ovnrH7W/3fQQD hcFom6emiMdZFU7aajWJMID4OAc8ySckn5ANTXjh+S71CM9dsiR0ePEX4yEg8zG4Ixnl8YNz GfJj3vd7ovnrH7W/3fR3u90Xz1j9rf7voNvSusV2p7vX19JRzp1zo9ySwxPt2LgYInHy6u97 vdF89Y/a3+76O93ui+esftb/AHfQUm4RkNigtJuEbwRowIkpsjcWLB1wwKsMkdpBHi7dVRw7 PXXO9Ucs9THSSCkQyyJuM6ooyQxx4WV7eY5nIPLGv3u90Xz1j9rf7vo73e6L56x+1v8Ad9Bt 6NYne73RfPWP2t/u+jvd7ovnrH7W/wB30G3o1id7vdF89Y/a3+76O93ui+esftb/AHfQbejW J3u90Xz1j9rf7vo73e6L56x+1v8Ad9Bt6NYne73RfPWP2t/u+jvd7ovnrH7W/wB30G3o1id7 vdF89Y/a3+76O93ui+esftb/AHfQbejWJ3u90Xz1j9rf7vo73e6L56x+1v8Ad9Bt6NYne73R fPWP2t/u+jvd7ovnrH7W/wB30G3o1id7vdF89Y/a3+76O93ui+esftb/AHfQbejWJ3u90Xz1 j9rf7vo73e6L56x+1v8Ad9Bt6o3hJJrVUU8cEspnjaL8Vtyu5SN3hMoOP06pd7vdF89Y/a3+ 76O93ui+esftb/d9BnSWiasFpp5qOujio6d6Z3/E+EHjEZblIcY7ew6+jwaGtk1GaqmjLwRw iSGiVD4LBizHJZido8YHjxq/3u90Xz1j9rf7vo73e6L56x+1v930GZbLFPVVVU9TJLBDFeZK tImix0mPispPiOefbnAxjmTmd1r8n4P+sX/Fj0zd7vdF89Y/a3+76wOMeC+NK/h2qluUlmMF JGahjHVSFgqEOwA6BQSQmOZGgye6d+W836un8T6NHdO/Leb9XT+J9GoGngn+Y8DfrVZ/DU66 VVTSQysUcjLY8oHIeL9uua8E/wAx4G/Wqz+Gp10ev+P/AO+f4V1y89sw3HTxzeSpLelg6fpq 2GPq8Qmm3so6OM7vDbPYvgtzPLwT5NT9dqPOf+EaUeIuDYOI7gtbNW1MEsECx04hmkRVcSrJ uYK43DKJyXaeRO7IQpRPCt0kvl4q4ZKa3iugmhWrjkE067hhWDdEkikEK2DK6qF2qANpTyTO 2f8Ap24zo+ddqPOf+EaOu1HnP/CNIcfBpqJaMT2q026iirBNNQ0EshjkUQzIScKiksZUDLsG VQhmcEKI+LODq+40tLTWMUcEdLFIKUyMqvSyMchkdopWCjwdqxmIptwD8XY5Zb1yNTo8wXk1 M1VDDUbpKWUQzDZja5RXxzHPwXU8vLonvJppqWGao2yVUphhGzO5wjPjkOXgox5+TSi/CUsV zvkttW30JuqyMbjFERVQs8SpsXbjlvUS7t/Mkjbk79QR8GmoloxParTbqKKsE01DQSyGORRD MhJwqKSxlQMuwZVCGZwQocr/AHU1OjrLelg6fpq2GPq8Qmm3so6OM7vDbPYvgtzPLwT5NL3G nE90szcOmkmUCsvUFHOrKMNHIHB7OYIOCCPGB2jIOPN3PRXxoauvmhkpelWhSmnlWOFDVGaM EKy5VVWFdq7cBThuUZQ7pP8A6If/AOS0f/8APVmVtk3tLJr2PnTzedf1jo6ebzr+sdR6NcuV 7dNRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1Ho05Xs1EnTzedf1jo6ebzr+sd R6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1Ho05Xs1EnTzedf1jo6ebz r+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1Ho05Xs1EnTzedf1jo 6ebzr+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1Ho05Xs1EnTzed f1jo6ebzr+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1Ho05Xs1En Tzedf1jo6ebzr+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1Ho05X s1EnTzedf1jo6ebzr+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv6x1H o05Xs1EnTzedf1jo6ebzr+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOjp5vOv 6x1Ho05Xs1EnTzedf1jo6ebzr+sdR6NOV7NRJ083nX9Y6Onm86/rHUejTlezUSdPN51/WOq3 EDs/AfEBZix6hUcyc/6I6l1DfvyC4g/Uan/COu/09tzc/LJxch7p35bzfq6fxPo0d078t5v1 dP4n0a9rzGngn+Y8DfrVZ/DU66Be7rQW+4Wmjqo6xpblUGnhanp2kUNsLZcgEKML/efiqxXn /BP8x4G/Wqz+Gp10a6Ui1VfaumuUlLFHUGRYIpmiaqlCEqhIYbkCh2KYO7aCeSsGWTKaqy2e sU4K23VHEtZYUSuFXSU8dRI7QMIirlgArkYJ8H9vPGSrhY+KJZrDw9WXajpI6zqcT1E0U1SY fxaIzNtIjfLcgACAOfaNaEFIvfLWVclykln6vHGlEszBIIiWIdo9xBdmDjeQOSBR2MWj4ra3 Lwldlu8s8NtkpJIqmWCNpHjjZSrMAqseQJOcEDGTyB1j8LDprnl2xO+CkoLtJbL8kdFVR0kV Uxp5nqECvJKpYnolKxoIlLSMAq9IASOROmKu3C6XSjmn6FLbTxTzyTFowqvvO4lkCFAEPhKx 5hgdu3nTvy2CSnrp7lV1dOl+ti0Ug6JlaKBRITIVKExBesHc8gCrld2PHqfAJF8uF2jutdHN W0iUvRqISkITcUZMxk7gXc+EWB3nIIAAfhYdHPLsW00V1p2np1rkRXKEVVLJTtnAPJZEUkc+ 3GO3yHWZW320WziGe018rw9FSQ1QlGX8F3lVmYKp2Rp0YLSMQo3jJHLN/hrhai4Xp54aOSRx M4ZsxRQqMDHKOFEQHytt3HkCSFUCO7cI0d4uNTWTVldF1ukShqoYZQI56dTITGylT8bpWBYY cAeCy5bL8LDo55dh7jYoqeOoluHRQSVE9MJJMqokhEhlBJGFCiGU7jgeD28xlEvV2sXE/CFJ e6urWigprjTVFtnp7lAR07co0mLowjdA++VNrhV5gvhgHuPhGjivFNcFrK7bS1ctZT0nSjoY 5JVkEpxty24ys3hElTyUqpKmwnDdHHw5brGJJ+q2/qvROWG9urujpuOMczGucAdpxjVniwl3 IlzyvyU0mSKjpZa/jC8wyTRCZ+r01HUwxRkkCVpY6UqkLYLLI+wFQSQCrBbFH1S4XFqCl46v Mk6yyQH/ACKkCCWMsHi3ml29INrNszuKjcBt562L5wPZuILzTXSugjeeJFjdZKaCZZo1YsEP SxuVGWbmhUndzJwuNCyR0NKldQUM0kpp62ZqgOOaSzN1grnABGJhjGeRAJJB1rjOk3S/fLZU 2Ox1t0m4tvJjpYmkOaWkI5f1tlIzBfKwU4GTjA0VVCaO4wUEnF/ED1U20hILdSzbAxwrSFKU iNSQcM+Adrc/BONzimno67hyrt9fWz0dLXbKJ5YAC/451jCjKsBuLhc45bs5GMinduDqe+VF vmr7jVymhRQmYabczAgs4k6LfG7YGTEyYwCu0jOnGdG6jn4eqKWnlqKjjO6wwRIXkkkhoFVF AySSafAAHPOleyXP4Vs3ws/Fd1WkldBTdTShq5JCy7uiaOOlLrOqjc8YVgo5hmAbb1DWH3r0 yWG02unq6unNpSNaOrQoZYykZi3eEpQkozKcqR4RIAIBDjOjdK711rSVYm4+vIkMQnZOo0uY oyzoXkHVfxaq0bq5fAjIw+0kZ2K+yTWy3VNfWcY3mOlpYnmmfq1EdqKCWOBTZOAD2a1LPw3R 2SqnqaeSeSaoiWOZpWB3sJZpWfAAwzPPITjC9gAUDGrl2tsN5s1da6hpFgraeSnkaMgMFdSp IyCM4PkOnGdG6SxPQvTvNHxxfJArqqpHb6Z5JtwJVokFJulRgrkOgZSEcgkKxFc1am/Wu2w8 UcSTJcKeWVZ47bTsI2SRI9jgUZ2kMzB9xHRlQGA3DTI9ltvEbwcR0VfVxS1NPTyUlVAFBjVV m2uqyIRlkqZFIcHkRgAjOpDwjRiCkSGsroJoOmD1EMoWSdZ3Ek4Y7fB3uAxMYRlI8AoOWnGd G6wz1Rayamk46vMXRbw08tFSJASgJdVmalEbMoV9yhiRsfIG1sXLbaZ7rTtPT8VcSIiuUIqr ZTU7ZwDyWSkUkc+3GO3yHVim4DtNDfKy8Un4irqelZZFpadnglkyXlSRojIWyW5MzL4RG3aA BJaLJauBbXVyLUSCB3VnPQxxgt8VVSKCNFLsSAMIXclVy2FAcZ0brPrKJKD4Q6zxteY/g+kF bVf5JRno4Tvw3Km5/wAk/IZPg9nMZp1M9DSPVLPxxfI0pUlaSY2+m6I9GpaRUk6psd1CvlFJ YbH5eCcScU2ePjGnjNHBSVFLc6d6Fp5GnjenYCTwpI1UrIYzuKpL0fRyKQGDP4NwcO2K53i5 Wmaqrp4affUSWyVDHDE1UsqvIkgRXfeHqB/KMqlmAClV2uM6N1IlkmkuM1AvGN5NVDFHNInV qLwUcuFOerY5mN/3fKNY/FEycL26snqOMLzJUU9I9SIerUYU4DbFeQUpWPeylVLY3NkLuIxp stPD6Wq41dwe4V1dWVcUUU0tW6nIjMhXCqqqv8oRhQAcA43Fi1e/8I0fEPWxNWV1KtbSdTq1 pJQnTxjeUBJUkbTI58EgNuIcMvg6cZ0bpfqZ6GkeqWfji+RpSpK0kxt9N0R6NS0ipJ1TY7qF fKKSw2Py8E4GD1Nrramz8VXy41ECAxUyUlIhnLZERUml5xOwwJhmPAY7sKSLFdYeH7hc6uxT 3Wu2z9ZKUahRDBPPHJ0pSXo+cxSaV+jZ2wrlgm0KQ0UlHTtdqq7xGcTTxJSOsiFABDJLggEA 8zI/PsI2kcuZcZ0bpLnFZQ8Q2qyVnEHEAqq2ked3pqGnnjicPGm3eKLBXLtlzt2hVLAbxrYr 7JNbLdU19ZxjeY6WlieaZ+rUR2ooJY4FNk4APZrYutjhutRT1BqqulnhR4ukpZAjPC5UyRkk EqGKIdy7XG0bWXnmSb4Ov1LdLTL+PhXdRVsXhL8eJWK55dqSKcg+PtyNOM6N0t1dCaOWqik4 v4gealiimligt1LM4SRmVCFSlJbJR+wHGMnA56z3rrWkqxNx9eRIYhOydRpcxRlnQvIOq/i1 Vo3Vy+BGRh9pIzsSdz61TUFXTSVFW71Tq8s0nRvuId5DmNkMTAySzSYZCA0mV27IwkdHwJZ7 TZ6yzpNXNDdaR7e7LGg2KWqJSQI4wkfOeQAkBeSKBnkXGdG6z7Qk92vd3tacScSRSW6o6HpH t1MqSAJGxO9qQKDmTAXJJADDKkHUnEtNU8N2yKtl4l4gnWSrgptkNFSSEdJIqFsJSMeQJIGP CICjmw00R2OGG9zXOKqq06Z+llpVkAiebYI+kbluJ2Kq7S2zkG27hu1Hemt1bZStbLPTwtVx RRyiNldKgTqsTKGXniUIQSCh5E5U83GdG6W6oU9D0HWeM+II+liWds22mPQRt2PNik/ELybn JtHgt/VbGpPw9UUtPLUVHGd1hgiQvJJJDQKqKBkkk0+AAOedSVXBtNVoySXK5EVFP1WvzIjG ui3O2yQshKDMsv8AJdHgPgYCqF0K670K228yNXyUyW1HWrnjjy1OREspYAqQxCOrdjDxYPMa cZ0bpbjpmltc1xXifisQRPsZGssKyk8vixGj3sPCHMKR2+Q4jXqjUdZVDjq89DRUnXKkmipA YosyA7l6rkMDDICmNwKEEA6uQ9zm0w2OptQnn6GeVZWxBTomV7MwLEIG7TktGxPgnOUQqUnC HD9tey2UyzvPSdYq6ZSFTpE6xHM4IRVRVWYwMAoX4igZXeC4zo3VeGCKouht0fGl8M+9o1c0 FKIpHXO5ElNLsdxtbKqxI2PkeC2NTvWrvztvPs9D920W7gezWziWovlPBH1iZ5JArU0BMckh y7rL0fS5OW5FyAGIAAAAOG6+3pa614rnV3KVHerqZGSZi+/LBoI2yTAdpEYj3KQuAWO4lxnR us+50Js/RGu4v4gjjkyTMtupZI4wMZaR1pSsajOdzkDAJzgHFOKot01RPCvH91XoHmjlkkpK NIkeIt0iGRqUIHUIzbc52Dfjbz1c424YsPElfbqK71NXDPWpLTU/R0yTK2ELsA0kTrC+0Mdy lGbb2tsXbqVPB1rrLdHQVPTy0q1dVVMhfG81AnEikgA7cVD4xgjC8+Ry4zo3S/Zw97vNdQUn FV8xR08EsjS0lJFIrSNKNjxPShkIEQYZ7Q4OMYJr3+aWy3mgs6cXV01wq0Mq080lugZkDKu1 N1N4Urs2EU7Q218su3ThaeH0tVxq7g9wrq6sq4ooppat1ORGZCuFVVVf5QjCgA4BxuLFrFTR 0/w5QXGQz9YSKakiCIWTEmyRi2Adv8gMEkDnjmSNOM6N0n1M9DSPVLPxxfI0pUlaSY2+m6I9 GpaRUk6psd1CvlFJYbH5eCcXLZRJeel6hxteZeiwTmko03K2dsi7qYb42wdrrlWwcE4Oo7pY eH6igv8A1y61y2yh601TTKF2Ucs0DPNKh6PezGOodsFnUdIQF5AK8acZ0bpLhtVdLxDW2nvo vI6tSQVPS9DQ+F0rzLtx1bljoc5zz3eLHOMUbi6XSjm4yusKW2ninnkmp6SMKr7zuJakCFAE PhKx5hgdu3nY4hFBR8QtWtxFdbXVTUkUdQKKmjmjSJHkKSTM0MghXLyeGxVSFb+qcbHwCRfL hdo7rXRzVtIlL0aiEpCE3FGTMZO4F3PhFgd5yCAAHGdG6V5JaWCihq6njLiSmjmqOqxLU2mC F5JdhcIqPRhmJCkDA8I+CMsQNalDZJrjRx1VLxjeZIXyATTUSkEEhlZTTAqwIIKkAggggEap p3N6CmS3U8DdLSxXDrdQrLHT4Ap5o1MawIirIHkVt4AfwR4XgIBuSXSx8MJDbmeSFETpH2RS zCJWYkyzyANsDNvJkkI3EOSThiHGdG6W6mehpHqln44vkaUqStJMbfTdEejUtIqSdU2O6hXy iksNj8vBOLlXQmjlqopOL+IHmpYoppYoLdSzOEkZlQhUpSWyUfsBxjJwOetC3cD2a2cS1F8p 4I+sTPJIFamgJjkkOXdZej6XJy3IuQAxAAAAGXbuHeFrzw9VWW2VU5phLHMxZA25QgjiYJKh SWHo41RHKurdHuBZ136cZ0bqvLDVtVWLqfFF1qKO6VEtM0xjo43hdIpJMGM0mc5idWDFSpGC CcgXI6JJerbONryes1ctFF/klH4U0XSb1/m3LHQyczyO3kTkZuUXBFLbqOyUtJcq6KG0VctX EqJAoleQvuDARYC4lkUBAuA3lAIkfguhkr46lq25LFDUT1MNLHUdHHE8ySLKQVAfLGV2yWJU /EKgkFxnRule43GOitnXIuJ+J5WFXTU7072mGOZBNIEDmM0e/bjfg7cMy7Ad3LWpPRTxVVng HFd8BujsIumoaaMgCJpMH/I8K+F+I5Q4DdpXabFr7nNptMFwjgnn3VnVyXSCng6J4HaSJ1WK JFLB2z4StnaAQRy1qT8NCd7O7Xa5B7ZUNUhi0bGokZWVjJuQ4BV5BtTaAHwoGF2uM6N0t1M9 DSPVLPxxfI0pUlaSY2+m6I9GpaRUk6psd1CvlFJYbH5eCcXLZRJeel6hxteZeiwTmko03K2d si7qYb42wdrrlWwcE4OrldwLQXCKrpp62u6jP1lkpFaMJBLOsiyyodm8sRNLyZmUbzheS4uX jh1ril2lorpV26vuFFHRiqg2kwiNpGVlBGc5lYHmDjG0qeenGdG6r961d+dt59nofu2jvWrv ztvPs9D920wQRtDTxRPNJO6IFaWQKGcgfGO0AZPbyAHkA1JpxnRulvvWrvztvPs9D920tcWU 18ss1BFQ8U3B2qek3dPTUZA27cYxTjynXSdJvGscUl4sSzyCOH8eXbyKFUnHI88DkPLjTjOj dJs0vGVO0Ik4lnXpoulTNHS8xkjzHyA/oI02mnuUHctvbXW5NX1E1BUShzFGmxTCcL4CqD5c 4zzx4hpevF5guKK8NDVJLG4MQMQAC9hXl4tvk8g033Rt3cvuLYIzZ5Tg9o/EnSSQ3XJe6d+W 836un8T6NHdO/Leb9XT+J9GiGngn+Y8DfrVZ/DU6euILL8LXiwTLbaGdqGrNSauri6ToFC4K xgMD0jEqQSCo2Fj4SoCi8E/zHgb9arP4anTtxI0/w3w2lLX3KKTrrNJSUKxETxBGDNLvwREp K5IzzdQBvKFaJKSy9Hxzcb2ttoadZaSKmNT0WamoYHcW3BsCMAquCoZivPwUTNjiu31l34Su 1soBAaqtpJKZDPIURd6lSxIVjyBJxjnjHLORTomnbug3TbX3KopFooFaArF1Smlyx2gjw+lK kMRjkrAsSGjCnHFvq7hw6i0c9XC8FbS1LmljR3Mcc6O5CsrbiqguFAJJQDDZKkCp4cluPFVn vtW0kL0lFJFNDT18wUSs8LqAF2h08CQNuA3eBlTgBdS+0KXPh650Esc8kdVSSwslOyiRgyEE IX8EMc8t3LPby0l1Qv8A1273q2tcozT2KnkhSeiXpbhNE9UVRhjADAqWRVWT8Yn8mQVNeuuv HQr+IBTpJGaenrHghEDupVUfq7Q/5NtaVj0JKmd/jONgPgoBFZbrxHdK25TiO5QFKRXpbjQS UFNVGPrQMXRyK7hF6aKUMwkBdcAjHgWKngq/JZLpRUE9tD3W2PQuJnfZRLvqHSOMBfDQLUdE D4GwRqwVv5MNFnN3gvNdRXCpkrIFp4KiOpanEa9K7SiSNNoxsURoQCWcb/CZsjWHxdX8WQcQ 0lNZV6OleJOhkKO0ck5dgyzbKeUiMDo+e6HkzYc4ygNF9tnw3w9c7T03Q9epJabpdu7ZvQru xkZxnOMjSnX8J3+5Ut1lrJ7bPU1yQQmB1Vk6KOWWULueJ1BUzBATE+4QhsK0n4uxSPxRJUQv U11WI6y511EY0o0XqlMpqDDPkqSXzHEAzeAVdQULHccOim4lsvc8ttvoY7q9VR9BT1s09Oqt TARENHAEgcyKrpGN/RSgrISHOCyBJRdzm5C014r5aSS5fBhprbJ07MtJMJqp4nGI0VTGs0Sq 6oCm1ggUciyWzhf4I4vuVzo6G1Rw3CU1E1UIsVIzGitCMAeCXQSlyxyWYbMnfrPtC8Y3GqCV d06lHHb4J0ZKLes0rSz4DmREJ/FrF0qBY23EbTEORdJ42mp5Ykmkgd0KrLGFLISPjDcCMjt5 gjyg6DH4s4eh4lsgo5aakqHiqIaqKOqQMjNG4bYTg7Q6hkLAHAc8m7Cv3Xg65XFIx1WzbzRL S05UsgsrBnxLSjYdzhXjGR0WTAh8HICZdntt5+AuELSkl1iqrdVxx1NVU0abaUihnjdIsKoZ VOAsrB0LSL4UmCupK668ddbpKenSSMB5YYZ5YHC1EiVEsatUBKaXCGNYXJBgB6RyrY/kw6Bd qOa42auoqerko56inkijqY87oWZSA4wQcgnPaOztGk+PgY1UtCJ7PZrZQRVonnt9umkMUqiC eMk4RFJYyorLsG5EIZnBCK8TxtNTyxJNJA7oVWWMKWQkfGG4EZHbzBHlB1zOim4lsvc8ttvo Y7q9VR9BT1s09OqtTARENHAEgcyKrpGN/RSgrISHOCyBocQdz2W4Xahagn6G2wxLCkQlRXof xjMZKcyQSlWw4ACGLb0SAHAXZJLwdc6nj74XqFtr2+V5EqwojVqmBoWjETp0G9wCY875mU7M hV8FVkSv4pW2UrSvO8j0geskgoy5gjMh2SRh0jL1Bjzvj6PAK7ginbFNYslNW2zja+rUTXWe O4VfWIkMEfVli6CJekMgQeEGjMQTcWwFYoRmTQY7dz64x8G09hpktVPDSSxExQIqrcdkbI0k 5eJ0DMSj7THJhoh4ZJDI6cOWprLw/R295ZJHiQ7t7q+0kltilUQbFztUBFAVVAAxjVPjk1A4 GvXU1neqNI4hjgpRUtI5GFQxlHDKxwrZX4pJyO0Zd7reI5ai6Vtpmq46Oks8NdSU3UPCqqnM 56I713AELGGjAD81wUOdwRrwreR3R47/AL6FKXpXM8kJSOSaLoWRI2UQb2w3Rk7p2UlNwVfB VNziuwniO0w0ayyRmOtpqglKiSHwY5kZxlCDnaGx5G2nkQCNieNpqeWJJpIHdCqyxhSyEj4w 3AjI7eYI8oOuZ2e23n4C4QtKSXWKqt1XHHU1VTRptpSKGeN0iwqhlU4CysHQtIvhSYK6Bsu9 jqZbtwvU0FNSSpaahmkmq6l+nWJoWiKqxRy5O8MdzDJjXJOcrHWWS8Vl84gkjmgoqW4WqOhp qyGdzPDInSkSbNqgc5zjD58Af1vBW7/f+L6C0070dJcpKymerUbaVmWt6OZki3rHTyHLKisc GBW6XwGxno9yyU1bbONr6tRNdZ47hV9YiQwR9WWLoIl6QyBB4QaMxBNxbAVihGZNBX4c4bu3 CtjujUkEBuVTtWnpEliNKjDIWRhHBTgc28MhSxWNQCSAunSATLTxLUSRyThAJHjQorNjmQpJ IGfFk48p0v8AHFLcq3h1Ka2NHvlraVJ0kp2mV4WnQSBlVlym0kuDyKBwcZyKdbTvZK7g6jgS d4Y6uRJ0paBpYIw0MgDglXMCh2VVAcBUdl5qp2hoWThoWq/X25tNO7XCr6WNTWTOioYolOUY 7Q29GwQOS7VBA8EYdv4JqZLNabbcqO2wUlFeKmtelpJ3aJoJVqCsY8BOQacKUI2sinPI7dWJ WqaXjHiyaz2uRrhJZ6doHkpHSCpqY+nwplIVGOJIR8bOOWfBOI+HILxxJY7pRcQTzvQVG2Ed Kjxzupz0qNvpoMRspVQVTd4T4cHG0C9cG1E12tMlnpKGOnt+DC9VMJRAekLYSF4X2qvLAikh JAC5UIhXQtnC/wAEcX3K50dDao4bhKaiaqEWKkZjRWhGAPBLoJS5Y5LMNmTv1T4hrLlaLzaK KzxVYoIkQGioKNlUqGwE6Tq8kWCBgKXg29pfDAo0XaSuhs1dLa4Y57glPI1LFIcK8oU7FPMc i2B2j9I0Fe+W2avp6aWjaNK+iqFqqVpCQpYAqyHkcB42kj3Ybbv3AEqNYb8LVlLPwq9LFQ1c 1sq5qitrJ3MUkjTI4maNQjY3vK0hXcqgoqjlgrnrduJYGE9tW63i3wyoSa+jWlnmdoqgGLaY kIj6Tqn4zZy3uSxVW2xtW8aSxXitSarjjpKJ66hpuoLuqn6eqMURyu4AwrAGjAEnNeaNu3Bq Wrhu40fHNbejBQw09R0is/SrPNIpIwNxgSReYU4MsiqBsVcbSlOHgiap4GNjuFssyvT3Nq6k pkYy04XrJnEWTGuwFWaEkKcKScHJXTBxpBNVcC8Q09PFJNPLbKlI441LM7GJgAAOZJPLGl+l vHEcFVFUVIuU1shqIzXM9t2yozRTiSKOJFLPEknVSrJ0nxm/GOoYgHC1QTUtrp4J4qSF402i GkUiKJR8VFz2hVwucLnGdq52hPuXAszS8Ui10dmhN9p5w1Y8RWdWkgEfReCvJDIolL5OSWGz J36ppQcQcT3i0NdoehoV+EZJKesomLwFatVhIeORVSboTiOVclcOwL7si5Far8l94rvaxUlT X07yJaVemeJ5P8mjMcfSmXDQbmYFMbTIGfKkYASXXgqoMF0pLRHQrQVkVNupajDdLKjytJI5 kjlXpGzCTI6SM3R4ODtdadDwHXU0VjrKims1XdrelRAr1a9IsCPOJIXRhGu4wqoVYwsY8Ngr Rgc47TV8a1yUcbVs8VPPcBDJUS0jNPHH1eZnJD00Cqu4Q7G2MA5O4uPA02T3lbA9nttzlq62 quFQ1NDUQ0bEEhWYGTYNqnaoyRgE7mCqobaGxPCtTTywOZAkiFGMcjIwBGOTKQVPyggjxaS2 4Jni7ksnCkSwVVdLb0p2NbVSyQrNsVS6FwxVVK7lVVABAwFzkPGjQL91orxXV3DVTFTUI6lV mprVaqcbcwyRFYz0fh46Vjk7M7AOW7K49o4KraHjmpvdTV9JG0s0yTJJGskocnbDIOgEhjQN gAzMMxRkKAAqvGjQYfE1orrrDQvbKyOkrKOoaaKV03BS0MsO7HMEqJS4BGGKBSQG3DHXhe5Q VHDlQlPbZZ6K51ddVSPMytEtSZS8UR6MlwDNnJ2buiXIGfBdNGgQ7lwLM0vFItdHZoTfaecN WPEVnVpIBH0XgryQyKJS+Tklhsyd+mCz2BbLea6WjWOK31FPABErMWadWl6WV8/Gd1aIFySz bPCPIa3NGgX6233iDiGe5WkUMnXKSGlkNXI69X6N5WDhVU9Lnpj4O6P4g8LwsrJU8NUZeqqk Srq55Ul/yWrudQ1LKXUgo0bMyBDnGNhAHYOQ1uaNBh8P2WptD1PWp46ySRIgKxi/SsFUjoyG LHYpyVO4k723ZfdJJHW2+8QcQz3K0ihk65SQ0shq5HXq/RvKwcKqnpc9MfB3R/EHheFlWDRo Mc8NUBrJqo1F16SXfuAu1UEG8EHanSbV7TjAG3kRggYz7LZa/hXgGmttvXrV2hpI4x01TJLC J9ipuy7ArCCNxVcYUHauTgtGjQRwCZaeJaiSOScIBI8aFFZscyFJJAz4snHlOpNGjQGjRo0B o0aNAaNGjQGlu+flbw5/3n/DGmTS3fPyt4c/7z/hjQU667V0NvqZY58OkTMp2LyIBx4tS3GR 5e5XXySOzu9mkZmY5JJgOSTrNuf+aqz/AKh/4TrQrf8Amnrf9yv/AIB0HKe6d+W836un8T6N HdO/Leb9XT+J9GoGngn+Y8DfrVZ/DU661rkvBP8AMeBv1qs/hqdOdXeLvHX1rxS0QoqW5UtE Ynp3MjrL0G5t/SAAjpjjwT2amWXF18Xivkup/PXX+zPo0aNacho0aNAaNGjQGjRo0Bo0aNAa NGjQGjRo0Bo0aNAaNGjQGjRo0Bo0aNAaNGjQGjRo0Bo0aNAaNGjQGjRo0Bo0aNAaNGjQGjRo 0Bo0aNAaNGjQGjRo0Bo0aNAaNGjQGjRo0Bo0aNAaNGjQGjRo0Bo0aNAaW75+VvDn/ef8MaZN Ld8/K3hz/vP+GNBjXP8AzVWf9Q/8J1oVv/NPW/7lf/AOs+5/5qrP+of+E60K3/mnrf8Acr/4 B0HKe6d+W836un8T6NHdO/Leb9XT+J9GoGngn+Y8DfrVZ/DU6c6uz3eSvrUiiojRVVypa0yv UOJEWLoNy7OjIJPQnHhDt0mcE/zHgb9arP4anXWtTLHk6+Ly3x3c/nrv/Q0aNGtOQ0aNGgNG jRoDRo0aA0aNGgNGjRoDRo0aA0aNGgNGjRoDRo0aA0aNGgNGjRoDRo0aA0aNGgNGjRoDRo0a A0aNGgNGjRoDRo0aA0aNGgNGjRoDRo0aA0aNGgNGjRoDRo0aA0aNGgNGjRoDRo0aA0aNGgNK vE1VBRcSWCpqZVihjFSWdvF4A/8A7jTVpO4xnjpr5YJZYlljVp96Mu4EYUHl5fJ8ugwa6/2y a31MUdTl3iZVHRtzJBx4tMVb/wA09b/uV/8AAOqt2rYLdAzR2+3yOzBYfxIKtnmDy8WOf7Na V7fpe5vdpNqputUzbUGAMwnkB5NByHunflvN+rp/E+jR3Tvy3m/V0/ifRqBp4J/mPA361Wfw 1Ouqy1MUJxI4XPZkgZ1yrgn+Y8DfrVZ/DU6Ye6hAtTwfc4DSvUtJSSrHEkJlZpCBswoBOQ20 58WM8sZ1Q4dfpfPJ6w+vR1+l88nrD69cfv8ARQvPRzUlteZRSItHTSW6QqpBJVYnUqaOTmoL uABiMj+TbFWpt1U80y0tvqxeus1zVFTChgklp2SfoVFSV2n41PtGW2lV5DYcB2rr9L55PWH1 6Ov0vnk9YfXrk3DFHVQvXGgjp6SBhFtK2qSkhZhv3Yp2YMHwUzJnDDaoGUOmForqVTbWUYIH hE0jHJyez8Zy5Y8v/ATbcxl+f8/seOv0vnk9YfXo6/S+eT1h9ekkx3LpnIq6Toju2L1Ztw7d uT0nPHLPIZ+TXyIrr0bA1lHvyMHqjYA555dJ+jx+I9ueTf2OE/un6/seOv0vnk9YfXo6/S+e T1h9euV3mkqpZKstBJOOoqtw6CMqKuHe5EUQO47wvSZwR8cDkWV48WngehN7qIbeguwa4SUc i2OXphIXkZG6wQUcFewY55A59h9OHgmWO9udurp27r9L55PWH16Ov0vnk9YfXrk09bxFS0tw gmSqdk6MwVEUalgOllXPgxuDlI42IWNiGlPJVxshpbpfp6Wnkq/hCmk6NhTrBQmTrEglkXEw ZF2AqsJyehB3scqB4D/jZa3uG3X+v0vnk9YfXo6/S+eT1h9euZUFdcpOKqqCXrUtH4ar+IaK KPBGD4cQz2Yysr7ichQp8CbhKfrFpmfr1wrMVk69JXQdE4xIRtAwOQ+jmMLjYuMvDcZu/b9T bo/X6XzyesPr0dfpfPJ6w+vXL+IaPiKorZHs9UkNN1VVlRgS0rdJkiMiRdrbN4z4Hxl8LsaK E3K+C8XRKWOoqtsMvVY3gaKESKPAzviXIyNuVmbO7cFCnwNTwcpuWfsbdW6/S+eT1h9ejr9L 55PWH165Sk93qJKWChuFyankqgktVWW5Y5EXopSwAKJyBWLDFMBmHNxlB8cS11+tVNTrQ9aq 54o3ffHAStQQfBR1SKQ5wBnnEDu8EjnsT6e3KYyzd/nRt1nr9L55PWH16Ov0vnk9YfXrlMcd 0tt14gam67VVNSzz0kMkSCnP4hArM4C4O9Oj2784wSO19Qulxr6m2rTVtykijrt3W6y3iOSL NPOr4G1OXNACyYDMOb81F/A+eU1r/Rt1zr9L55PWH16Ov0vnk9YfXrkFTT8W1qSPSVPQokck EoljIeoCVDBSmHUK7RKSWAjB3jDdhiddc/J45h8ykpq6/S+eT1h9epUmWRQyZZT2EcxpQ1aq YZ6iktkTWuW428dK88MZi8JwcIHWRlDJ4Ttjn4SIfFz5W6jphjyy1boz7/7Lfu0b/wCy37tL VoENu4XmuFBFS0huUgnpYujKwo0oWOBSqDIyOj3Yz4RYg40w1UzwU7yx00tS64xFEVDNz8W4 gfLzPi0l3Fz8fHLU/JJv/st+7Rv/ALLfu0pUFGi1d0uFnscFvq6KmelipTHHG0kzKsnh7GKl cdDtO4Yy+fFotNspHv1KqWhqKpt0InmqKlYjU1DSK0aszxltwOJS2SCWCHy6zyvTrfBjJby9 vy/f8jQ9ZBGxV5FVh2gsAdVqa+Wus3dVuFLPsxu6KZWxnszg/JpB4uko+EbRJQWxOgDfi6dA 5JXcMs2Sd3LJ588EjWD3Ov8ApL/sv/562891v09nY+v0vnk9YfXo6/S+eT1h9eua8VL0vwVC 1dJRQvVSmWZZ3iUKlLPIN7IynZuRSRuHIdo7dZ0yW3qQxDdaSr2qagVN1r9lGrY/GyfjVJTn kZ2k4YN0eyUxEdb6/S+eT1h9ejr9L55PWH16QOG1eOxJE8s8piqqyIPUSGSQqlVMihmPMkKo HPya1dA1dfpfPJ6w+vR1+l88nrD69Kus+9xVc1plShL9KWQssb7HeMODIqtkbWZNyg5GCQcr 2gHrr9L55PWH16Ov0vnk9YfXrnMFRTUNwLx0tTFSPQ06wLFRSYUKZPB2hfAwGXwSAR5NTdNL HeLkB0uBTRtG7UrMoYb8gFQC+MqduSclsePGeTt+Df03/j/G3QOv0vnk9YfXo6/S+eT1h9eu Wiuu5paeNDP00lXsLyqAWTonYqu6OPwhtyCVxkjJIyAwUPWOpx9a/luec4zjJ27sct2MZxyz nHLSZbPJ4b4562HLr9L55PWH16Ov0vnk9YfXrmtWrQ3S81FJSyCs+D16KZaYndIN5wGxhjzj 5c84A8XIuFPcZY5qdqid1jemqeljhUH+UJdVGDkKFDAc2zgEtnBnL7NTwbs/q99frr93Suv0 vnk9YfXo6/S+eT1h9euZ1lVdzPTLSLKsbRrseZCOkfJH4wLG20YCn/R/GPjHg3qP4RIlqZ5p HCyzKtN0SruQOwTBOPCOBgk4I8WfC1Zlu6TLwXHHlbD91+l88nrD69HX6XzyesPr1y2lr7s6 yJN1tYFdC1QIGaVQQ+doMS58JYxyRsBic/1bEi1YrbfXNJXMixSR7UgQM5LqVDLg7dyrzJ2g YHxMkanPfs1fprjdZWfybdK6/S+eT1h9ejr9L55PWH165681Ul0ugp4pJJRSI0HSQbUMg3+B vwMjmpwWPxmxjniuktzlniipqmrNM8qq1RUUoVwNkhYbSq4AxHhiMZb+l8XV5MzwWze5/Jt0 rr9L55PWH16Ov0vnk9YfXrmtQlZU/B2yKUXGKqYCpMe0LTrKBJvOMfjIwMLjmxVgAE3JdMF9 6zKwuNu6ud/Rp1B9y5B25bpsHBxnkM4Pxc5Gp6uOU42w+9fpfPJ6w+vR1+l88nrD69c/FPxD 0Dg3S1mUspVhbpNoXByCOn5knbg5GMHkc8h6fiEpGI7pa1YLiQtbpCGbJ5gdOMDGBjnzBOee AR0Dr9L55PWH16Ov0vnk9YfXrkULCq4dvPD701xSrqZLiinqEu0iSWZlIkYLGcqwIy4ByBka OHrdVU/XRZY6Sjik6JmqKiymn3v4e+NYgYm2L+LKlix8JhuY/FDrvX6XzyesPr0dfpfPJ6w+ vXP3p+ISkYjulrVguJC1ukIZsnmB04wMYGOfME554GFQLfRxBTVc1FsinuNVBNUdM5kenXpu iDRFAqINke1g3axI5yvkOu9fpfPJ6w+vR1+l88nrD69cYNNDL3Lb5RR2upC7q5aekNvkVsvK 7Q7IyuceFGQQMLjxbThqqBdqvop7ZW0lNTvGG2VdBI8mTzyfxiFeWPBK5BznyAH3r9L55PWH 16Ov0vnk9YfXpCMF96zKwuNu6ud/Rp1B9y5B25bpsHBxnkM4Pxc5HwKfiHoHBulrMpZSrC3S bQuDkEdPzJO3ByMYPI55B0Dr9L55PWH16x71bqC91VHLNWbFphJhUZQSW2+M57MH9+ld6fiE pGI7pa1YLiQtbpCGbJ5gdOMDGBjnzBOeeB9mC+9ZlYXG3dXO/o06g+5cg7ct02Dg4zyGcH4u cgN2osVrqlpRLWyN1ZGSM9KpOCc+Txdg+TXzdaulqO5/xFDSMzx0lFUUxZh2lYeePL24z8h8 WsqgiucfSfCNXSVGcdH1elaHb25zukfPi8n7fF5T/wDN5xl+mt/wtBz3unflvN+rp/E+jR3T vy3m/V0/ifRqBp4J/mPA361Wfw1OnCut0d74sraGWtuMHVqOnqFMFQFT8Y0y4C7fF0OcknO7 HLA0n8E/zHgb9arP4anT9X8OyVV5kulJe7lbp5aeOnlWlWBldY2kZSelicg5lfsI8WqF+G02 Kouht0d+vZn3tGrlnEUjrnciSlNjuNrZVWJGx8jwWxXFNw6ad5Te+I0dHVOrSRTJUMWBI2wG ISMCFc5VSMI5/oNhkHCNH1wyNWVxpRLNUQ0ayhEgmlDiSRHRRKGPSy9rkDecAYXbl23ua2u0 vNPRV1XBVu8Tx1EEFLCYWRZVyqRwrGSVnkUl1bkRjBAIDItsFruaWt4btdNlyraulgdKtpEk WBpRvV1iKZYRBgrFcgtgttwZ4oOFpqieFeKbovQPNHLJJMUiR4i3SIZGQIHUIzbc52Dfjbz0 wQ8G01Klpjprlcoo7ZWzV0amRJDK8rSFhIzozMMSyLnIOGySWAYSVPClPJbo6aCpnikhq6qt hkLHwZZxOGzsKttHWHxtZW5L4Weegx7ZYrReOlFHeb+WhwJVm3wtGTnCsHjBDYAbaee1kbGG UmO5WmxWmoWCsv17VygkcozyLChJAeVlQiJOTeE5UeC3PwTjY4Ms9zsdreirzSJAj5p4Kfoy IwcluccMK4JOdvR5B3Es24Bblw4fSuuJrY7hXUUksSwVIpHVesRKWKqWKlkx0knhRlG8M88h cAtvauH4qeOol4lukUElRPTCSSo2qJIRIZQSVwoUQynccDwe3mMx9R4cjt3X6ziO8W6l6XoQ 9zkai3PjOAJkUnlns8h8h1uPwbTGvjq4rlcoOgqJ6qmijkTo4JZkkWRwpQ7iWlZ/D3bTyXCl lNjhrhai4Xp54aOSRxM4ZsxRQqMDHKOFEQHytt3HkCSFUAFeSDhZEhlTim6VEEidJ09JMaiK NNxXfJJGhWNMq43OQPAfn4LY+JqayrfqCz095vE1RVVclMT1goo2RSO7IxTbLtaMIwUnYzAN g8ix3zgezcQXmmuldBG88SLG6yU0EyzRqxYIeljcqMs3NCpO7mThcSR8I0cV4prgtZXbaWrl rKek6UdDHJKsglONuW3GVm8IkqeSlVJUgoVS2yl4agvYrr/PDNcFolSFpi65qOhJZTCHVgAS VK/GGwEkqSxwcHUdTTxTpdr2EkQOoklKMARnmrICp+QgEePVyl4Tgp7DPaZbjXVSyVbVq1E3 RCSKYy9MGXYiryl8MBlIycEFfB1JPYKtns5p7/coUoahpqgEo5rtytlZCV5Dc2cLhQOSquEK BT7yKX0vePaR7uqdy4ctdpp1mq71ewHcJGkUjSySNgnCIiFmOASQAcBSewE6YILXVxcS1l0e 8VctJPTxxR25lTooWUsS6kDOTny+XJI2BM+n4VnW1pTVvEFyq6yCtlrKa4MsQlgL7xtUFChA SR18JSPCO0KAoUFSgl4cq6FaqS/XhY3lnUSQTNURpFHNJEs0kiRlY426MsGchcBuZCk6txQc LTVE8K8U3RegeaOWSSYpEjxFukQyMgQOoRm25zsG/G3nrYXuf22KlkpIK65R09QkkVYhmWQ1 cLyyyGOR3VnwDPKNylXIfmxIBFyp4OtdZbo6Cp6eWlWrqqpkL43moE4kUkAHbiofGMEYXnyO Qx7ZYrRd+lFLeb+skWC8NTvp5FBzhtkkattOGAbGCVYA5Bxod5FL6XvHtI93VzhrhW38LU88 VEsZedw0kopKeBmAHJT0MaAgZJGQT4R563NAr95FL6XvHtI93R3kUvpe8e0j3dNGjQK/eRS+ l7x7SPd19NwXA9O9O96vTQOpVozVAqwPaCNuCDpm0aBe71P/AGgv3tn/ANtHep/7QX72z/7a YdGgW4+Do4VKxXy9opZmIWrwMkkk/F7SSSflOhODo42kZL5e1aRtzlavBY4AyfB5nAA/QBpk 0aLspVfc9ttwZWrbhc6ll7DNMrkfvX5B+7XzTdzq10e7qtbcoN+N3RSqucdmcL8um/RohUk4 BoJXieS5XV3hfpImadSUfBG5fB5HBIyPKdffeRS+l7x7SPd00aNAqQ8A0FNEIoLldYowWIRJ 1UAklicBfGSSflJ1995FL6XvHtI93TRo0Cv3kUvpe8e0j3dHeRS+l7x7SPd00aNAr95FL6Xv HtI93R3kUvpe8e0j3dNGjQKrcCUbsjNdLsxQ7lJqAdpwRkeDy5Ej9uvrvIpfS949pHu6aNGg V+8il9L3j2ke7o7yKX0vePaR7umjRoFfvIpfS949pHu6O8il9L3j2ke7po0aBX7yKX0vePaR 7ujvIpfS949pHu6aNGgV+8il9L3j2ke7o7yKX0vePaR7umjRoFfvIpfS949pHu6O8il9L3j2 ke7po0aBX7yKX0vePaR7ujvIpfS949pHu6aNGgV+8il9L3j2ke7o7yKX0vePaR7umjRoFfvI pfS949pHu6O8il9L3j2ke7po0aBX7yKX0vePaR7ujvIpfS949pHu6aNGgV+8il9L3j2ke7o7 yKX0vePaR7umjRoFfvIpfS949pHu6O8il9L3j2ke7po0aBX7yKX0vePaR7uvi7WaCx9z/iOn p5Z5RJR1MrNMwZixiIPMAeTTXrG4v/Iq/f7uqP8ADbQcV7p35bzfq6fxPo0d078t5v1dP4n0 agaOC/8AN/BH61W/w1Ot2q4wusd2mooYaZts5hj3BsnwsDPhawuC/wDN3BH6zW/w1OqXEXEc NhuN7IoZjcRJuomPhrLl2DlcclxjGSTg57CCAuUnu1jjcvZqVHdPq6SpMU8CdHk7J4oJJY3w SDgoSeRB5EA8tfds7p7XdnWikpJCnaNjqceXBPZ/xB1xWprbncARUVApYzz6Cm5Z/S3jP6P3 6ip1NJKktM7RSo25JQfCB8uTnPy51xy+owl1HWfT5Wer9BrxhciMmKn9Vvr15ScS3Fkvla7q zU4p1iiOdi7iQeWc889v6PJjSFw3xNDeD1OpCQ14HxByEo8bJn6R2j6dNNCv/J/Eg/Vv7zrt LLNxxuNl1V5eNrqe2Kl9Vve1Uu/dKrbPCm6jSrrJlLQUcAYOy5wXJydqjBA5eERgdjMijcOI ltlRWUiUclVcYwr09OsbbXVl3bmI/ojnkA5OQBjwmRRq34ks3FFbMZpKxqmlE3TikSVZN1OW Ug7cYBChVGABtAA5ATLOSbjphjM7rF2e2d0BrnZ/hVKqhipAyozSpJlWIJIYDO3AVs57Ma9T jeurbL16m6JUmp+lifYcgFcg4J+UduuI0dFfoLY92HSvUVlVNG0DQqu9UQZk2YA3DdyOPC3A ePl0HhueGp4CojBIH6KgWKQDtV1jAZT5CCDpjltM8ZJ9zZX8XXO009riiEUvS0EUrvNuZixB B57h5NU6bjzievrZqW3WRa6SCNJJTEUQIHLBf5SVc/EbszqjxAu5bN/uuD/jqv3LL9bbjxJe khnEc70tKnV5h0coZGnLrtPMldy5xkDPbrTm05+6HxDSOEqrPTQuc+DJXUinkxU9tT4ipH6Q R4te0ndLuFRVrTSUcUDvGssTllljlBLgbZIpXXOYpPBznwWOMA4Y7naYRMJUpb5VNKzMwpLr JGqH9BmQAc+QHIY8WlPijh+3jhW8VC2K9UcsFvmlSoe5Hbvj6SdGcJOS5ErMwLBuZ8mt2Y6/ pYly36t+h4juNw4jtdNI6xwsZS6RZG/CHGck9nk+oauDiWuP9CH9zfXpV4Tq/hC7cO13R9H1 mBptmc7d0WcZ8fbpkr6WupAq2OOCoKH8bKZB0w/2VYbQdYbWqrimO2JD8LXCjoZJ89Ekqtlh 5Tz5D9OrSXO4TQiamalqoiM9JTuXX6DpBudq4XmVprr8Ox3SUhdtRCZJHY9gAClDz0cOcDtQ 3IV8VxqLcEDFFaPa7HHgmRUfaV8ZGQTjBxq6D2b1XK2140U+QqQf79ZMXEdxgtVfWbxNL8Jv CqyZwqBBgAAjHZ/f4zpBv3Gd0t9hqbTS35brUw5Z7hHEFCKoOAGxgkkZPaOeATplmG7hutH/ AK6k/g01flJdtVOMrm6gmOmX5Srcuf8AtajrOOLhR0FRVFaaQRJuVUjc7mOcDkxx2dvy6WY4 +z9GqlbV10loaBqSNUfOcxMP29v06xllMfd0xwuXsd04xuTgFUpiDzBAb3tV7txXdDaZxG0c LEAdJGCGGTg4yeWlDhR5ZKaWNz4MZAVfJnPl5+LWzdkC2ic/7P8AENWM2We5gvfF9ytt6no4 Y6doo9uC6sScqD4j8uspe6NdJWZKelgqGX45jVtif7TFgB+/OsvuhqPhC6Fs7dqZx242rpYs l1vyJ1a3R9dgTGxXi3KF8hYYwf06W6pMbZs4p3SuIRI7yW2kelQEtOhdUHyBnIDH9Hbq5Rd0 16xkUCKNnOFEkbDJ8md2M/t1i1sV1ZI6yutFGwGAcs0vQDxsU7D+gZ7NWa22UvwLHWrVGsfp YejkyNiAyqCEUcl7f06rJkpOIrjU3iqZ3UJBbZJUiXIQuGHMjOT5O39HadRDjO6H/R03qt72 qVvTF3uI8tol/iGssusZUE5ZzhVHbqxTFNxtW01MZpY4T4QUBVbnnP8Aa+TX1Q8a1tdBHKsM KhlyRhsr8nbpcukJ+CpME4WRW/T2j/jr44dwtBnDNgN2DJ7dLA5rxJXMcbYf3N72sxOKrnRc OWqp3pPNVGcyNMCTyk5YwRjt+ga+aZo5k3RsTz2kEYIPkOsmdd3CVh+TrH+JqC0vdMnI51Fs H/vn3tSr3SHPbVWwf9p//wBayaGoqUttAqVEqIKODCq5A/k1+vWhTz188yRJUVDOxCqOkPM6 DUpONaqsWV4pbeYoQDLIZMJGDyG4lsDnqmnHZu9zpqGguEEojroY6h6VXA5nOzc3I+LO39B7 dc67oHFU12uFPwza6lpKdHCPMCWDvna0h8qgnCj9vj1scJ2IWg2fAZV67CoBPblskn5TjP7d auOvf3DvV8Y3SG5VdOiUgigkdTJIGAVVJG5juwOQ1jL3WpJC3VaOqrUUZMtLREoflG6VSR8u NYHHDB7rHbnbbTVlwqJKnxl1iKkKR4xmTOD27Rpm4j6e209HbbRSKkZUlpAOZx4s+Xxk+POp 6KsUHdEnucbvRtTP0bbJUaN0eJvIylsj+4+I8tX04uubf6On9Vve1zS8/CNuNLep021EM8cM kg5dNC5wUb+tg7SPJzxp0iQEAjA5aI1afiS5lb5V7ld4BTLDEc7F3Eg8s9pz258niGsep7qF RSzGFugkkUkP0ULFQR8pcZ190+5KDiTaSGBpcHx5zpKTh+jSoVGLSMeahjuIHLmfFjSa+Q4R 91Z3YKVRP7Twtj6HJ+jWrS8dVdWA0RpXXlkorcv/ABaSRYrZ0nQtAEkIyCBjI8eCNfElm+Dp 91FWIZx/omlUn9GM5P7dPS+xs7LxxXVdrlqIOhU9G2CFOUYDyEkZ/Tr7reLLna6a1xRCKXpa CKV3m3MxYg55g/JpGoKwGruKKu1Z4WkK8xhsc/pP0aYr2m6Oz/7sg/46Waouyd0KvpoJJ6s0 MEEalnlkDgKPWz5OzWfT92S3VUyww3WgkkPiWmqOQ8ZPg8hpN49gM3B/RCQR9LWxKSezGyQ8 /wBoGuc2agegr5maVX3QnaVyMeEuf7yP266ePx8rEtfoy3d0Sa6q70T0kyIcEqrj6Cc6vUnE Nxr+I7XTSOscLGUukWRvxGcZyfF5PqGuX8AQutXdxIjK/wCJJDDHaGOn+2Lt4stH/bf4Z1ny YzDK4qlXjm6ntipfVb3tEvHtbTqGnNFGD2F9yg/vbSBxJeJbXBDT0e3rlRkqxGRGgxlv7gP/ ALax+GKWzVV5aTiKXpUERIkqJCN75GAzeIYye0dg1vx+HLLG5fCWx1yHjetqEDw9UkUn4yZY fxasLxbcW/0dP6rfXriU9VS0t9qp7FIVpllxC6Zw45cufxlzkc85xrothuAutsjnHKQHZIo8 TDyfvB1fJ4bhjMvgl2ZKbiW4xWasrndZZTcmhAfO1U2DAABGOz+/x68HGNyEfSOlMiZAyysB zIH9b5dZtMqtwxVbigAuznLnA+J5fFpVuE9RcK0UVOMbhsIEu9CBz3cuXLXnrUmzwvHk/TrE 3V1PWGhYkEYC/wBL43YdWKbjKrqFhO2BWmDsiENu2qcbjz5DSlT8LwoiGapl3t5HVQc884Oo np1pZnhp6t5EddshUhSR41B/46zy17rdG69cT3H4HqTC6xNtAEkeQwywHI55ctSXniy6UN9m t9LDBIFKhAVYuxKg45Nz5nS9WVHWOHakuIUcbMRxyByo3AAEjx6h4tuVHBxHeqyeuFOtqeGS WJHIqH/Fo6lBjG0k43eIq3I8s7nqyaLlxi/D1C1Xfq+hgCnaYKeJpZN39X4+N3byBPZpauHH L8T26shpkrYKUW+sZxPEsYl/yd8chI5IHkOPF2+JJmvMXEVdbLdWUiUMrSdJFNVviPcFOEBG cMeznyGSc8sFhamipoaxEjeORaCuSWNxhkYU75BHiPPVqS9s/unflvN+rp/E+jR3Tvy3m/V0 /ifRrKmjgv8AzdwR+s1v8NTqrxDQQVlfcKeq3dWaplZXUZaByxy6jydm4eP9IB1a4L/zdwR+ s1v8NTqe5pm7VuQMdO/8R0s36LLZdxzC5PV2mdbdcaOmq4IUAjGBE5jPxTFKoyV8YDhgMYwM YFZaCluTYs9UZJiCeo1OI6kfIoztk7P6BJ+Qa6DdLVDcqI0VQAsYyaeowSaZyezlzKE9o8Xa OfI8ruVDPT3GS1PTLNVo23olYMAfE2R2LjmGH7NeLyeG8tR68PLLNoKjdAz9K5pXhbwixKNG 2R+ggg+PXW+DrjWVvA97r6lo+tbITuniZVO12Cs6rg4IAJxg+THiwuHeCbtdVhqbnGazos7X 6FnKN4hv7TjPj58/2aaHzbeGOL1poBOYY4UMW3f4yGBXB3Y55U9uCDjt16MML48a8/m8m5uE Sku14g7p9HNQVFJVV86dGoqsmNwFIjLAEAE7QyhDsG5duAdXIO6JxPwVV1trgprOyySJVkPF Mwj6RBtRcPyChQuD2YxnyJlwvlV8Pw1VBJVNJRzpJHLPTKshYEkSMSMBiScZHIBck7da99jq +JOIK6tttIerNDBEDL0MQVY1I8bEL2DAyTjOSeephlZHm+nykx1kbLFfOLL9JdeIUorHItYz 08yzpJ0cQiVQxH4wbQ2xMkntVeYOBqLh6y3ALW3uWriplnSoiqaCGnKq7ozoGYlzhht8gPiO sKz8Q13C9A1rq7PVruqJajpVhxJsk5MqPtJBIA5jkCMHdk4Z+Eb8t0sVzo3o5KWaATS7SpCs Hd28EY5AZAx4sjXTGy+tdfxMbdQxXtcx2f8A3ZD/AMdcWW0C8X68yUMMQr1nbdRGbduZSN5B PMhmzgkAc8ctdvuy5gs/+7Yf7jrmVlvQtvEPEkj0FjgudNMVppK10pmlUvIwzuZd2QV8IYJB BYnkde36T6ieDyc/tZ95vr7s5TbRt1G9llstJfLDwlF1uFkRZqBGPJ6ceESMvJhpAAGAOckt jT9dzw/JwTxJPQzWKe5VFnq5pJbfHGjyBoh0jnDMxBfaScntUEkjJ5jeuJr1xBcrPWVve0pt jFoo6e7wIG39GWDFpW7NuMjyHtyNdAunHttu3AnEsNVV2iidrfPFSQi7wTzzZiYc0QlVJOMA MxOfF4/Nlrfp7L6vjgMYXg75aAf4A06tXUVxqKqemj6zEk23rFKd5B2r2hTu5Ekcs888tJ3A wxHwX8tAP8Aa24OFYriXr4ZpbdOThailO1n/ANoA4YZ8udRWoK6QMGpqlKldwXbJhiCeXMgZ Hb4xnXNuO7rV1N4kt/S9DSCNCaWDsc+PcR8vYPoB56abrNc7ZXQRVTQ3UQJ1t6iOMQzxxo6l sj4rZBwACvj5eVOucFw4m4jm+C6GaMMi9JU1cRjWI7RyII8I/o5fLrWPuhYq4QaR6NEZ6ioR khgjTmWIx2Y+k66sy54erh/65k/g1Nw7wnQWFOkVOmrZFAlqH5s/b+4fJrxRmxXAdv8AyzJ/ DplltWYieTnrPqzI0ck8s7GAM0WEcr0JU4yR4wRg58WdbKR47AOesOuq4p6YTPSbZWAVyrsu R8vl15/K7eCW30fXB2XSryckMv8AeRrbvaYsk5/2f4hrI4K8JK3AwAVG0eL4w/4a3r+mLFUn H9X+Ia6Y+znn7s3uhpmoup/sJ/Cul7ha9TWm3q0zGegV9kqD41OT2HHjU/35/a8cRxLLfqpW UMrbQQRyPgDXN62kNso+ruBDVKGViPiVEZOQc/1gfox5NVg9VXFtJEm2iieqbHJsbE/eeZ/Y DpZWunluOJTFElUyZghXahcSoQceNu3nqpSjNLCB/UX+7WtYVikvsKkK7qjNgjJXkOfya9eX hxx8e/k2aaIYvleP/VEn8Q0u2zNTfa93+LAqxqB4hzz+3lpmpVxxBWg+iJM+vrDoqVqO/wBW OxKva6E9mRnI+nXlVHPcFqrZWoY+jdVUhS2eW5caktkyW6O3U+CZ6hekYg42KRy5fLqO9Ua0 6rULyVhhsfpyNfdhpJaqp61NzZ8BcjsUdmtW+gvxP1fikxdsdTTByv8AaGef0a8RUPC9g6QE oDPux246TnjVunozV8SyVY5w00AiDeVjkkfTqtEu7hOyD/r/APE1kc84h4kvMNxp3cdXpaZI 5YKGA/i1iKDA5fGOzlkk8/k5aYOJOKI7DwnHPBkV9zh/EBTho4m5bh48v2D5Mnyao8Y0G3hy hr54lpmooYaeR5JY/DXYBywxPJs9o/p6T7PTVnE99jqMSVUNMBHCxlTmVGAfCYclXAHi/drv ePGZJ8t3g7hpllp66rQPM9ZTmU+LnKo2j5B9eukzoqVloCjA+EIf79V6OiqI4aWljtskSpUQ uztNDtCrIrEnDk9gPYNXq1dtVaO3PwjD/edcb6+qlHjeglrK+aWAKamlrJJYQzYDgkhkJ8W4 Ac/EVHizrZou6Bw9JbYY66vFLUQIFkirYykoI5dmOZ/2SdWLnCst1rVYZUzvn1jrJksCykY2 Mo7A6BsfozorA4n4lj4sulJbaGOSO107NUSTyrtNS6f1VPhYVSzY7TzOMLnT3RhJKaJ0ZXRl DKykEMCORHi0sXXg+KttrRgncMlSnIqcYyPIef7QSDkajtnFq20zR3+RKeqjy8rkbUqhnBmj HikyRvj/AKWdy+FnpM5ZTG+rWOO99mqEf5LxKP1X+/Srw/Iatq6qb4zVHRj5FUDA+nTdAPA4 lH6rpbsdIaCWupGBA6Yyp8qsB/djGqw+r5up7U1ShxJA6SJ8hyB/xOvZuH4LkVq0lkjaZQxw cjn8h1YvtO9TbepRDMlRIqL8gDZJ/QANblPAsMKRryVFCj5AB/8AbVnoFKLh6rt889Q7o8Ag dQV7Ty8Y/ZphuyboLOcf9Gw/3HV6vX/kus8ghf8AuOqV3eOOjtDSkBfg6Ht/QdS+vqEzjhqd LDRpVYEDXODpM5+Ltkz9B0j0RoKLiKCWkYPEtOssgil3kESjIBPYcAcj5dN3GlbQ1tHbaVz0 kTV8JmVSclOYbmPkOsCWz2CnvFJHRSzpBVo6VAeUZVd8QypwMci3l7NdvHfWSs5G/gKqFxul 5qAhQEUybS+4gKhUZPaTgZ56eaFdnFtmH/X/AOGdJ3BtHSWq73mOjjZaCZoOruW3bsR+Ec/7 RP8Aw+R1plA4sspHj6f/AA9YzsuW405NxVEy8Rb25g0yBD8m58j9/wDw0y9y2aoe9VdMKmdY FpGlESyELv3xjdtzjOOWe3Vi92IXimTYwSojyY2PYc4yD+7WRw/cKrgupmqZbFPUVMiNEXap 6OIJlDyxG2Tkducc+zXrwzxy8HD5ZvvtT43Vjx3dw0hbEkQGeePxMfLW7wHFItJXsQeiMkYH LlnDZ/4Z/ZrOrKeu4vvstwprPJSPUFWmeSp3xDCooxmNcclyeZJ8Wni12yG1UEVHAS4XJZ+z ex7TjxdgA+Qa5+Tyf9cwq6+XxAQnC1eTJFGq3V8tMu5R4HjHj0t256aiuE1RKvSKUKqqLsDf L8g02W9QbFWg4yLtJjIzz2aX6+hKO08heVeRkkmP8o5OAoUfs14st/DculSWr69UzTsHldvB iWLmoPkHLWvBaeqWyaoqS4nkQKoYjCZOcY8urFJco4VWFqZVKno/AbaN3kxtOoZ6uoubKkMb EBWdViIBypx4+3tPP5NSYxKqsyNYbgyNBg7OUcW0nwxzJ8Z/Zqvx7wzBduMZ6uSJXZNmMnsw i/vGR2HOt+8UppuFqhDI7EbM7wMjwl5cv06m4hXdxBUn/Y/hGunshPuHDdNXUDQ9Hnl4S+X9 B8R8esy01F2L3SiujdMtJa6mOnqWUB3j6vLhWP8ASK4xz/u5ad40z2Z1nXaBI+syKMNJbq7d +ynf69CMDunflvN+rp/E+jR3Tvy3m/V0/ifRqBk4WkkpuHuEaxaeeZKeesZ+ihkk256woyEV mA3Mozg9upZ1uE9RLM4w0jFji1V2ASc+Z+XXPaTiK926jSlo7pNDTx7tkaqmFyxY9q57SdS9 +HEnpmo9RPd1U2e+ir8EYOD2/wDJVd9jrOj4fMVW9SkG2VyCxFqruZ/+DpV78OJPTNR6ie7o 78OJPTNR6ie7obPVSl1npoYEmenSJmYdFaaznux27oD/AFfF5TqparNNaLBX2mHp3irXDO72 6uyBuZyBiAdpb9w8edKHfhxJ6ZqPUT3dHfhxJ6ZqPUT3dDbYk4BoJpWklpJHZsZJt9w8Wf8A 8r5daEXDa08DxQUyxhgV3C0VpYAjBAJgyBjyeXSv34cSemaj1E93R34cSemaj1E93U4xNQ1P w+ZdvSQliBjd8FVwLHxliIcsT5TnX1DYnp3Z4Y3R2VkJFtr+wgg9sPynSn34cSemaj1E93R3 4cSemaj1E93TjF9D/VdeqBTKEZVp6dIFzbK4khR2n8T4znVKrtT18IiraSGpiDbgk9mrXAPZ nBh7eZ/fpN78OJPTNR6ie7o78OJPTNR6ie7qmzOOFbeP+gbZ/wDt+r+w19jhi3j/ANHrV/8A t6r+w0q9+HEnpmo9RPd0d+HEnpmo9RPd0Nug0ZrKKsop44FVaNHSGKO1VyIoKbQMdD2DlyGO zGqVXRXSqYFa+404/qw01yC/uMRA/ZjSX34cSemaj1E93R34cSemaj1E93Q2b4bXcojKDXVs yTbBKk1urpA6oSQpJgzjJPIEZzrbFxu4/oJ81V/2Wua9+HEnpmo9RPd0d+HEnpmo9RPd0Num C6Xgf0I/mmv+y1VD160MtMEP42qeqdjbK7tYAYA6HkBz8vaPJz5734cSemaj1E93R34cSema j1E93Q2fVFwXsH/yqv8AsdVJ7ZVT/HM4B7QtDcQD+zotJvfhxJ6ZqPUT3dHfhxJ6ZqPUT3dF 2c6O2T0LbqeIq39b4NuGT+k9Fz1crGuVbRPSyDCPjJW11+eRB8cPyaQO/DiT0zUeonu6O/Di T0zUeonu6Jt0SvmuFdXy1JQpvPJfguuOABgDPQ8+Q1n11uqbjSmnqI8qexhaq7cp8oPQ9ukv vw4k9M1HqJ7ujvw4k9M1HqJ7uhsyxcNzRlA0tTIiAAI1trgDjy4gB+nWzSJV0MeylpoYhj+h aK4Z/wDJ0g9+HEnpmo9RPd0d+HEnpmo9RPd1bbfc26JFPcY6yeqKEyy0pphi2VwVQWBJx0PM 9o7dQsLg6gMgODkH4Kr8j/ydIPfhxJ6ZqPUT3dHfhxJ6ZqPUT3dQ26FJLcJozHJDGynxG01/ 2WvYp7lCm1IkA7P801/2Wued+HEnpmo9RPd0d+HEnpmo9RPd0NukRV91hiWOOKNVXPZaa/nn x/yWqw68lto6FFYJTB/Ca2VxLFmLH/Q8vENII4v4jP8A0zUeonu6977uI/TNR6qe7obPLx17 xlGXKkYP/JVd9jqCjt9RQzNLBFtc9ubVXn/6Ok3vu4j9M1Hqp7ujvu4j9M1Hqp7uht0Naq6r 2KufL8FV/wBlrx57hNUUkkyErT1CThUtlcpYqezJhP8AdrnvfdxH6ZqPVT3dHfdxH6ZqPVT3 dDZ9mNxmnkmYYaRy5AtVfjJOfM6AbiPF/wDKq77HSF33cR+maj1U93R33cR+maj1U93Q26AJ rmP6I+aq/wCx1m11ne4ypJUU6MyMHGbRXEbh2HnD29ulHvu4j9M1Hqp7ujvu4j9M1Hqp7uhs /wAT18UVeoQl6wxbj8GV2FCZ7B0PaeXPPiPl5QGCuLKxUlkOVPwXX8v/ACdI/fdxH6ZqPVT3 dHfdxH6ZqPVT3dDZ7Va9JTKEG8jG42qv7PJ/I6nFRdB/RX5qr/stc977uI/TNR6qe7o77uI/ TNR6qe7obdBmqLpPTyQMoCyIUJFqr84Ix5nVe4QVNwjpY5ITspoEgXNrriSFHafxPjOT/wD3 Okbvu4j9M1Hqp7ujvu4j9M1Hqp7uhsxScLLKSWicZ8lsrh/9HXwvB9OJUkamaRk+KXttecdh 8z8g1gd93Efpmo9VPd0d93Efpmo9VPd0NnelpaijUCCmjXByP+Sa/wCx1chqLhHcaWtaPL0y yCNVtdcASy7ef4nxcvJrnnfdxH6ZqPVT3dHfdxH6ZqPVT3dDZ6CXAeI/Ndf9jr7VrkpyMg/7 rr/sdIXfdxH6ZqPVT3dHfdxH6ZqPVT3dDboBnuhOWyx+W115/wDpa+lqbovYo/baq/7LXPe+ 7iP0zUeqnu6O+7iP0zUeqnu6G3QIpLhDQSUqIfxtU1S7G2V3aQBgDoeQ5Hy9vycwy3JgN0aH GCM2muOCPH/I65/33cR+maj1U93R33cR+maj1U93Q2eRDVCVJOrpuSQy/wCa7hzY9pP4rU8E tfTIiR08QCAhc2mvJGTk8+i1z/vu4j9M1Hqp7ujvu4j9M1Hqp7uht0GunudwopKWVVWOTGSl qrwRgg+Z+TXtfNcK6vmqthTeeS/BlccDGAM9Dz5DXPe+7iP0zUeqnu6O+7iP0zUeqnu6Gz4P hEeL/wCVV/2Oq9dDWz0tS0kU8jCiqYo44LXWhnaSFkA8KIDtI7SNJffdxH6ZqPVT3dHfdxH6 ZqPVT3dDbT7poJ43m/V0/ifRpara6ruVUamuqXqJtgTe4UHAyQOQHlOjTSXJ/9k= --=-=-= Content-Type: image/jpeg Content-Disposition: inline; filename=2001_05_11_094016_shot.jpg Content-Transfer-Encoding: base64 Content-Description: move back to top: white bar in toolbar /9j/4AAQSkZJRgABAQEAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CADMAgUDASIAAhEBAxEB/8QAHAAAAgMBAQEBAAAAAAAAAAAAAAYDBAUHAQII/8QAXhAAAQMD AgIDCggICwQHBgcAAQIDBAAFEQYSEyEWIjEUFUFRVVaV0dLTBxcyU2GSlKEjNnF0gZGTsjM0 QkVSVGKis9ThJDVDdSU3c4SFo8FEZIKDseNGY3a0wsPw/8QAGQEBAQEBAQEAAAAAAAAAAAAA AAECAwQF/8QALREBAAIBBAICAQMDBAMAAAAAAAECEQMTFFESITFSQQSR8DJCYQVTcYGhsdH/ 2gAMAwEAAhEDEQA/AMm22+3uWyM6/G4jrm8qUXXB2OKA5BQHYBWuqzabhwBNuYTHZJwnDzpK j9A3VixnuHbIIz/IWf8AzXKti7MKeid1Mw3245IUzMSkoWk4zhSuSVDHI/Sa+jesV/T+dKZt j47eOLTOr4zOITdwackMpfgtpfZUcBXGdHPxEbuRqLvbav6kn9s77dVJ90jPTSiCzEYQpwLL cRKQ22lIIAJTyUo7uZ+gVsaeu7ECY+t1bbbi2Shl10uBLatySSS31x1QodXx4PImtaEVvpRe +niekvaYviLelLvbav6kn9s77dHe21f1JP7Z326amNV21LqEPvJU25L3OhppfDx/s4UshRKl BSUPjJypQUcgbiKhgX60x7Uy1IebfjtcFYiucZbu8OoU51T+BAI4mMYJBAPMqreKf7aeU/Yt 97bV/Uk/tnfbr6TabctK1Jt+5KBuWQ66doyBk9fkMkD9IrYZvZZuDLj1+alvJQsCQ4h4pSDj CS4Al4divkjAzjsWvEYuRcXfFx78GGlMjKXAQqZzA28kjJ7esQFKySQApeNeGn9I/n/Sedu2 W3abc64htu373FkJSlLrpKiewAb+2pH7FCihBetuxKwFJUXncHKUqHPf/RUk48GRVWFcUxZ0 eQpKlpadSspS4UFQBzgKHMH6R2U2S9ci73SLIWpuI4yyUhxfF2FRSjcOoorR1gvCkcyClKuW aW06xPqkYIvMx7sV+9tq/qSf2zvt0d7bV/Uk/tnfbrdN8jkOiPeVRyJClvOLaUoy2ylACcBO HCClf8JtCt+TgqUBTm6gRJkxozkhxVsDMZDyGkAHKW0BZSCPlghQCu3HLO3lSKUn+yP5/wBE 3n7KTFmt8hwoagJUoIUsjjujqpSVE/L8QJqPvbav6kn9s77dND2qGESIbqbk13SUSWXX4q5J 2JW2kN7lO9chK8qwM4xkDPbnsXdluOttq9qacEhbkl1TayZiSlHIJwQvBDnJzaDvGcblASK0 +kL5T9me9YILMpuMICXHXENqQlt54k70hSQBu7esB+Wvl+xQooQXrbsSsBSVcZ3BylKhz3/0 VJOPBkVrDU8cOkOOqdjsxIhZZSVN5eRwd+CBkLwlxO/txyBxgVBqjV51G5FWpnhqZRgkKIBJ SndhOSB1grn2kFOeylaVmYiaRgm/r+pmN2q1uOpQIScqOB+Hd9utt3TWn0GSEQCrhlLKMyHe s4e0nr+DxUuxJobmMLJ5JcST+utpNwCXVbjyRcEuq/JWNbTpFoxDVL2mPk4s/B9pNLKEuW1S 1gDcrup4ZP6F19/F/pDyUr7W/wC3XnfX6fvo76/T99fLex78X+kPJSvtb/t0fF/pDyUr7W/7 ded9fp++jvr9P30Hvxf6Q8lK+1v+3R8X+kPJSvtb/t1531+n76O+v0/fQe/F/pDyUr7W/wC3 R8X+kPJSvtb/ALded9v7X30d9v7X30Hvxf6Q8lK+1v8At0fF/pDyUr7W/wC3Xnfb+199Hfb+ 199B78X+kPJSvtb/ALdHxf6Q8lK+1v8At1532/tffR32/tffQe/F/pDyUr7W/wC3R8X+kPJS vtb/ALded9v7X30d9v7X30Hvxf6Q8lK+1v8At0fF/pDyUr7W/wC3Xnfb+199Hfb+199B78X+ kPJSvtb/ALdHxf6Q8lK+1v8At1532/tffR32/tffQe/F/pDyUr7W/wC3R8X+kPJSvtb/ALde d9v7X30d9v7X30Hvxf6Q8lK+1v8At0fF/pDyUr7W/wC3Xnfb+199Hfb+199B78X+kPJSvtb/ ALdHxf6Q8lK+1v8At1532/tffR31+n76D34v9IeSlfa3/bo+L/SHkpX2t/26876/T99HfX6f voPfi/0h5KV9rf8Abo+L/SHkpX2t/wBuvO+v0/fR31+n76D34v8ASHkpX2t/26Pi/wBIeSlf a3/brzvr9P30d9fp++g9+L/SHkpX2t/26Pi/0h5KV9rf9uvO+v0/fR31+n76D34v9IeSlfa3 /bo+L/SHkpX2t/26876/T99HfX6fvoPfi/0h5KV9rf8Abo+L/SHkpX2t/wBuvO+v0/fR31+n 76D34v8ASHkpX2t/26Pi/wBIeSlfa3/brzvr9P30d9fp++g9+L/SHkpX2t/26+HtDaLjRnZL 9tUlppJUo91v8h9evrvr9P31RvEwTbTKilR2vIKDjxEH10GSzB0U4WXV6bkNQn1htmSuc7hZ J8QcyOzwimRvQejHEFYtitgGSe63/B/8dJjj7sq2xoEpdsbaaWC660tJJSPC20OslZye0DHg 7eTJHuThgvKWClTxWrZns3HOK46NtS0TuRj36/4atFY/pYjqNBpcdcb05MXAac4S5gkvbAr9 pnH0+D9Ipoj6F0ZKQFt2w7T/AO+P8v79KCH32bG5akS4yQFbG3XFNJCGyRkFs9ZR+VnqnJPb TBabiGYzob3hohKGt/I7UoCQT9JAz+mmlbUtNvOMYn1/ktERjEsyfD0RGnqjRdMzpqUOcNbr Mh8gKxkpHX5nGOQ58624Oj9EXGM3Ij20qQtIUMS3+YPh+XS3GlvW1UpiOIq2pTylul6b3OpK VA5SB48nO4ZOMDFaVgfTCYbZacLjLDKWg4QU8Q5UoqAPYMqOPoFNO2pN7RauIj4nsmK4jEkr Wdqh2XVkqFAaU1GShBSguKXjOfCok+Cir3wlDGuZP0soP3qorqyXih6T3ggMPhhyY+iNxSje EcSStGcZGcZzjI7KdV/BNJSpSF6yZyDgg2knn+1rFj2dhmBoi7h55T796ZaKFFOxKRLV2YGf B4Se2ularuT1otk+dHS2p1pY2hwEp5rA54I8dd7atvUVn8Ocace8wTh8E76fk6yZH5LQfe17 8VUnzzZ9EH3ta8vUL0QJKJ8GbxGn1IMeOdu5tvfhSuKceDwH9HbUzWrIyYaHZDLpLbDDktxp I2Ml0AjkTuPb4Aazu3+0rt06YXxVSfPNn0Qfe0fFVJ882fRB97T/AEtu314X24wV3C2wmo3D 4ZkoJU5uTk/8RPZ/6im7qfaf3NunUMT4qpPnmz6IPvaPiqk+ebPog+9rdnanCJTDENpSgbii E6442dh/phJB5EZHb288ZwcQxNTSJUixobY4jM/jb3OGEHqEjqjecYxk5JyOznyDd1PtP7m3 TqGR8VUnzzZ9EH3tHxVSfPNn0Qfe0/0r9I5nej+DY7598O9/yTweJu7e3dt2+Htz4Kbup9p/ c26dQyPiqk+ebPog+9o+KqT55s+iD72tuLq2O5AadLT8h0x3JLgaaS3sbSspKiFLPiPIEnl4 KsP6qt8dmS6pL5Qw00+MIALrbmAFIBIJAJAOcYNN3U+0/ubdOoLnxVSfPNn0Qfe0fFVJ882f RB97TnEuTM2ZMjspcPcqwhbmBsUojJCSDzI7CPBXzeLkiz2mRPW2pwNAdRJxkkgDn4OZFN3U +0/ubdOoJ3xVSfPNn0Qfe0fFVJ882fRB97TKu4z7Ypg3TuZ1Egpab7lSpKg8QTswokEHGArI 59oA5ga1NEccaSqPJbC5JhqWsJwh7n1DhRPgHMAjmOfbhu6n2n9zbp1Ba+KqT55s+iD72plf BpPVvzrZnK8bj3nPPH/za01atacm28soUmA+JC3HnWzzQ2kncjB8YVyIz9AyM6lrvLV1SlTU aS2hbYcQ44lJQsZxgKSSAQRzSSD9FSdS8/MrFKx8Qwk6FvSUgDXjWBy/3KPeV70Gvfn4z6FH vKanw8plQjuNtu/yVOIK0j8oBGf10uxb9LRFuM64vRkxYElyOtLMdW9zbgAglZAyVDlj9PhG GlfoNe/Pxn0KPeUdBr35+M+hR7ytRepojanWnY8lEpt9tjuYhJWpbgyjBCtvMZ7VeD8marmq m+74aEp4ccrkolh1GVtFlG4gbSQf0ZoKvQa9+fjPoUe8o6DXvz8Z9Cj3lblrvLV1SlTUaS2h bYcQ44lJQsZxgKSSAQRzSSD9FXJclEOG/KcCihltTigntIAycfqoFfoNe/Pxn0KPeUdBr35+ M+hR7yrjV7ntN2uZMRGMW4uJbS2yFb2ivm3lROFcu3knHgzU0LVMOf3NwY8sGUhwsBaAOIpH ykg5xnHPPyfBnIIAZvQa9+fjPoUe8o6DXvz8Z9Cj3lSW7Va3odskTkpYEkSFLKGtySloE5B3 5Ty8YJJB7ORNperoLMZbz0aW3tjokpQpKCpba1BIUMKI7SORIPOgo9Br35+M+hR7yjoNe/Px n0KPeVpPaqt8dL/FS+24y620W1oCVErGUnmQACAT1iCMHIBrUhyu62VLMd9hSVlCm30bVAj9 YI+kEigWeg178/GfQo95R0Gvfn4z6FHvK1tQ3V61R4a2VMI48tDC3HwSlCVA5VyI7MeOqcTU 2JLrMnhyWu62YrEqInDbinE5xzUfk454J7RyoKvQa9+fjPoUe8o6DXvz8Z9Cj3lWrhqhSGQI ERxbpuHcBU4E7UrGM4G4Zz4OY+kjw/KtSPxrhcUzG0txLa2jjLS3lTq1Dlt6/VySMAhXLOSK Cv0Gvfn4z6FHvKOg178/GfQo95WhI1ZAhBwS2ZLC2n0MuoUlKijekqSo7SQRgHsJPLsoZ1VG ffUyiBcOK2EqeaLIDjQJxkozuPgPVBwCKDP6DXvz8Z9Cj3lHQa9+fjPoUe8purLg3J6TfbtB WlsNQ+DwykHcd6STnnQYvQa9+fjPoUe8o6DXvz8Z9Cj3lWoerY70aKOE/JlPtLeDbLSUK2pU RySpZyeqeQKjyJwKsP6qgxnpKHGZYTG4Rec4WEoS5jBOeYxkZGN3iBwcBm9Br35+M+hR7yjo Ne/Pxn0KPeU3UUCj0Gvfn4z6FHvKOg178/GfQo95TdRQKPQa9+fjPoUe8o6DXvz8Z9Cj3lN1 FAo9Br35+M+hR7yjoNe/Pxn0KPeU3UUCj0Gvfn4z6FHvKOg178/GfQo95TdRQKPQa9+fjPoU e8o6DXvz8Z9Cj3lN1FAo9Br35+M+hR7yjoNe/Pxn0KPeU3UUCj0Gvfn4z6FHvKOg178/GfQo 95TdRQKPQa9+fjPoUe8o6DXrz8Z9Cj3lN1FAm9ALtu3dOGM+PvIPeVJ0GvXn4z6FHvKbqq3K SuHapkpsJK2WFuJCuwkJJGf1UCudAXZRydcME+PvIPeVINDXoDA12z6FHvKmRqxtTlnHHiKR IjuPTeGdymSlvfyAJI555HJ5UXHVyWbU+9GjONykx25LSJKQUrbWsJ3dRR8fYSDzFBWVoC7L OVa5YJ+myD3lYWrbbd9JWYTRq9uY4XEIRHTaUt7gVpSTuKzjG7xHwflDojU8JcosFqSkCYYR cU2Ngd8AznnnB7Ozw4yMrHwtfi+x/wBon/FboKHwmjGt3vzdH7y6KPhO/Hd783R+8uioLCfx T+D/AP5+1/8Au1066uiO3GFLgNsPr46+a2gg7NqweYUtOc48FKUK3zLnpXQ7EAMKkt3RclCX 3ChCuE666UlQSojIQRnB7a2pKNZqlPFdy0w0srJU33xUNhz2c2M8vpqia4Wt2/vtOONvweA0 82A6lC9/FQUZG1Zxjt59tV06OQhe4SGF7mmG3FPREuKHDSEko3EhO4AZyFV8BnWJ7Ltpn0kf cV7wNZeVdNekT7igaqV0tXaPd58+JDfR3Zw9yHWWl7dicDBD4+mvO5taeVNNekT7iomka0ef lNInWHEUILrpmqCAV5wN3c/by+8UFoaZU48h4THGmjcE3EsLaSVBfLckqB/VjsyflciPqLpc xItqQ3PUHreXdroaHWS5ndyJOCMjB5jlzB7KrBnWJ7Ltpn0ifcV9oia1cUUouWm1EAnCbgTy HMn+L0DM4oobUpKFLIBIQnGVfQMkD9Zpd7mf6Qd9O9ty2bM9z8RrbxcbeJ/C4zs6uMVF3NrT ynpv0if8vXy6zrNllbq7npzYhJUoieonA+gR8mg8a0UlhiOlEphx1qOtgqkRA4nBWVhSUlXJ Q3Ec8j6K0JmmIsyRFU4rLLcfuZ5vbjjNggpHVwE4UM9UDPZ2VmpTrMx47ztx07H47SXkIeuB QraoZHLgV7t1ef540v6S/wDsUG7Z7Z3qhrbW9x33XVvPPbdvEWo8ztyQOWBy8VTXG3sXS3vQ pIUWnRg7TgjByCPyEA0vcPWB/nfTHpI+4r3g6yPZddM+kT7igkuNrujzlvVIlOzRGfbe2R47 bYJRnJVucByrPgOBg8uyqvemV/UZ3+9e+XyWPqfwv3/dX0Ua0M2NEbnWF16QVBAamqVjakqJ JEfl2ff+XE/cWt/KGnft5/y9B9xNKKhvQCi5OcKDxwykNJ3AOZ55OesM9uMHA5Dnm1arCu33 KRPdlJcdfbShxLTXCQtQPNak7iCo+MYHM8udU+4dcf1/Tv28/wCXr3vfrn+v6e+3q/y9BvyX nGGwpuM7IJONjRSCPp6ygPvpbbszkq33O2vxpjKLhJXJ4yg1hokhQBAcJPNI8HPPg7al7366 /r2nvtyv8vVdhvWr6JDgm2FDbD5jqW5NUlJWACQCY/Pt+4+DnQW3dMLfkPTHZqe7VyWZKVJZ w2C0MJBTuJOQTnrDweLmMaXLM1iZ3eoPIfkPuFDQGVupCeqCTtxgdu7NVyxrMDJummsePvif cV5wdYnsu2mfSJ9xQaNqsK7fcpE92Ulx19tKHEtNcJC1A81qTuIKj4xgczy51oXABUNxpUR2 Uh0FtbbSkpO0gg81KT9xzzrA7n1mf50016RPuKhmHWUGG7KcuGn1obGdrc5SlK8QAEeg+2YE 4dwsyoc5+HAWFx2glhCsp5IK1B3ntHLkBnw5r50tYn0wrRLmOOtqhh/ZHW1tUlS1EHJ7cYGQ MZye3GBUr0bWkd4svXPTbbo7ULuJBH6DHr54WsD/ADvpj0kfcUH23o5KUxGV3BxUWMiQ2hsN gK2Ogg9b+kN3bjBwOQ55+X9HLlRFtP3BO8Q24bakMYCUIWFZIKjknA8I/JXwhOr3FFKLxpdS gcEC5ZI/8ipBG1oey56bP/iJ/wAvQX3LG6ZtylMzUoM0tbm1sBaNqElJSoE9YKB8GD9NWLHa RZbeYqXlOguKWBzCUZPyUgkkAfSTzyfDWIlGtVzjERNsKlpYU+tSZqihCAQOau58eH7ueOWf vgay8q6a9In3FBe1DFkze40R476lR5CJKXEJbUklOeqQpxB8NZ7dikzpj8qSl+PMXIZkpdU2 3wgWhtSnYlxSjkFWeY/R4ZBF1qrsuemz+S4H/L173HrcnHfHTnpA/wCXoJW9LlDaUqnqWRdB cStTQyr+ycED9IH6Kkm6ZROVed8pSRcg1ySj+DLY5eHnk48X/rVbuLW/lHTnpA/5eq8fplIh NS+79PtMvFYbL05SCvaopJAMf6PvFBdGlwVNK48ZotzGpO2NDS0jCAergHPMknJJ+gCprxp9 y7yEKXO2NIWhbeGvwjJB5ltYIxnl8oK5jPixQ4WsD/O+mPSR9xXvA1key66a9In3FA1Urpau 0e7z58SG+juzh7kOstL27E4GCHx9NeCNrQ9lz02f/ET/AJeopCdaR+CDOsDinnkMoS1NUolS jjwR+Q8NBMrSLhsTFpNwbWw2hQIcjZG4qKgtOFApUMkdpBHg7aqjTr8653qG6/JbiOCIguuI 3F9KEjJCjjrZT28xzOQeWLC2dZNuKbXddMpWkkKSq4kEEeAjgV5wtYn+dtM+kj7iga6KVeBr I9l1016RPuK97n1n5U016RPuKBpopRbTrR1+U2mdYAmKEF11U1QQCvOBu7n+j7x4a+tmr/LG mPSX/wBigbKKVOFrHytpn0kfcV6I+sz2XTTXpE+4oGqilRxrWTTK3VXPTmxCSpW2eonA59gj 5NfKEazMeO87cNPMcdpLyEPTylW1QyOXAoG2ilMN6wPZd9Mekj7ivrgay8q6Z9In3FA1UUrd z608qaa9In3FRqb1r3bFiIm2F16SVBAbmqVjakqJJ7n5dn3/AJaBtopU4WsT/O2mfSR9xXvA 1key66Z9In3FA1UUrdz608qaa9In3FeiLrU9lz036QP+XoGiilGOjWklt9xM6wpaZfLBcXNU lKlgAnBMfn2/cfBzqTgay8q6a9In3FA1VRvCHHrVIjtsOul9tTX4LblO5JG7rKSDj8tYoi61 PZctN+kD/l69EPW57Ljpw/8AiB/y9BE5aHpgtMd6HObahx1xlr/A9YLbDZVycOMdvYa+jo0K tj0MyozZWw2yHGYSUHqqCipRyVKJ2jwgeHFRzka0gQ3ZTs6wqQ2nJS3NUpR8AAHc/jqV6NrS O6pp656bbcT8pC7iQR4eYMegitliflSpS5LjrDLV5cloaU1jiY+SpJPgOefbnAxjmTmfC1+L 7H/aJ/xW61kM6ycUEouumVE+AXEn/wDopf1jZ9TT7ZwJ8qyu7ULfHc8ta1JQ0OKvkGUjmEYG T2kfTQRfCd+O735uj95dFHwnfju9+bo/eXRUDRov/d2iPzmb+7JroVutcB+M46/AjOOqkPkr cZSSfwqscyPFXPdF/wC7tEfnM392TXTLQSYKspCT3Q/yBJ/4q+fP/wD3i5VR9d5rWP5th/sE +qjvRbPJ0T9gn1VdooKfem2jst8T9in1V6m129CHUJgRQl3HESGU4Xjszy54q3RQUu81r8mw /wBgn1V47ZLS8ytl22QnGl43IXHQUqwQoZGOeCAfygVeooZU+9Vu/qEX9in1UG1W4pKTb4pB GCCynn91XKKCm7aLa9s4tuiOcNAQjcyk7UjsA5ch9FfHeO0j+a4X2dHqq/RQUe8tqH82Q/2C fVXvee2D+bon7BPqq7RQVW7Zb2nkOtwYyHUZ2rS0kFOeRwccq973Qf6nH/ZJ9VWaKCJEWO2k pQw0kHtCUAZr47gh/wBUY/ZirFFBB3FE/qrP7MV8G2QC0powY3DUsuKTwk4Kv6RGO36atUUF MWm2p+Tb4gx4mU+qhVptq0LQu3xVJWnaoFlJCh4jy5jmf11cooKfem2+T4v7FPqoVaLatJSu 3xFJPaCykj/6VcooKb1qt0h1Tr1viuOK7VrZSSf0kfRXx3ktJBHeuFg9o7nR6qv0UGUjTFgb UFIsdsSpPYUxGwR91Wu9VuH/ALBF/Yp9VW6KCqi2QEKUpEGMlS0FtRDSQSk9qTy7Por570W3 ydE/Yp9VXKKCp3rt4SUiBF2ntHBTg/dXibTbkABFvipAGAAykY+6rlFBW73wv6nH/ZJ9VfCr TbVMttKt8QtN52ILKcJzzOBjlmrlFBRFltQ7LZCH/wAhPqr0We2Dst0T9gn1VdooKneq3D/2 CL+xT6qO9dv3IV3BF3IUFJPBTlJHYRy5GrdFBSXaLY44pxduiKWo7lKUwkknxk4qZEGI2kJR FYSByAS2BU9FBTNptqlblW+KT4yyn1V6LVbgciBF/Yp9VW6KCoLXbwh1AgRQl3HEHBTheOzP LnigWq3JSEpgRQkcwAynA+6rdFBUNrt6hgwIpHiLKfVQm1W5JBTAigjsIZTy+6rdFBTNptxS Um3xcEYI4Kez9VDlotr2zi2+IvhpCEbmUnakdgHLkPoq5RQURZbUOy2Qv2CfVXos9rHZbYf7 BPqq7RQUxabaOy3xP2KfVX0i2QGnUOtwYyHEZ2rS0kFORg4OOXKrVFBR7zWsfzbD/YJ9Ve95 7Z5OifsE+qrtFBT7023yfE/Yp9Ve96rcOyBF/Yp9VW6KCoLXbw0WhBjcMr4hRwU4KuzdjHb9 Ned6baP5vifsU+qrlFBV72W/KT3DGylW4HhJ5Hx9nbQLZABJEGMCfE0n1VaooKi7Xb3UFDkC KtJ7QplJB+6uZ6n4fTJxLiHXEuOsoKGRlZBSkHaPHjJ/RXV64P8ACBcLzB1TfIVvZZWJ4aCJ agA7E/BISoJV2lBAztHhJ8ZpAv6p1DdItqZZ08WLah95LRdZxvQg/wBo81KJwM1lxEXFMaYb jPnTFm3TCFSpK3cf7O5naFEhOfox4PorAFqnWKTFuUZruvggpVFlEuIeSobVdvyVFJI3DHb4 M5piYusG6xJS4EhTjSbbNJadzxmFGO5ltzlzII+V4R24OaspESrfCd+O735uj95dFHwnfju9 +bo/eXRWVNGi/wDd2iPzmb+7Jpgd1PPt0iVEYajKSh93aVpUTzWTzwfppf0X/u7RH5zN/dk1 93CXFXcpa0SWFJU8sghYIIyaosXrX+o4cAzIMS3OJYTiU040srRzxxBhYyg8vB1TyPaDSsPh t1I2+hxdutLrA/hGkpcbUfyLKyB+kVtF6NvDqZDAcSCBlSSCPCCDyIIJBB7aQZWlm51/fWss R7cpe5DLbpII8KSTz2/R2+DJrlal5tms+nWtq4xaPZuR8MGo7pICLKxZ1pUo5TIZc3tAHnkB zCvAMggZz4qcoWsru5YrzLlNQG5EBpC0nYtLeTnJX1idox4Ozn20tQG9O6ftzG78K4pS0BEZ WQhICccglXbk9uOyqkWYm+6O1S5KYVDVJW2hpreAsFLi9hBUBk4QFZx9IreJiPTlecx6eOfD Tc42oIEaSi3JhPLbDwMR9LyEHkVbdxwTjcE4PJSeZ5mvrUnwwX+z32VBjx7S400yw4lSmnVb itOSAQrBAPYeQIGfCBXL52mrzLnPuu8WUFLDgU7KbG9R+UT+rGeWKZGrAJS5M+88OXKWnmXp jq1LUAcdhyeZwMqGBnlXOJtjEuWlNq+r+3R9MfCZcrzYXpcpmAmUJL0ZtphtwqKh/BAIydxU QoYKk5xyyeR1IWtrlKsz81TMPchcgI2BRSUocWlJznnkJHPlnxDsHHJWkWg6F2+W+02tOdhk pJSSc88pGCTgnBPMdvZWxpeC7YG7gwt9S48ppfJbqFbF4URgDxkn9f691t235TM/Dqk7V1wj NwFNsxj3REbfXuSrkpWcgdbspYsfwkajuF9uDcpzTSbVFWpBcQtaXWzvUkBYUvkeoc5AByCk nnU90fj8K1JL7QUi3MBQKxkHGcH9BB/TXP3tKriSbs/bZNomIujwW9HufEAQOsTtU2sZ5qPI jsxz5c+tZiJzMZadD1J8J8mBd7BDs0qzTkzXFpllBLpawUYA2OdUkKV257PoNMlzu1+s+mbl dnpNtkKiW56QltENxsF1KNySSXVdXkcjt5jmMc+FDSM0gA2zRZA2jBlTMcgAP5f9kflxzrba Y1THs11tsUaMYRdWlty3+PJcfc3JKclxalEkBRxnIGeypM5HTNN60uV4Tp8yGIie+MbjO8NC htPCC+rlR5ZPhzX0nWl1gOr7521uRGySH4AOUD+0hRz2eEE/kpf0uhq3StMRHJUdaoURTby2 3AUApZwTnxcj24rQb1rAsrfD7hlvOKOVOsrbWFY/IskfpxUgbUbWPdfDXEkQpbanUIWEJUhx rcoJ6yCSfD4cfkpd1B8JN3s90kNJat3crQSd7ja88xk8wr/0rLut8t2opy5LkZ2NIZYDUNS0 7Fh1av4TiJztCAAeZ8J/TLG03YTdRcbjd03F5ACWhJebKUADHYO09vM86sYGzp7WGrb26JDs C3xLcQClS2l8Rz8g39X9Oe2tfpVPNtlSeFG3tXBcVI2qwUhOQTz7ahRcrYkBInxAB4A8kf8A rWMiTG7xzdz7QDl3dWjKx1htHMeMcx+sVBsI1hcldrMX6qvaqrM1re4zS1NxIToUMtuJBwOz kob8/pB8VZCJMXwyWP2g9dL8pptMcMIUpeOaSFt4/frnfy/tdNPx/uOun9d3a6h/uhiEktkY 4aFDtz41HxVpXLVlwh256Q2zGK0YwFJVjmoD+l9NIWl197eOJBaCHSOfGTkcz2jP01uXuZDd schLUllTh24SlxJJ6wPYDW4z+WLYz6MN81RdIM6TFhtRCUBOwuoUeZSDzwoeM0pI+FO+ogd0 Pw7cOMklhaUL27knCkqG/txg/pHjrUv8qKb/ACj3QySClJ/CDkQkAj8uaTb5bmu5HV2+QwW1 ELcjBYxuH8pI8B/J2iqhoZ+Eu8uMNrMaBlSQThtftVag69vk64Mx0sW5CFZUsltedoxkDrdv OkCKsltlkNqK9qQQrqgcvCTgUx2SIiNMTLl3CEgJQQGm3QTkjwnl4q9OpOlFMR8p7PbGppzt zkRi1HCG4KpKTtVkqCsYPPsrKt+ubpJuM+M+xDSGFJDZShWSDnt630VXjS4vfyc6mSyWhalp KwsbQSsYGfHzH66zSuG3PTNakx8kbHU8VPWHgPbXmVqytd3mItSVxoRBSCg7FePw9avuLru5 zJ/CZYhlpKQFqKFZKvDjrdlZN1RFmRQGp8RLqDkEuivuzogQWk75sUqAzjipGT+uqGI6suPf 9qAhmKW1McRZ2q3A5P8Aa+igatuBsduncGNxJPF3jYraNqsDHW8VZ8GRb233pr86IZD424Dy eogdg7azm5EdGl7Khx5tKwHlbVLAOC4cHH6D+qoIr/8ACVqK0x7dIZh21TUuKhwlbTh2uFAU ocl9nWT+v6KyJnw1Xp25QoVqgwFKU0hUhT7SztUB1yAF8hnknJP0+Kvu9wYVwsC4MWRGZdGw tuOurd27BgAJK8DlkcsUv6X0tGhXB165SmXVqVkuB5TYPgAwlfYO39ddM18fj2YdTiauvK4b D0qPCSt19pvCEK5JU4lJ/lduFVdf1POafgoDUfbIlNsqylXJKjzxz7aXmU2RtxtfdCDw1pcS Fz3FDck5B2leDgjNSSpUV+baEMSWXVC4MnahYUQMnxflrmNK4avuseXJZYYiK4bqkJ3IUSQC R4FUvS/hA1YHv9nRZm0f0XorpI/SHMH9VSzZUNdzlOJlMKSp5ZSQ4kgjJ518B+CcbpEc/lWK orzvhN1VBiiR3tt0hKdxcQ2y4FEbTgp657DgkY5jIHPFM9q1w/co7TjaobyXUcRp5tKgh5Ax lSQVciCQFJJykkdoKVKxHF219gtLkxtp8HET66TJdvnWmU6LDcYrbUlwOOJWdyW3B/xkY+Sv BII7FBRB5Eg5t5ROYbr44xLq7eqZy0XglqNmFweHhKue/tzz/wDpWJZPhAvNxZkGRGhIcafU 1hDaxyGO3Ku3majjyo5Z1C4ZDQQ4YoQreMKPM4B8J5H9RrJY7ljTHHWpDOx8guDiDqqxjI5+ Hw1WDFd9d3SBanpTTEMrRtwFoVjmoD+lWlG1TcnGG1OsRkuFIKwEqwDgZ/lUpSDEmuNtPSWB HQsOHLqeuRzA7eytRE2EkfxyP+1HroNyTqeczDfeS3GKm21KAKVYyAfpqKbqy4R2YK22YxMi I2+rclXJSgcgc+ysedOhKtkpKJkdS1MrASHEkk47O2s++yiiJakx3WOKm3shQLgBScZGR+Qg 0EuqfhI1BaLfGct0O3vSpEpEdDbqFkHcDj+WPDjnmlpHwwa9ZmmNP0/b2XFNlTKO5nQXVApG Enic/lDs8YrGvLNyuPcwLjYEZ9D6NigclPZUC495k3OA+Sye593WccSMEqQc9v8AYrdJrmMp Ofw6VpP4QdR3eVc413t8GK9ELWG20KyAtO7rZWeeMfkpmZ1LNcvlvhKajhqTxN5CVbhtTkY5 1z6yMdzzZM9+XFRJlKRxiHxg7UhI5fkpkiy4qtT2dxMlhSW0vqcUlwEIHD7SfAORrM+5VSv/ AMI2oLWlp6PEt62FZCytpZKT4OxfYf8A0+mr+iNcX/Usx/uy3xkQm2iQ+yysDiBSOruKiM4U TjtrILsJ1otuusLQoYKVLSQf11gStIWCUrKJiGu3CVLS4lPZ2AnP312pbT8PG0e+0/Jr1P8A CDqSw3+TETboghBSRHeeYc/CjYgqwrcArClEcuytayavvM61tyZsWI246SW0oQoDZ4DzVnmc 4+ikq16X01b3w8p5iQsdgWUIT4O0A8+zsJx+WmhM+Eo5VNj/ALVIz99YvNcYhWuzqi4yLRJk pRES63NVHBKFFIQE5yQFZJ/TWO9r68pXhqLEKFHDa3GVo3fTjf2VHClxm7FLK5DKeJdXFI3L A3DaOY/WP11SltwZIUtM6MHVBKS4t0EpQFZIAz21xmJ/CwaIeob2+0haxBXnmeCysjH5d/30 T9YSYyQllthbmRkBKlYH6DSchLYkIxIihC31DJeR1W8ciefaTmrEONDcCFTJ0XBQtKkiQlJT k8uYPZgCrGUMT2rroxZHZym4pcTgBKmFoGdwB7VVk6njNO6ikqWgKPU54/sCvu/zYTlgkssz WHF9QJQl0KJwpP0869v8qKb/ACv9pa5EJP4QciEgEflyKozu50ONltacpI7PFS+LG1aZ13kN Ajuq2ysnwHbGdA/Tg/8A0pmblRB2ymf2g9dUrs8y6y9wnW3MW6dnYoHH+zq8VAvfCd+O735u j95dFHwnfju9+bo/eXRUDPo1tDtt0S24hK21yZqVJUMhQKZOQRXSDZ7EFlJtdvBT25jIA/Xi uc6J/iOhvzqZ+7Jro8/5f/xn91NY1bzSuYbpXynDzvPYPJ1t/YN+qjvPYPJ1t/YN+qk7UWsm NOXBMJ6FJfdfYS5HLLLi0qWXUt7VFKDtGVo5p3HmRtyUBc/TC2JuVziO72hbWFyJDi1t5CEY 3HhBRdxzyCUAEYIJCkk8N+/zhvbr2au89g8nW39g36qO89g8nW39g36qVXtUiKGESrLdmJMh 8MMxy02tS1FC1pIUhakYPDUD1uryKtqTuqO7a0t1jiw5NyZejNyN+8PrabWzsIC8oUsKcxn/ AIQXnGU5ynLkX6NuvZu7z2Dydbf2Dfqo7z2Dydbf2DfqpRianc7s1D3xgPRYFpdV/tZ2FPDS y24chK1KKjvUoYTjbgHCsivibqmVFdtyFWW4MOSJnAXHdaStxaSy8tJbU2tSMlbYByrqjJVt BCqci3Rtx2ce89g8nW39g36qiegaajqaS7CtaVPL2NpLLeVqwVYAxzOEqP5AaSLj8IUOAttH cExxx9o8FKWHFYeS+GFtuFCVAbXFJGUFeeeActhyD4Sf/wAIf/qWH/8Azqxr2zjBtx2f+9un vJsD7Kn1Ud7dPeTYH2VPqqCiufJv1DWzVP3t095NgfZU+qjvbp7ybA+yp9VQUU5N+oNmqfvb p7ybA+yp9VHe3T3k2B9lT6qgopyb9QbNU/e3T3k2B9lT6qO9unvJsD7Kn1VBRTk36g2ap+9u nvJsD7Kn1Ud7dPeTYH2VPqqCinJv1Bs1T97dPeTYH2VPqo726e8mwPsqfVUFFOTfqDZqn726 e8mwPsqfVR3t095NgfZU+qoKKcm/UGzVP3t095NgfZU+qjvbp7ybA+yp9VQUU5N+oNmqfvbp 7ybA+yp9VHe3T3k2B9lT6qgopyb9QbNU/e3T3k2B9lT6qO9unvJsD7Kn1VBRTk36g2ap+9un vJsD7Kn1Ud7dPeTYH2VPqqCinJv1Bs1T97dPeTYH2VPqo726e8mwPsqfVUFFOTfqDZqn726e 8mwPsqfVR3t095NgfZU+qoKKcm/UGzVP3t095NgfZU+qjvbp7ybA+yp9VQUU5N+oNmqfvbp7 ybA+yp9VHe3T3k2B9lT6qgopyb9QbNU/e3T3k2B9lT6qO9unvJsD7Kn1VBRTk36g2ap+9unv JsD7Kn1Ud7dPeTYH2VPqqCinJv1Bs1T97dPeTYH2VPqo726e8mwPsqfVUFFOTfqDZqn726e8 mwPsqfVR3t095NgfZU+qoKKcm/UGzVP3t095NgfZU+qjvbp7ybA+yp9VQUU5N+oNmqfvbp7y bA+yp9VHe3T3k2B9lT6qgopyb9QbNU/e3T3k2B9lT6qO9unvJsD7Kn1VBRTk36g2ap+9unvJ sD7Kn1Ud7dPeTYH2VPqqCinJv1Bs1T97dPeTYH2VPqo726e8mwPsqfVUFFOTfqDZqn726e8m wPsqfVR3t095NgfZU+qoKKcm/UGzVP3t095NgfZU+qjvbp7ybA+yp9VQUU5N+oNmqfvbp7yb A+yp9VZ2pLbaW9HX2REgRG3EW+SA42wlKh+CVnBxnsNWqhv34hag/MZP+Ea6aWta9sSzfTis ZhyH4Tvx3e/N0fvLoo+E78d3vzdH7y6K9LiadE/xHQ351M/dk10i4JIWCR2qJH6k1zfRP8R0 N+dTP3ZNPWo5s+Fc9PCLcGI0eRcOBIZXDcfXIBbWQlJR8jG0qKjgDG4nCSledSnnXDVbeM5Q uwor/H40ZlzuhoMvb2weI2N3UVntT1lcjy6x8dUTpy2LlOyH2npRd35blyXX2hvBCtra1FCc hSk8gOqojsJFakabP6fT4DtwYcgi3svsw0Q3Atola0lSnvkdYpOE9p28gNiiuPXzRVoW9SES Jcd+JCfksuRZLjCkuIaUUklCgSM89pyDyyOVcONP2dN3/DPi6ctkR5p9DTzj7TvFQ9IkuvOB QQtAG9aiSkJccwknAKyQMnNF205bL3u7uaeO9osucGS6zxW+fUXw1J3p5qwFZA3Kx2nNO4zb npm7XtVte4tttVkYnONT5L0ha8OS1KQgqUSFLCccRRVt2JGxQxt1BqJLOsdSQVz7apcK2R5T bTklTXDH4XeHcqUEgdRRWEAhLiMhWE040/PkbsdI3rDa5M1yW/DQ646kpcQ4SpteU7Cotk7C oo6m7G7b1c45VHF05bIjzT6GnnH2neKh6RJdecCghaAN61ElIS45hJOAVkgZOauaI1I7qO3S XJD7D7zLu3fGaQG9pAwNzb7yCrOcjfuAKcpAKSrH1JqefY9ZXBuO+wW02qM+1FkcRXdLock/ 7OyBhKXncAA5KuoMNuAHa40/Y3Y6abNmtrDMllEJktyt/HC07uKFrWtSVZzlJU44cHkNxwOd KXwnvNR2dKPPuttMt6jiLW44oJShICySSeQAHhNMw1nJVPhWtpuIu7O3OZGdiq3o4bTaJC2C tQCuGXEtNKBIO5KlKSkgcsOLK1In4M4N04m+Zd3bfxQu6OEFL620rWlXC3MqXxNpQjqtjrN4 UMKtf0+JzMk6uYxhs9LtMec9j9JM+1R0u0x5z2P0kz7VUrzqe+aYm2yyx4zb7q46FoEuS0sy nVLUO5m3nXWSSjCU79jqyFoKk5+WwWC5X66vOyn021NvRNlxA2gLDu1p5xtLm4kjPUCSjHjX vH8HV41O5TeszOl2mPOex+kmfao6XaY857H6SZ9qtfXNxXaNDXq4NSGGHGIi1pU+pSUqOOSA ULQoKV8lJSoEKUCMnkcvUOtRbLzaGYs62rhy0IeOxbb77zalYBbb4zaiCPkltLxUcgIykBbj U7k3rPjpdpjznsfpJn2qOl2mPOex+kmfapzfLyY7qo7bbj4QS2hxZQlSscgVAEgZ8ODjxGud 2S8Xi36ItV4nzGIzl34K3ps2SuTGjBTKnC+sK4fD3qCW+ElYbSVI28yQpxqdyb1mj0u0x5z2 P0kz7VHS7THnPY/STPtV5adSakvk92PCbtSW48RuQXXUuYl5fkNpLeCdjbqWUuJXlewKHJ0H IZNS3J6zaVu90jpbU/ChPSG0uAlJUhBUAcEHGR4xTjU7k3rFzpdpjznsfpJn2qOl2mPOex+k mfary4apvFrmO2+e7aojn+zuruC0LMaC26JGA5lad+FRw2F7mwovJ6oI2qpq1FdVXew3WTco kO1uR5bK/wDZXFomrS+2lBaAc5rebSVspAWQCvHEzkONTuTesu9LtMec9j9JM+1R0u0x5z2P 0kz7VVo+ubs7qi5QVRILceH3SXG5MhphUdtoK2vuK4qnOGshB/gEgJdCtygkFexojUjuo7dJ ckPsPvMu7d8ZpAb2kDA3NvvIKs5yN+4ApykApKnGp3JvWUOl2mPOex+kmfao6XaY857H6SZ9 qrerNT3LTke7vtW5yQ2zbDIhLQwpaS8gOl0OqBCUISkNK5lJVlQTuVyGXP1peGn7i3BRBlTm +7EN2dDK1S2OEh0tPOYXlTbhbbwNiP4w3hR5bnGp3JvWWel2mPOex+kmfao6XaY857H6SZ9q tezanj33UNyiW99iTAixIzrclnJS4txbwVtX8laRwkjKc4VvBOQQF/4R9Tz7TbrvEiPsRFJt S3WVL4gelLUHEq4Ckc0qZCUuKO1XJaclsdenGp3JvWWel2mPOex+kmfao6XaY857H6SZ9qqV 213coAurjKra4/FRN/6LLau6IqWG3VNyHiF5LThaRgbEcn0YUeW7cQ9eLq7d9PzZLESUYjD4 kwQsFlt9TqFISSclxIaVtd6oypJ4Y24U41O5N6yh0u0x5z2P0kz7VHS7THnPY/STPtV93yVN sWqrEpN1bi2VMJ5laJLTshT7oWztbCuJlx9aQrZyUvqucl7uTJfZUyDp65zLdH7onMRHXY7O wr4jiUEpTtHM5IAwOZpxqdyb1ix0u0x5z2P0kz7VHS7THnPY/STPtVFP18ruW6y4PDbhx0MI jynmUrQXVOuhW5RebbCC0hpxBU4jIebPMuISc+F8IN6uNpn3SPHtoiWy2Ge/uytUgoelNqQj YsoSFiNuCtywjOPwoO4ONTuTes1el2mPOex+kmfao6XaY857H6SZ9qp7JcZ7Gtr7brldGHEu y98KEIzgdDXAaIcB3qCWQQtBO0JLu7rAq2Vc1w5cmNOoftk1uGtqbFW+842paUMh9HEKtq04 QE5Usk42JWDjO4ONTuTeszOl2mPOex+kmfao6XaY857H6SZ9qorrraTEQ2uLMtqwmEmQzxWF pN5d3LSWYgKwQSW04I4uQ+2QCMFbpPk9x26TK3MJ4LS3MyHeE2MAnrrwdqeXNWDgc8GnGp3J vWKHS7THnPY/STPtUdLtMec9j9JM+1VKLr993R064rlxFS2ZCGkPtxmjHSFYOFLTLU0DyV8p 9BBKBtypAXJb9dXS4WWPKahMLeuLTke3KbTvbVLbfWyouFC1DhkbHQEKWQht87lBAJcancm9 ZZ6XaY857H6SZ9qjpdpjznsfpJn2q8tGsLtcdcybOqEwiOy68hxkraS8w2gkJeP4YuKSshGB wUDDqTuIAK2y3XSJdUSFw1uLQxIcjLUppaBxG1bVhO4DcAoEbhkZBGeRpxqdyb1ip0u0x5z2 P0kz7VHS7THnPY/STPtV58IGuHdH8BbJYO1pb7rL6UJ46U4whtxbzfW5EHYl1QyklPNIXGvV 9+ix1z12+JLYXNuEGLCipXx3VRxJUhRVzGVCPs2BJ5qCgr+QHGp3JvWS9LtMec9j9JM+1R0u 0x5z2P0kz7Vfekb3Ju+qr0ly5RLhHYhQ+DIghaY7pUuTuWhKioA8gglK1glvmQQUJk1IbxM1 lZ7TEVwoLkR+St1qcthxK0OMp34DagvYHMhtZKFlR3DqjLjU7k3rIOl2mPOex+kmfao6XaY8 57H6SZ9qqV213coAurjKra4/FRN/6LLau6IqWG3VNyHiF5LThaRgbEcn0YUeW50tnfj8L327 hO7C2+5N42Zzls7vlbeX4Qbd2T1EY5uNTuTesWOl2mPOex+kmfao6XaY857H6SZ9qrcnUtts 2urjHu97iQWFWyGthuXKS0kq4skLKQogZwEAkeJOfBQNRJZ1jqSCufbVLhWyPKbackqa4Y/C 7w7lSgkDqKKwgEJcRkKwmnGp3JvWVOl2mPOex+kmfao6XaY857H6SZ9qspj4QbvItENyGiJO lvXPuVxbEcKQ2yWHHCtIZkPBxaOGVFsL3qACdqStCi+WSVMm2diRPj8CQrdkbCjekKISvYrr I3JAVsV1k7tp5g041O5N6xY6XaY857H6SZ9qjpdpjznsfpJn2qrR9YaiuOqLlZ4MKCh5nulD bMlbaVMbAoNPOYeLqm1qDfLgo6roIUQAV2Jut5Bsc67x2e44iOAzHVNjjcl89Z4ObnW20pSF Jb6zicOocRzVtSpxqdyb1nvS7THnPY/STPtUdLtMec9j9JM+1VKNq1m7DQ9zkTm4b8y5yoim kTAluSlLb7ediVqQsFxDJHNe0rSAo5yrQGty3PhQH0t92KucxiXHZYcccZjtokLaVtTkha0t NqSDzWCooBHY41O5N6z46XaY857H6SZ9qjpdpjznsfpJn2qXka2vOoLLcERZ8Fl63S7fIems oQpsMLfIWFBmU4EpSGypZLgygqBSkdctE3UrTc7RxN1gqZuMtxlSsLY7oUGXAHGgXObZWEgA hxKuK2UnO1Rcancm9ZB0u0x5z2P0kz7VHS7THnPY/STPtVSu2u7lAF1cZVbXH4qJv/RZbV3R FSw26puQ8QvJacLSMDYjk+jCjy3biNTrtDt3Gp34MZmBEYnLfZ3BDaHVOpDXPJcUC1gKATv3 gBCTyLjU7k3rKHS7THnPY/STPtUdLtMec9j9JM+1Tmw+zKjtSI7rbzDqAttxtQUlaSMggjkQ RzzUlONTuTesSOl2mPOex+kmfao6XaY857H6SZ9qnekT4Q20PS7MhYyk8fIz9CKcancm9ZJ0 u0x5z2P0kz7VWbhcYFz+DvUL1unxJrKYclBcivpdSFcInBKSRnBHL6RSldrDFtzkQFsYWjY7 1vku8zjO7xcvyp+mmyZDjwfgturcZpLaV2t5xWP5SiySST4a1TRrScwzbUm0Ylyv4Tvx3e/N 0fvLoo+E78d3vzdH7y6K6sGnRP8AEdDfnUz92TXQrtNdhXiz8CxPz1SXVxnJbOz/AGNsp3FS iog7SUJyByO3wq2JVz3RP8R0N+dTP3ZNPWoF6fF4sDd8mMIeVLJt0V8p2uSQnqrAIzuSCQnn jc4ORVsxRYiTXelFxtybE/HjhpqSbn1A3JcUNhTyO4qCUJGTzwnngbCs1XcJlo0ldrnALAlQ ojklAfbK0K2JKikgKSeYBGc8s554wa8Ren165uIbmMP6iREaDraikuR42cpQnA5JKiVntOVp yccMA1nNsUTTjjWo3uHbZjrUNwCSWCviLCcbgpJ2gZUrB+QlWQRkUFO86juFuvNosUdLbtwk x1PuvGBIUw4UKQjYCjdwgpSyS4SsNgDclW5Jpgu1yZs1mnXSQlxTEKO5IcS2AVFKElRAyQM4 HjFY7N0043eYSDLbD7EJluFLel7kvtylHahC1KJdWoxQcnJOAQTk1oS7zaiufb+/kSNMjx1O vhMhvixUbQeKpKshIAUk5UMcxnINBTm6vgRLw/aGWn5tya4IEaMWypa3EurCMqUkJUEMrWdx T1duCSoCo061tqoF1l8CWBa4RmSmyhO5O1byFtjrYK0qjuJPPaeRCiDms+x6VtEhEzdKtshb S0RNtkQYSIamlOK2p4biltu5kOhRCxkKwQMq3WLvp/RaURLZd+5Ge60KjNR35qm1TMqzhQ3g vLC3CoKVuUFrKgQpWSDBdrkzZrNOukhLimIUdyQ4lsAqKUJKiBkgZwPGKy7jrC2W9NyVnjJt 7TTry0PsoQeI64ztC3FpSFJW0sEKIx2DJ5Vck3awyUSoUq4W11AjurksOvIUAylRbcK0k/IC gpKieQIINLdr6DXLSQvUeQxHgOcJ12Wu4Ft6M4U8kreDm5tz8KrcAsEqecJyXFFQWGvhHs8h hUiNGnSI7UQTZL7KEKbjs73ULUpYVtVsUyvIQVFQ5thYyRoWS/Tbnfr7b5FqfYYt8vgtSSW9 ihwml4OHCrceIVDqgbSkHCsiqbNt0XDgOwkyonAu8dEZXFuKlqlNvLeWgBSllSitTj5Cgcqy cE7eWw/a7RFnu32QhtlxpBccecdKWkYRtLpSTsCwjq8TG7Z1c7eVBX1XepdhtLMuHAcmuLmx o5bQUckuPIQT1lpGSFbRz+UpJPVyRHcNWMWzPHt048CImbP28I9wsq3dZzr9b+Dc5Nbz1Dy5 pzTOrNM6g05b5S5DbtvuS9ilh5I7kWlhUn8IpKvwS0JbzkHKVbSMdoJNt0WEWtD8qI0iYgIi p74qQLilSt2F4WO6gpThJC9+S6onO85Bknzo9st0mfMc4cWK0t55e0nahIJUcDmcAHsrDf1e IgjomWG8sSpMgR2YxabcU4otuLSQpC1IweEoHKuryK9qTurcn9x97pPfHgdw8JfdHdGOHw8H dvzy24znPLFKdhkaLkWGLqePOb7naWh8y59yU6uM4psoDbri3FbSlL6hwyrALhIGTmgku3wk WSxusNXJL8V5bXGfafU00uOjcpJJStYLnNC/4EOZ25GQpBVcf1pb2NTu6e4TjlwCCWWm5EdS n1hvi7Ajib0EpB6ziUJ5fK5pzYkt2CdIbvCpzaVxo7cpUiPPU0ksZUpC3diwFtcnCN+U/Lx2 qzl2rojdNXzUwZG67WqW4pUZNwWW0uFsBx1DAcKBzeUlStgO8rzzySEcPX7TGhbVqC+wnITs 1DKUNqdZbS+tbXEKkKU7sQggLI4i0nq4xkgFksl5h6gs7FzgL3x3twByDhSVFKhlJKThSSMp JScZBIIJx7pY9NWSxy5UhjueO1tcDgmqYW0U5Shtp1TieCnrqQlCVIQOIocgpWdhVwtdq7ng P3FhlwcJlpEmVlxZVuDYys7lKVsVjOSopV2kGgz+mFsTq/oy4dk5XJs8dlW9XD4mNiVlxPVB OVoSnl2805k1Zfjp2yCWhpxx12QzFb2x3HghTiwjepLYyQnOduRuICQQVCh3T9jhT+/j3EYM Vbkrcua6mOyooUHHOEV8JJIWslW3tUonmSaz+lmmb/YbTOXIbdgTZDa93GSBFdabMscYpVhB QGckZODgHkTQV57DFxlacN3hOKfuS1x3nGOKy0+hLTjqG3mi4hWFBKlcNxLoTlxB+VuOou/L gXy/t3J1hFst1vYnpcQyre2hXGDm7md+ODkbUjtxg4yS6r01OmWGVPujCXi6HrUU3FTIfWoA AoSlYDuQsDsVyWR2KOadue0petWX9th9uTdEo7hnxnJhdQ60lKSQGCsp2JLhQTtGFFweE5C5 pjWFs1V3UmCdr0XYXW+Oy9hK87TuZWtHMpVy3bhjJABBLBS3d7ZbLZpObCfcuTsOUtLLjapb kh18uqS2GUreUopDhIR8pIG8nKT1hciXaBHatMFEbuFcrczHgucNlbQaSdwCCobkp2hP4PcO aSMoO6gz7ZqWVddX3K3R2dkO3umO6Hob6FKIbQviJeI4Z5rCQ3jJT+ECinAIzrFCbPCmSIE5 x+bcJEBqKywniJdbU91FAOKT/wAEpK923PWOxOduhbpENGo71b2YT7EocCbIdWQUSOIgtpUn CiRgR9pBCfk5wc5OPD6I27TyrnaZHfKJbpbktsx7guYsyloUkoQVOHc4vikBBPNTmcblZoLk nWcKJNtcORDlsSLgsIS3IU0wW1b9hH4RxPEIVnk1xOW0jIWgqksl+m3O/X23yLU+wxb5fBak kt7FDhNLwcOFW48QqHVA2lIOFZFR3ZmwTJFvVfpLkORNQlpq3yboppL5yMtKZS5w3TlYSoYU DkDmMVqd5Ld34769z/7X27t6tm7bs4mzO3ibOpvxu29XO3lQST7kzblww+lzZKkCOHABsbUp KikrJPIKUAgeNS0Dw1lp1MiS/YzGYfEW5y32EPqbSpCg2h1SSDvBCVhvehYCwUjmBuBFjvhp /Ulu4LVxgzor7vBSqPKSrLqRxAEKQchxITvG07k7dwxjNU5belHpFpQ7OiMLtshLcBlieWEo dJW0lAQhYCj+DdbCSD8lxOPlCgsQNUwrhqWZY2W3EyIiCpalutAnBSD+C38UDrDClICSMEEh SScuVq+a1pNi7xrW+++5dUwVxihtC2h3XwFA/htpUMbQoLIKilRATnboXCBabA1P1LIROkKh tPTFJcmOvhGEqKi024soQrbuSNoTgKKcgEio7dbdLt2uRZ4cpt+O7NcQtCrit5aZQ/CLCVqW VodBSXMAhSSCvkcmgYGHFPR2nVsuMLWgKU04UlSCR8k7SRkdnIkeImk+VrC5sxNaOC0ONd40 PKjPu8MtLKI7bqUrCXCslRWVDAA2EAkKyK1DdrXYmIkC3Rn5aVcZWyF+GWlLawH3VkqytSVr G4Dc4pSj1VHdVOXCsF51FPhP2mXIK0KiS5CSrucOrYGUqSFdV0sLA420dVQRxMkIoLD+s4Ua BPlSIcuOYaGnVMylNR1LZdWUNuAuOJSgKKV9VakrG0gpBIBpxNbm6XqytWq2vy7bcIkh1cht bJ4a23m2lc+KAUoKlbikK3ZQUFQzViSvR17aduyrpBdSrayZ0a47CgspccwlxCxsUlDjxO0g 7FKz1asR9L6dlWeG0wz3RBG95pwS3HOMl5XEWFObiXW3CdykqKkq5ZBwKDcfeTGjuvrDhQ2g rUG21LUQBnklIJUfoAJPgpHtGq5I+DmXqBEBtqHHhJfisR4K2jHRw92zhuqQl1Dadp4iFpDg CglKSBl8rLe09bH9NDTy2HBaxHTF4KH3EHhJAARvSoKxgYPPmMg5yaCO7XCZBvVgYZLBizpb kaQlbZK+TDrqVJUFADBawQQc7vBjnnw9fWSdqhVgZdzKDrjCFcVo73WworTwwsupxsX1lISk 7eRO5O7Uk6ft8tdrW/3WpdrWFxVd2vAhQTtyvC/wh25BK92QpQPyjmSLZYUG4vzYyX23HtxW 2JLnByo7lKDW7hpUTzKgkEkqJOVHIF0vMOzqh92r4bcp1bQdUQEN7WnHVKWSRhIS0rn+Twcx njUyH5lpbjsPpZm3CVBU4ttJAWwHgQeuCncWVEKCVck4ISVAjUuVqg3eOmPcIzchpKwsJX48 EH9BSVJI7FJUpJyFEGmrS9pV3s/Avp72OqfjcOW6jDis7lrwocRSsqyV7id6853KyGHK1hc2 YmtHBaHGu8aHlRn3eGWllEdt1KVhLhWSorKhgAbCASFZFMFqvjN1kSI4iy4r7KEO8OU2EKWy sqDbgAJKQooWNqtqxtO5KeWY5+lrNc35L0yHxFSmltPJ4qwhQUgtqVtBwHCglHEA37ernHKt BEGO3cXp6W8Snmm2XF7j1kIKykY7ORcX+v6BQY824Xh/UL9ttJgt9xxGZTgltrV3RxFupCAp KhwscE9ba58sdXq4VYOo4qpj0NmFdXpTe8BAtr7aHFJBOEurSlrnjAJWEnI586kuWnrZdpCX 5jDilhAbWEPuNpeQCSEOpSoB1HNXVWFDrK5dY50H2UyY7rCy4EOIKFFtxSFAEY5KSQUn6QQR 4KDLiSrdqJ9mS1HfcRAd4rEhxCm0h4oW2tIScKKkpWpKgU4ClFPy0KCa824Xh/UL9ttJgt9x xGZTgltrV3RxFupCApKhwscE9ba58sdXq4VqQrVBtq3FQYzcYOIbQptnqowhO1OEDqghOE5A zhKQeSUgV7lp62XaQl+Yw4pYQG1hD7jaXkAkhDqUqAdRzV1VhQ6yuXWOQjOpYAmPRTHuvEa3 7iLTKKDsBJ2r4e1XYcYJ3cgMkjNPRd+m6lsybpIabQxIQh1lIjusqb3JCi2eIMOBIKcPIO1e ThKdvNkrLesEF3TQ0+hLjNtEdMThIVklgAJLe5WTgpG0n5WCSCDggNSio2GGYsdqPHabZYaQ ENttpCUoSBgAAcgAOWKkoCiiigKjfYZlR3Y8hpt5h1BQ424kKStJGCCDyII5YqSigKKKKApU 1Q247qPT6WUtqd/2hSOISEhQQkgnHPkRnHhprpbvn426c/7z/higXJdhvEiO4mVf4JbPWWTh PYc5zj6M1vXTHxX3HDgdHed3DgBAV+BPPB8dZdz/AN1TP+wX+6a0Jv8A1Tzf+Sr/AMA0HKfh O/Hd783R+8uij4Tvx3e/N0fvLoqBp0T/ABHQ351M/dk10a6W+XPn2pTL7cdiJIMl1zhoW4rC CkNpCkkJCgtW5YIUANo+WSnnOif4job86mfuya61VGWxb5Y1LMubr7aI647cZqO22gle0qVx Fr2hecrUlKAopAyrmV4TJerZ33thih7guJdakNOFO4JcacS4jcnIynchOQCCRkAg8xoUUCnL 0Wq4IvLs24NvT7nZ+9ZldypBZBU8pRQAc7MupARnOGk7lKPOs+X8Grcpd2Qq5OGPMRMVGQtT 6jGekpcC17eNwiBxnQAG0nChlROSXyigy4VkZt95kTY/DaYchRobcZtsJS0llTpGMcsYdxjA xt+nlj6i0Q3f7yJqprjbD8dESbGLj6UvspUs7RwnmxkhxwErCxzGAOe5sooFuHpFmEuGtp5t K2LxKurqksBJeU8l9O1XPtSl5I3HOQ2BgZ5Z72hZLthg2zv44kWtbYtqkNraDaG21tDiFtxL i1lDigpSVoBKU4SBuCnSigV7Poi3WuU++62xK7ot6YTqXW1ObsuvOvHc4tailxb2SlRPyRkq 8DRRRQKcTRammbHFl3BuXDsshtyGwuKkAIaZcab3EkkuguJUV8hltO1CDknPk/Bq3JluOKuT imJS3kzWCp9tLzLkh57YOE8gZxIcSSsLB5EJHMKfKKApLe0LJdsMG2d/HEi1rbFtUhtbQbQ2 2tocQtuJcWsocUFKStAJSnCQNwU6UUCmnRKURYTbUttDkFBcYUWVOgyVOh1xxwurUtaFLCTs K8g9bcVpbW3qR7NIiX6XNYuGyHLdEl+NwQVrdDSWh1yeTe1CTtCd24Z37cprYooMvUlqevmm rlaWJLcVc2OuOXltF0ISsbVHaFJydpOOfI4PPsOXctId9e+78qUx3dcrIm0l9EXHC/hStaQV E7VF1J2Z/wCGMk9oaKKApTiaLU0zY4su4Ny4dlkNuQ2FxUgBDTLjTe4kkl0FxKivkMtp2oQc ktlFAh3v4PZt0tL9uY1A5HYfXMU4ktuhI7oeccOEtvNhRAc2nib0naMJTlQUyR7NIiX6XNYu GyHLdEl+NwQVrdDSWh1yeTe1CTtCd24Z37cprYooMfUunYep7Y1BmtMONty2JIDzIdH4NxKl Jwf6SQpBPiWe0cjHcbC8/KsCrdIiQolpkcXufuQqC08JTQQjatIQAhxeOR57eWAQdyigW52l 3rndL65Lnt977tbE25TDUcpdbSnidYOFZBP4Zz+R/R8R3SaY00qw91PyZXdk6TsQt/fIV+DR koTh550jBWs8iB1uzw0wUUC3fNNzbreY06Jc27eG0JStbLbofXhRI6yXkoUBk7UuNuJBKuRC iDsXa2s3mzTrXIU4libHcjuKbICglaSkkZBGcHxGrlFAny9FzLo+udcL1suZ2IRIt8cx0ttp Q+31Ula1BzbKeIXuwFBs7TtIVGPg+Z7lvaVzG1S7rbHYKpHcwyyp12Q66pHWzsK5HJGextOV KPOnSigz77bO/enrnaeNwe7ojsbi7d2zegp3YyM4znGRS+jRUhl9ma1dGEz4fBbhK7hCWUNN IebQlxpCk7lbZLuSgtpzswlISQpwooE+2/B9AiXS33Capi5SoXdZD8mG3xFrekh9C9w5BTZ3 gYA5rUQE5xVgaEs5VqVRjsNuX7iIdfYjobebbcaQhaQvBzlSFOc+W5WSCeZaKKBLt+gG2ZUK ZcJbc2XGmolKcWH3AtLbTyWkYffdKSlb6lhQPbjlnnW5Og3REy1iySIMKCiWt24Mrjbi+hQU TtIIworVuJ8JO7JwUr2KKAooooCiiigKKKKAooooCiiigKKKKAooooCiiigKKKKAooooCiii gKW75+NunP8AvP8AhimSlu+fjbpz/vP+GKDGuf8AuqZ/2C/3TWhN/wCqeb/yVf8AgGs+5/7q mf8AYL/dNaE3/qnm/wDJV/4BoOU/Cd+O735uj95dFHwnfju9+bo/eXRUDTon+I6G/Opn7sms DU3/AF9Mf8whfutVv6J/iOhvzqZ+7Jp8laL0/Mv6b5It++5JcQ6HuM4OsjG07Qrby2jweCuW tpzqRER2+l/pn6yn6W97XiZzWY9dzhvUUUV2fNFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAU UUUBRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUUUUBRRRQFFFFAUUU UBRRRQFFFFAUUUUBRRRQFFFFAUt3z8bdOf8Aef8ADFMlKeqlym9QWFUJlD0kCTw0LVtSTsHa fo7fpxQZ1z/3VM/7Bf7prQm/9U83/kq/8A1jP23VciO6yuFCCXEFBIXzwRj+lW9dWHIvwYXK O6AHGrQ6hYBzghkg0HJPhO/Hd783R+8uij4Tvx3e/N0fvLoqBp0T/EdDfnUz92TXWq5Jos4t +hz/AO9Tf3ZNOl21Ouw2GTdH47stEcvrWhlTe7YhZBxkgckjOM55Y7eVUM9FJr+ulMPoYFnn OuhlD8ltotqVGQokAqGescoXyb3nqnlzTmB34SIcdbq5ESSzCQp5Amq2lta2gsuJCRleUhtz mUgHYcE5TkHmilO3ayVOffju22TDlMpQtbEhbZVsUVBKsoKk4JQsYznq8wMjOh39X8z/AHv9 KDcorD7+r+Z/vf6Ud/V/M/3v9KDcopRna3Zt7kht6M7vZjh9CUkZfyop2Ng/KXu2jHjcQP5Q qKPrwyHHlG0ymYTLjzbk511lLKeEpSVKPX3AZQRnb9PIVuNO2M4TJzopXVrOAmGuYqVFEVvb vfMlOxO4ApyrsGQpJHj3Dx0L1nAa7k4kqKjuzHc26SkcfOMbP6XaOzxjx1PC3SmiilpGrYjk 9yAh6OqY0ne5HS+kuITy5lPaBzH6xXxbdZQ7xGVItzrUllLimlLacBAUk4I7P0/SCCORBp42 xnAaKKV5WsYsJxbcj8GtLYcCTklYKtuEDb1zuKRtTk5UkY6yc/aNWxHJ7kBD0dUxpO9yOl9J cQnlzKe0DmP1injbGcBlopUa1xbHoplNToTkcKUguolIKApKSsjPZkJBUfoGeyvtes4DXcnE lRUd2Y7m3SUjj5xjZ/S7R2eMeOnhb4wZNFFKMHXUC43Gbb4zjS5UNwtuNB5JUcBJKgBzwCra T4FAjwV8K+EC2cJh5qRHfjvPKZL7MhCm21JaU6d6uwAJQf1jwc6u3f4wmTjRSo7reC0gLU4g pUyl9spUVB1BIALeB1ySUjCcnK08usnN/v6v5n+9/pWZrMfMK3KKw+/q/mf73+lWHLrwoUd7 hOuvSHC2zHa27lqAUSAVFKR1UqPMjs8eAYsRMziGpRWfbbgq4iSCw/FdjPcFxp8IKgdiVjmh ShjCx4asSpCIUN+XIe2MMNqccVtztSkZJwOfYKmfys1mJ8fysUVXVIQiY3EU9h9xtbiE7e1K SkKOezkVp/XWXG1AJL8JKYUxEacrEaUoNcNwbFOA4CysApSSMpB8eKZhY07TGYhuUUtjVQ7g VMdhSoraUqWtEpHDcQBnJKeeOzP5MVlac+EBd/7p/wCjuBwNv/G3bt2f7I8VVmYmJxJ5opWu Ws41pbYVLbd/DuhlpDLS3lrWQSAEoSSeSSezwVX6eM+Sr36Hl+5ohxopat2rWbrAanQ0KXHd KglSgUHKVFCgUqSCCFJI5jwVZ7+r+Z/vf6UG5RWH39X8z/e/0qGXqhuDGXIkI2NIxk5ySScA AAZKiSAAMkkgDJNAxUUtR9UqfeLKobrLyWW3locWnKd+4bSU5GQUnOCR4ia+29TJclPR0NpU tkJKwHUnbuzgEdo5DPMeHlnniZa8ZMVFLKNXw3GC+h+MpoEp4iZCSnIG4jP0AE/k51Yb1DxW 0uNtpWhYCkqSsEEHsIOKZJrMfMN6ilfpcEzpEZyI42mO0HlvrcQG9pzjn2/yVdoHyT9GfmVr WHEjl9xbRQl9LCiHk9VZIBB8WM5PiAJpmFjTvMxEQaqKW1asjI4G91hPdGODl9I4ucY2+PtH Z4xX0jVDLj5YQppToBVw0vAqwDtJxjwEEfl5UzCeNvnBiopZTq+GuKuUl+MqOg7VOiQkoSeX InsHaP11GvWsNuZGiqW1vkt8Ro8ZOFDIAx492eWO3B8VMwsad59YNVFLrepkuSno6G0qWyEl YDqTt3ZwCO0chnmPDyzzxGjV8NxgvofjKaBKeImQkpyBuIz9ABP5OdMwnhbozUUrvavaYXFK 2iWJJCUSErBb3HGxJPg3Z6p7CeWcqSDc7+r+Z/vf6VWW5RWH39X8z/e/0o7+r+Z/vf6UG5RS gvXTCLHOu5ivdzw+6OInI3HgqWlWB2cyg45jwdlFn1sbx3Tttr0fudzhL4khhzrj5SfwS14U OWQcHmKBvorD7+r+Z/vf6Vnta2jPXAw0tLyVKbQ6f4NxxOd7aVY5qSBzH0KAyULCQbKKSlfC AhOmZN8NrlhqNxuNH3N8VPCWpDn8racbVHkrmByyeVbPf1fzP97/AEoNyisPv6v5n+9/pR39 X8z/AHv9KDcpJ104tm62J1s4WhTyknHYQEYra7+r+Z/vf6V8Ku6VuJcVGSVpBSlW7mAcZGce HA/UKBXv8pL0aOhgFKJo3qx/JSD1k+D+Vy/JmmC7/wDVlc/+UO/4Jqz35/8AyP7/APpSNeNS 3Oa3eoa3gmIqLOb4KUJxhDCsc8ZzkZ7fVQKfwnfju9+bo/eXRR8J347vfm6P3l0VA0aL/wB3 aI/OZv7smtDVcmDJsM2xi4tRZEgym1qLKneGlxxQOQCOeCcc/CDzHbQ0T/EdDfnUz92TTdJ1 LbbNrq4x7ve4kFhVshrYblyktJKuLJCykKIGcBAJHiTnwVQiXgwLz3MX7pE3tt7FOG3KU40r wuR153MrPbkleClBxyO6NbVudWWVX1bcJD0iSwGI60SG3Xg4FHi5IIHGcKcIBHV5nB3O7GsJ J1AqM8uItAkSGnrYwytc2I00HCmQsJUSpDnDRtAbTnjt4Urlvw7Z8JM2e1JZck2prhOsBy6r DZjRkOJeILiWpLiflMBAJdTzeTy5DeGRaWbBBbfRKctzqHSkiPGtxYjoKd3XDZKuud2CrPMJ SMcuekqTpVaUJVHhqCBtSDEztGScDq8uZJ/TV2z6of4GlXLhOYYVcr3cWVsSHXUuclyQ2lJU UEpSQhvYtvtW3yQoJFaDeq723tlvxoLsV64T7fHjspd4iix3QpLilAKPMR9hQlCjk7gf+HUx DcXtHqJYhm6YLy3i1E4q929fcvWVuyFZO3nnJz4818iTpUNqbEeGEKIUU9yciRnBxt8GT+s0 46MvkvUFrXOkS7a+gL4QEIoUQoZJ37HXUJOFJwkLVyG4nr7EV9Ralk2q8iIiXbYSEx0PNJnN rUq4rUpYLDO1QIWnYnO1Lp/DI6nYFPGDdv3JLlu2h7f3PchFS0ziElqOoJivZUS6AMBROUjB 8AUOxagcvuG3BF1bRcrahNxTKQ4+m1LEja8VKwXN/WCSoeDmEgcu0Pj2ulx348NwwUT++E1m Sy8pTSGGGkSVsrcXz4W9LTStygdyStSUkDlJprVN3v8AZn3obdtuExqQEqy6I7AbKc8nGVyk qWCOadwIBBIAKSrtXWvWMVlifc5kkOsWxKpqoV8djmTtJy0528Z51QKkFCsEvnASpJG0ZKgS DDCiwoMVbDd9aX3S2pmYXYLju9Bddc6m9RwfwywSviZwMjty46g1nqK0XaDb+9cFEp5pK0td 0tqRLcU4pIZadecYIUAlGSlDhHFTlPIbxWp58zW1nt5fYab76yWnYbXES8yhtiQEcY80qS7t S6gEI5AbQ4AVpvI1MYz/AOkxBdhyIcW9vTjeUJjrUtQjMMPISdxz1gpakZz1iUoSSrnnBUDZ sl4YhwXGrjcYrrypDriVRYi2k7VLKhkc+fPJP08yo5UdHv7Puvwd98LZeoPHjXvZLlscR1oN Im9ZZ/DEob4e1xQKykNEgYSQUtjWqbQzHs6Zl2ice5r4MVe0tJlOAc1NpUSdhI6pyQdyMKVu TnNtS1oxJhzm7x9J3yUZM9SHXgyGm1qYyWsK3ZGUHJzjkrIwCMYUoKrONW6RJuAfvXDhTW3m 1R4rDyOTgIJIUtTeeZUVJQklXMnBUFdbZvlrkXyTZGp7C7nGaS89FC+uhCuwkfqz4tyScbk5 w7hrSDIszM+yXa2qiOTVQ37k8d8eGUpWSpwBSeRUlKB1kgl1BBIICrGvqRGIkxBGU5AmToky 53OLIejyEPANW9SEkIQ6EDmVKyFOlWSogbRgAkkw6iat15jLjRb13Ew424hxpLD20lZJUvDa 0AkkknfvB8Qyrdr27XN1Ys6nXXYjL4XLkNRZocW7cV91yEiJHKy2pK0BtCBlCiOK2NicAK2F 6vv0WOueu3xJbC5twgxYUVK+O6qOJKkKKuYyoR9mwJPNQUFfyAjXvFotE/BiCzKctcpy5tG8 Lbg3JKu6GkRzxCpTQa5LIICdqUnG3O4Z3Y6tfCnIEydEmXO5xZD0eQh4Bq3qQkhCHQgcypWQ p0qyVEDaMAEkl50PqS4ajjzHZaYjrDK0palRVs7VqIO5BS0++AUjYclYzvHVGMlspvXxjJhx F206TmcRc95El4qdLbio3Nre+t7llJyQVAdbIIB5AKUFM/SO0/1v/wAtfqro9FZvqWv/AFSY c46R2n+t/wDlr9VWXNQ2JUeNKRepkaXFZeQlMVkFTgWpKin8I2U5JQnHMfSafqK5zGW62ms5 gitajsSdMItrtwYdeeSBN3NPBDhcVmQQQkEFW5wjGACR2Cr1y1Tpm5wjGXd3WfwjbiXGmFbk qQsLSRuQR2pHaDTZRTELOpbOf85c6RqO0qZnolXBU1U55MVTklpSVCGnO7dw0pAJ3PbSkZ/C I3YwdusjWVgdvTkl2UlLbDPBjucJ3crcQpzkBjb1WwMgHKVeAglvoqRXDVtWbOQ6+v7N2bMe 1OcZp5QLq9pTgJAwMKA7TzyP6P01laLlM2nu7u5fC4vD2cirON2ezPjFdzorTk5DfLtb5j1s LYalNtSHS808khBSuM+31spPV3OJBwFHBPI1C9PS5CEN67MTGGkpO19l0GX2ZbdPWIRyPPrl QUkL37F8bslFByiy3y3xrYW5EhSHDLlu7VIJO1yS64knGRkpUk9vhrQ6R2n+t/8Alr9VdHoo OcdI7T/W/wDy1+qqtwutluMNUZ2YtIKkLStCFbkLQoKQoZSRkKSDggg45gjlXUaKDkhurSZX dLd3ih1bDbTu6C4UqUkqO5I3jaCVnkSfy1Iu6W9c6Y+q4MKakR0shpcRagMbsFXPrDrqyMDl jn4+r0VPGHTdt/Ij+fhxhx6CsQ23ro4+lEsPFSUufgsNr2qHEKyTuKeWSOQ6vys7UW9WaJHD SJilDKlKUptWVKUSpRPLHMknly58sV02ipFYj4W+te8YtLkkqdb5T1xKro2lqZEEYJEZe5GN 2FZzz+WrlgeDxc/p6ZZnFuqanJaBbYS0hLCtqC0tS08scxkgYGOQ7efLrNFPGDev3/PX/wAh x6U7bJj6XX7spZW2GpKeG8hLiAVHACFJx8tQ627lj6Sbka4WWPHdQmWkOLfdfDqY5CkrWVdY ZSeYCtuT4B4uVdVopFYj2W1tS0eMz6cajuQmJCpJvKVyAUFsrYeWlO0OJ5ha1KOQ4rkFDBAP jzcNwt4LDjV1S2+gOJWtMU4IcUFLKU4wDlIwTu8OQonNdZopFIhbfqNS05mf/EOTPz7ZJlTl PXJPc8uMIxbRHWFpA3c9xyP5avB4vFzj7rtj81mZNuLTzrbiFYREWlBCEuBPIk4ILhOc+Ach 2112injCRrXiMRLkapVpcQww7ct0VuUuUtsMLBcXxeK3lXgSlXPA5kpTzAylXp6GmS7JMC3G Q7v4jvcI3L3ghWTtycgkHx5NdborTnMzM5lyEM6ISwtgWy1hpakrU2LeNqlAEAkbO0BSsflP joWzoh1DaHLZa1paTsbCreCEJyVYHU5DJJ/KT4669RRHGI7zTTMuC5e4i7ZJckrU13tWXQHl rWRuUpSDgr8LZBAwRzojM2BziG8OW6dltlltlFtKGGkNb9m1tRXhQ4qxnOMYAAwc9nooOQrZ 0Q6htDlsta0tJ2NhVvBCE5KsDqchkk/lJ8dUosSxxbhFnJu8lTrM+RMUlRfLag7xeqGyrYkj ijrAZO09m412uig4oCwrSdysrt8jF2aqQe6EwHAlCXlKUsbN5ycrXg7uXLIODnQkOaWuXCdu 8e3TpaGwhTzsDOcczt3BRCckkDJxntNdbooOSHoaZLskwLcZDu/iO9wjcveCFZO3JyCQfHk1 8BnRCWFsC2WsNLUlamxbxtUoAgEjZ2gKVj8p8ddeooOQrZ0Q6htDlsta0tJ2NhVvBCE5KsDq chkk/lJ8dfZ6GmS7JMC3GQ7v4jvcI3L3ghWTtycgkHx5NdbooOVwJelrVxO9zESHxccTueJw 9+M4ztSM4yf10rqkl+833YgcA2+Y4h3bgq3Mv8v0AA4+mu+Vjav/ABKv3/LpH+Gqg4r8J347 vfm6P3l0UfCd+O735uj95dFQM2kXDGsejpimZDjEeTLU6WI63igHuhIJSgE4yoDs8NdC6V23 5m6+iJXu6/P0TUV7t0NEWHdHmY7e7Y2lKMJyoqPanPaTUvTDUnlmR9RHs1Uy750rtvzN19ES vd0dK7b8zdfREr3dcD6Yak8syPqI9mjphqTyzI+oj2aGXfOldt+ZuvoiV7uo39R2eVHdjyIl yeYdQUONuWaUpK0kYIILWCCOWK4P0w1J5ZkfUR7NHTDUnlmR9RHs0Mu2Wy42C0cUxY98U47g LekwZ8hxQGcJ3uIUraMqITnAKlEDJOdDpXbfmbr6Ile7rgfTDUnlmR9RHs0dMNSeWZH1EezQ y750rtvzN19ESvd0dK7b8zdfREr3dcD6Yak8syPqI9mjphqTyzI+oj2aGXfOldt+ZuvoiV7u jpXbfmbr6Ile7rgfTDUnlmR9RHs0dMNSeWZH1EezQy750rtvzN19ESvd1G5qOzvLZW7EuS1s r3tKVZpRKFbSnKfwXI7VKGR4CR4a4P0w1J5ZkfUR7NHTDUnlmR9RHs0Mu8DUdnTIXITEuQfW hKFuCzStykpJKQTwskAqUQPBuPjoZ1HZ4yChiJcmkFallKLNKSCpSipR5NdpUSSfCSTXB+mG pPLMj6iPZo6Yak8syPqI9mhl3zpXbfmbr6Ile7o6V235m6+iJXu64H0w1J5ZkfUR7NHTDUnl mR9RHs0Mu+dK7b8zdfREr3dHSu2/M3X0RK93XA+mGpPLMj6iPZo6Yak8syPqI9mhl3zpXbfm br6Ile7o6V235m6+iJXu64H0w1J5ZkfUR7NHTDUnlmR9RHs0Mu+dK7b8zdfREr3dHSu2/M3X 0RK93XA+mGpPLMj6iPZo6Yak8syPqI9mhl3zpXbfmbr6Ile7o6V235m6+iJXu64H0w1J5Zkf UR7NHTDUnlmR9RHs0Mu+dK7b8zdfREr3dHSu2/M3X0RK93XA+mGpPLMj6iPZo6Yak8syPqI9 mhl3zpXbfmbr6Ile7o6V235m6+iJXu64H0w1J5ZkfUR7NHTDUnlmR9RHs0Mu+dK7b8zdfREr 3dHSu2/M3X0RK93XA+mGpPLMj6iPZo6Yak8syPqI9mhl3zpXbfmbr6Ile7o6V235m6+iJXu6 4INX6jP88yPqI9mvel2o/LMj6qPZoZd66V235m6+iJXu6Oldt+ZuvoiV7uuC9LtR+WZH1Uez R0u1H5ZkfVR7NDLvXSu2/M3X0RK93R0rtvzN19ESvd1wXpdqPyzI+qj2aOl2o/LMj6qPZoZd 66V235m6+iJXu6Oldt+ZuvoiV7uuC9LtR+WZH1UezR0u1H5ZkfVR7NDLvXSu2/M3X0RK93R0 rtvzN19ESvd1wXpdqPyzI+qj2aOl2o/LMj6qPZoZd66V235m6+iJXu6Oldt+ZuvoiV7uuC9L tR+WZH1UezR0u1H5ZkfVR7NDLvXSu2/M3X0RK93R0rtvzN19ESvd1wXpdqPyzI+qj2aOl2o/ LMj6qPZoZd66V235m6+iJXu6Oldt+ZuvoiV7uuC9LtR+WZH1UezR0u1H5ZkfVR7NDLvXSu2/ M3X0RK93R0rtvzN19ESvd1wXpdqPyzI+qj2aOl2o/LMj6qPZoZd66V235m6+iJXu6Oldt+Zu voiV7uuC9LtR+WZH1UezR0u1H5ZkfVR7NDLvXSu2/M3X0RK93R0rtvzN19ESvd1wXpdqPyzI +qj2aOl2o/LMj6qPZoZd66V235m6+iJXu6Oldt+ZuvoiV7uuC9LtR+WZH1UezR0u1H5ZkfVR 7NDLvXSu2/M3X0RK93R0rtvzN19ESvd1wXpdqPyzI+qj2aOl2o/LMj6qPZoZd66V235m6+iJ Xu6Oldt+ZuvoiV7uuC9LtR+WZH1UezR0u1H5ZkfVR7NDLvXSu2/M3X0RK93R0rtvzN19ESvd 1wXpdqPyzI+qj2aOl2o/LMj6qPZoZd66V235m6+iJXu6zNR6giT9L3aHGjXVyRIhPNNI70yh uUpBAGS3gcz4a4x0u1H5ZkfVR7NHS7UflmR9VHs0MtP4TQTrd783R+8uilqbOl3KUZM6SuQ9 sCN6wkHAyQOQHjNFMJNn/9k= --=-=-=-- From pekon@informatics.muni.cz Fri May 11 09:54:01 2001 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA05975 for ; Fri, 11 May 2001 09:54:01 -0400 Received: from anxur.fi.muni.cz (0@anxur.fi.muni.cz [147.251.48.3]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id PAA02582 for ; Fri, 11 May 2001 15:52:38 +0200 (MET DST) Received: from decibel.fi.muni.cz (mail@decibel.fi.muni.cz [147.251.51.14]) by anxur.fi.muni.cz (8.8.5/8.8.5) with ESMTP id PAA05335 for ; Fri, 11 May 2001 15:52:38 +0200 (MET DST) Received: from pekon by decibel.fi.muni.cz with local (Exim 3.22 #1 (Debian)) id 14yDLR-0006bx-00; Fri, 11 May 2001 15:52:37 +0200 To: xemacs-beta@xemacs.org Subject: Core dump on exit in 21.5.1 X-URL: http://www.fi.muni.cz/~pekon/ From: Petr Konecny Date: 11 May 2001 15:52:36 +0200 Message-ID: Lines: 109 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Persephone) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Petr Konecny Hi, I get a coredump on exit in XEmacs 21.5 (beta1) "anise" compiled and used on Debian/Linux sid box, with 2.4.4-ac5 kernel. Happens only under X windows. I have not seen anybody reporting this, so I suspect it could be Debian problem. Any clues ? Take care, Petr xemacs -q C-x C-c Relevant backtrace: #0 0x40578ae1 in kill () from /lib/libc.so.6 #1 0x80c0363 in fatal_error_signal (sig=11) at emacs.c:535 #2 0x40578a18 in sigaction () from /lib/libc.so.6 #3 0x402b1078 in XtDisplayOfObject () from /usr/X11R6/lib/libXt.so.6 #4 0x40139048 in XmImVaSetValues () from /usr/X11R6/lib/libXm.so.2 #5 0x40136810 in _XmImFreeShellData () from /usr/X11R6/lib/libXm.so.2 #6 0x4013ef27 in _XmRemoveGrab () from /usr/X11R6/lib/libXm.so.2 #7 0x402a66a6 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 #8 0x402a64cd in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 #9 0x402a69fa in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 #10 0x402a6afd in _XtDoPhase2Destroy () from /usr/X11R6/lib/libXt.so.6 #11 0x402a6c98 in XtDestroyWidget () from /usr/X11R6/lib/libXt.so.6 #12 0x82077d1 in x_delete_frame (f=0x85da478) at frame-x.c:2682 #13 0x814fde3 in delete_frame_internal (f=0x85da478, force=1, called_from_delete_device=1, from_io_error=0) at frame.c:1533 #14 0x80b1fa5 in delete_device_internal (d=0x85efab0, force=1, called_from_delete_console=1, from_io_error=0) at device.c:798 #15 0x80a9f31 in delete_console_internal (con=0x8651710, force=1, called_from_kill_emacs=1, from_io_error=0) at console.c:689 #16 0x80c1b17 in Fkill_emacs (arg=137338532) at emacs.c:2850 #17 0x80c95b7 in Ffuncall (nargs=1, args=0xbffff378) at eval.c:3528 configured using `configure --dynamic --with-mule --with-pop --site-prefixes=/usr/local --with-xfs --without-gpm --debug' uname -a: Linux chazelle 2.4.4-ac5 #1 Fri May 4 18:53:42 EDT 2001 i686 unknown ./configure '--dynamic' '--with-mule' '--with-pop' '--site-prefixes=/usr/local' '--with-xfs' '--without-gpm' '--debug' XEmacs 21.5-b1 "anise" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /var/home/pekon/cvssrc/xemacs Installation prefix: /usr/local Additional prefixes: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: postgresql/libpq-fe.h - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using Motif to provide XIM support. Mail: Compiling in support for POP mail retrieval. Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- From youngs@xemacs.org Fri May 11 10:17:31 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA09064 for ; Fri, 11 May 2001 10:17:29 -0400 Received: from slackware.mynet.pc (wdcax13-076.dialup.optusnet.com.au [198.142.220.76]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4BEHKl25706 for ; Sat, 12 May 2001 00:17:21 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4BECq4s014836; Sat, 12 May 2001 00:12:52 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Updated Packages in Pre-Releases - May 12 From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 00:12:51 +1000 Message-ID: Lines: 89 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii The following packages have been updated and put into the "Pre-Releases" directory: cc-mode-1.25-pkg.tar.gz ======================= 2001-05-11 Martin Stjernholm * cc-langs.el (c-switch-label-key): Regexp fix. efs-1.23-pkg.tar.gz =================== 2001-05-10 Ben Wing * LISTS: * README (http): * efs-report.el (efs-bug-address): * efs-report.el (efs-report-bug): Note that this version is modified from the original, and that bugs related to this are not the maintainer's responsibility. * efs.el: * efs.el (efs-version): * efs.el (efs-null-device): New. * efs.el (efs-tmp-name-template): Fix up problems with Cygwin FTP client and Windows native XEmacs. * efs.el (efs-expand-tilde): Use efs-null-device. * efs.el (efs-guess-host-type): ditto. mule-base-1.38-pkg.tar.gz ========================= 2001-05-11 Alexey Mahotkin * mule-diag.el: Fix list-coding-systems. xemacs-devel-1.34-pkg.tar.gz ============================ 2001-05-11 Steve Youngs * ibuffer.el: New. Previously announced packages currently in Pre-Releases ======================================================= egg-its-1.26-pkg.tar.gz pc-1.20-pkg.tar.gz prog-modes-1.38-pkg.tar.gz Installation Instructions: ========================== Manually: --------- Simply download the files from: ftp.xemacs.org/pub/xemacs/beta/experimental/packages/ And unpack them into: [1] /usr/local/lib/xemacs/xemacs-packages/ Using XEmacs package tools: (XEmacs 21.1.14) --------------------------- 1) Options -> Manage Packages -> Add Download Site -> Pre-Releases 2) Options -> Manage Packages -> List and Install 3) Choose the packages you wish to install (there are brief instructions at the bottom of the '*Packages*' buffer). 4) Packages -> Install/Remove Selected 5) Re-start XEmacs. Using XEmacs package tools: (XEmacs 21.2 and above) --------------------------- 1) Tools -> Packages -> Add Download Site -> Pre-Releases 2) Tools -> Packages -> List and Install 3 - 5) As per 21.1.14 instructions. As always, please let me know how it goes. Enjoy. Footnotes: [1] Note that 'mule-base-1.38-pkg.tar.gz' is a Mule package and therefore should be unpacked into: '/usr/local/lib/xemacs/mule-packages/' -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From pekon@informatics.muni.cz Fri May 11 11:02:33 2001 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA18346 for ; Fri, 11 May 2001 11:02:32 -0400 Received: from anxur.fi.muni.cz (0@anxur.fi.muni.cz [147.251.48.3]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id RAA10813 for ; Fri, 11 May 2001 17:02:31 +0200 (MET DST) Received: from decibel.fi.muni.cz (mail@decibel.fi.muni.cz [147.251.51.14]) by anxur.fi.muni.cz (8.8.5/8.8.5) with ESMTP id RAA08818 for ; Fri, 11 May 2001 17:02:29 +0200 (MET DST) Received: from pekon by decibel.fi.muni.cz with local (Exim 3.22 #1 (Debian)) id 14yER4-0006gV-00; Fri, 11 May 2001 17:02:30 +0200 To: xemacs-beta@xemacs.org Subject: Re: Core dump on exit in 21.5.1 References: X-URL: http://www.fi.muni.cz/~pekon/ From: Petr Konecny Date: 11 May 2001 17:02:30 +0200 In-Reply-To: Petr Konecny's message of "11 May 2001 15:52:36 +0200" Message-ID: Lines: 23 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Persephone) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Petr Konecny >>>>> I previously said: Petr> I get a coredump on exit in XEmacs 21.5 (beta1) "anise" compiled and Petr> used on Debian/Linux sid box, with 2.4.4-ac5 kernel. Happens only under Petr> X windows. I have not seen anybody reporting this, so I suspect it could Petr> be Debian problem. Any clues ? After reading `configure --help` I added --with-xim=xlib and it does not dump core anymore. IMHO configure --help is inconsistent with the behaviour of configure: --with-xim=motif (*) Used in conjunction withMule support. Use either raw Xlib to provide XIM support, or the Motif XmIm* routines (when available). NOTE: On some systems bugs in X11's XIM support will cause XEmacs to crash, so by default, no XIM support is compiled in, unless running on Solaris and the XmIm* routines are detected. I do not run in on Solaris, so it should not use it by default. Of course another way to fix it is to fix/get rid of OpenMotif. Petr -- If you think last Tuesday was a drag, wait till you see what happens tomorrow! From glynn.clements@virgin.net Fri May 11 11:28:17 2001 Received: from mta1-svc.virgin.net (mta1-svc.virgin.net [62.253.164.41]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA22536 for ; Fri, 11 May 2001 11:28:13 -0400 Received: from cerise.nosuchdomain.co.uk ([62.252.68.7]) by mta1-svc.virgin.net (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010511152808.GYKW267.mta1-svc.virgin.net@cerise.nosuchdomain.co.uk>; Fri, 11 May 2001 16:28:08 +0100 Received: (from glynn@localhost) by cerise.nosuchdomain.co.uk (8.9.3/8.9.3) id QAA01497; Fri, 11 May 2001 16:23:37 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15100.1017.568779.186182@cerise.nosuchdomain.co.uk> Date: Fri, 11 May 2001 16:23:37 +0100 To: Petr Konecny Cc: xemacs-beta@xemacs.org Subject: Re: Core dump on exit in 21.5.1 In-Reply-To: References: X-Mailer: VM 6.92 under 21.2 (beta46) "Urania" XEmacs Lucid Petr Konecny wrote: > Petr> I get a coredump on exit in XEmacs 21.5 (beta1) "anise" compiled and > Petr> used on Debian/Linux sid box, with 2.4.4-ac5 kernel. Happens only under > Petr> X windows. I have not seen anybody reporting this, so I suspect it could > Petr> be Debian problem. Any clues ? > > After reading `configure --help` I added --with-xim=xlib and it does not > dump core anymore. IMHO configure --help is inconsistent with the > behaviour of configure: > > --with-xim=motif (*) Used in conjunction withMule support. > Use either raw Xlib to provide XIM support, or > the Motif XmIm* routines (when available). > NOTE: On some systems bugs in X11's XIM support > will cause XEmacs to crash, so by default, > no XIM support is compiled in, unless running > on Solaris and the XmIm* routines are detected. Yes, this is incorrect. > I do not run in on Solaris, so it should not use it by default. Of > course another way to fix it is to fix/get rid of OpenMotif. Note that this was a bug in XEmacs, not [Open]Motif. It should have been fixed by now, though. -- Glynn Clements From youngs@xemacs.org Fri May 11 11:48:31 2001 Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [203.2.75.229]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA26116 for ; Fri, 11 May 2001 11:48:29 -0400 Received: from slackware.mynet.pc (wdcax13-076.dialup.optusnet.com.au [198.142.220.76]) by mail005.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4BFmQl17414 for ; Sat, 12 May 2001 01:48:26 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4BFixfS015806; Sat, 12 May 2001 01:44:59 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 12 From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 01:44:59 +1000 Message-ID: Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Aww crud! I sent this to myself instead of the list. :-( |--==> "SY" == Steve Youngs writes: SY> The following packages have been updated and put into the SY> "Pre-Releases" directory: Oops, forgot to mention: net-utils-1.16-pkg.tar.gz ========================= 2001-05-12 Steve Youngs * feedmail.el: Sync with version 10. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Fri May 11 11:48:33 2001 Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [203.2.75.229]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA26125 for ; Fri, 11 May 2001 11:48:31 -0400 Received: from slackware.mynet.pc (wdcax13-076.dialup.optusnet.com.au [198.142.220.76]) by mail005.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4BFmSl17432 for ; Sat, 12 May 2001 01:48:28 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4BFl1uj015810; Sat, 12 May 2001 01:47:02 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 10 References: <15098.11302.47725.672028@ulthwe.dyndns.org> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 01:47:01 +1000 In-Reply-To: <15098.11302.47725.672028@ulthwe.dyndns.org> (Peter Brown's message of "Thu, 10 May 2001 15:50:30 +1000") Message-ID: Lines: 24 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "PB" == Peter Brown writes: PB> Steve Youngs writes: >>I've just uploaded the following updated packages to the >>'Pre-Releases' directory: PB> these all installed without a hitch with xemacs-21.5.1 on my RH 7.0 linux box :) That's great. Thanks for letting me know. PB> but i had a problem with installing leim-1.17 PB> was trying to install it (first time i have) and i go this error PB> package leim-1.17-pkg.tar.gz does not match md5 checksum I just installed it here (via xemacs.org), no error. Which site did you get it from? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From andyp@bea.com Fri May 11 12:33:19 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA01263 for ; Fri, 11 May 2001 12:33:19 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA20349; Fri, 11 May 2001 09:33:24 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001329wss.beasys.com [192.168.6.160]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA27899; Fri, 11 May 2001 09:33:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20010511093042.00b1b360@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 May 2001 09:31:10 -0700 To: Petr Konecny , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Core dump on exit in 21.5.1 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This looks like the same problem Andreas is seeing. It would be nive if we could figure it out. andy At 03:52 PM 5/11/01 +0200, Petr Konecny wrote: >Hi, > >I get a coredump on exit in XEmacs 21.5 (beta1) "anise" compiled and >used on Debian/Linux sid box, with 2.4.4-ac5 kernel. Happens only under >X windows. I have not seen anybody reporting this, so I suspect it could >be Debian problem. Any clues ? > > Take care, Petr > >xemacs -q >C-x C-c > >Relevant backtrace: >#0 0x40578ae1 in kill () from /lib/libc.so.6 >#1 0x80c0363 in fatal_error_signal (sig=11) at emacs.c:535 >#2 0x40578a18 in sigaction () from /lib/libc.so.6 >#3 0x402b1078 in XtDisplayOfObject () from /usr/X11R6/lib/libXt.so.6 >#4 0x40139048 in XmImVaSetValues () from /usr/X11R6/lib/libXm.so.2 >#5 0x40136810 in _XmImFreeShellData () from /usr/X11R6/lib/libXm.so.2 >#6 0x4013ef27 in _XmRemoveGrab () from /usr/X11R6/lib/libXm.so.2 >#7 0x402a66a6 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 >#8 0x402a64cd in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 >#9 0x402a69fa in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6 >#10 0x402a6afd in _XtDoPhase2Destroy () from /usr/X11R6/lib/libXt.so.6 >#11 0x402a6c98 in XtDestroyWidget () from /usr/X11R6/lib/libXt.so.6 >#12 0x82077d1 in x_delete_frame (f=0x85da478) at frame-x.c:2682 >#13 0x814fde3 in delete_frame_internal (f=0x85da478, force=1, > called_from_delete_device=1, from_io_error=0) at frame.c:1533 >#14 0x80b1fa5 in delete_device_internal (d=0x85efab0, force=1, > called_from_delete_console=1, from_io_error=0) at device.c:798 >#15 0x80a9f31 in delete_console_internal (con=0x8651710, force=1, > called_from_kill_emacs=1, from_io_error=0) at console.c:689 >#16 0x80c1b17 in Fkill_emacs (arg=137338532) at emacs.c:2850 >#17 0x80c95b7 in Ffuncall (nargs=1, args=0xbffff378) at eval.c:3528 > >configured using `configure --dynamic --with-mule --with-pop >--site-prefixes=/usr/local --with-xfs --without-gpm --debug' > >uname -a: Linux chazelle 2.4.4-ac5 #1 Fri May 4 18:53:42 EDT 2001 i686 unknown > >./configure '--dynamic' '--with-mule' '--with-pop' >'--site-prefixes=/usr/local' '--with-xfs' '--without-gpm' '--debug' > > >XEmacs 21.5-b1 "anise" configured for `i686-pc-linux'. > > >Compilation / Installation: > Source code location: /var/home/pekon/cvssrc/xemacs > Installation prefix: /usr/local > Additional prefixes: /usr/local > Operating system description file: `s/linux.h' > Machine description file: `m/intel386.h' > Compiler: gcc -g -O3 -Wall -Wno-switch > -Winline -Wmissing-prototypes -Wshadow -Wsign-compare > Relocating allocator for buffers: no > GNU version of malloc: yes > - Using Doug Lea's new malloc from the GNU C Library. > >Window System: > Compiling in support for the X window system: > - X Windows headers location: /usr/X11R6/include > - X Windows libraries location: /usr/X11R6/lib > - Handling WM_COMMAND properly. > Using Lucid menubars. > Using Lucid scrollbars. > Using Motif dialog boxes. > Using Motif native widgets. > >TTY: > Compiling in support for ncurses. > >Images: > Compiling in support for GIF images (builtin). > Compiling in support for XPM images. > Compiling in support for PNG images. > Compiling in support for JPEG images. > Compiling in support for TIFF images. > Compiling in support for X-Face message headers. > >Sound: > Compiling in support for sound (native). > Compiling in support for ESD (Enlightened Sound Daemon). > >Databases: > Compiling in support for Berkeley database. > Compiling in support for LDAP. > Compiling in support for PostgreSQL. > - Using PostgreSQL header file: postgresql/libpq-fe.h > - Using PostgreSQL V7 bindings. > >Internationalization: > Compiling in support for Mule (multi-lingual Emacs). > Compiling in support for XIM (X11R5+ I18N input method). > - Using Motif to provide XIM support. > >Mail: > Compiling in support for POP mail retrieval. > Compiling in support for "dot-locking" mail spool file locking method. > >Other Features: > Compiling in support for dynamic shared object modules. > Compiling in support for extra debugging code. > WARNING: --------------------------------------------------------- > WARNING: Compiling in support for runtime error checking. > WARNING: XEmacs will run noticeably more slowly as a result. > WARNING: Error checking is on by default for XEmacs beta releases. > WARNING: --------------------------------------------------------- From andyp@bea.com Fri May 11 12:35:55 2001 Received: from beamail.beasys.com ([63.96.163.38]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA01635 for ; Fri, 11 May 2001 12:35:50 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA20807 for ; Fri, 11 May 2001 09:35:52 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001329wss.beasys.com [192.168.6.160]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA28562 for ; Fri, 11 May 2001 09:35:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20010511093150.00b15740@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 May 2001 09:33:38 -0700 To: xemacs-beta@xemacs.org From: Andy Piper Subject: Random hangs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I just built and updated packages on RH 7.1. I am seeing frequent hangs in the ftp (efs) process. When I look at the ftp buffer its just sitting there trying to download a file. If I hit ^G it starts up again. This latter fact seems to point towards an XEmacs problem rather than slowness in ftp.xemacs.org. Does anyone else see similar behaviour? andy From hines@gderome.com Fri May 11 12:44:50 2001 Received: from gderome.com (ns1.gderome.com [12.3.146.242]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA02879 for ; Fri, 11 May 2001 12:44:49 -0400 Received: from rand.gderome.com (rand.gderome.com [192.168.130.26]) by gderome.com (8.11.2/8.11.2) with ESMTP id f4BGeJr10805 for ; Fri, 11 May 2001 12:40:19 -0400 (EDT) Received: from neo.gderome.com (neo [192.168.130.144]) by rand.gderome.com (8.8.8+Sun/8.8.8) with ESMTP id MAA15920; Fri, 11 May 2001 12:43:36 -0400 (EDT) Received: from neo (neo [192.168.130.144]) by neo.gderome.com (8.8.8+Sun/8.8.8) with ESMTP id MAA22056; Fri, 11 May 2001 12:43:22 -0400 (EDT) From: Charles Hines MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15100.5799.538353.668901@gargle.gargle.HOWL> Date: Fri, 11 May 2001 12:43:19 -0400 To: XEmacs Beta List , Michael Kifer Subject: oddity w/ current ediff package and multiple frames X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Face: 'pn"gAx+&w4-=-}\z>*.Y*@(lC;t1J[a,/Q.Yv0^Wwc6_"H]}}-"?%)ETS`1v[]P`w4,E.9Bgf*XI4 Principal Scientist at ReQuest Technologies Inc (http://www.ReQuestTech.com/) Martial Arts Instructor [Modern Arnis and Balintawak Escrima] "Go back to sleep, Chuck. You're just havin' a nightmare -- of course, we ARE still in Hell." (Gary Larson) From jmincy@muniversal.com Fri May 11 12:57:28 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA04053 for ; Fri, 11 May 2001 12:57:28 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14yGEG-00069j-00 ; Fri, 11 May 2001 12:57:24 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15100.6730.110000.34663@antarres.muniversal.com> Date: Fri, 11 May 2001 12:58:50 -0400 To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Random hangs In-Reply-To: <4.3.2.7.2.20010511093150.00b15740@san-francisco.beasys.com> References: <4.3.2.7.2.20010511093150.00b15740@san-francisco.beasys.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Andy Piper writes: I just built and updated packages on RH 7.1. I am seeing frequent hangs in the ftp (efs) process. When I look at the ftp buffer its just sitting there trying to download a file. If I hit ^G it starts up again. This latter fact seems to point towards an XEmacs problem rather than slowness in ftp.xemacs.org. Does anyone else see similar behaviour? I see something similar running from windows xemacs 21.1.13. Except that ^G gets tries to signal the ftp process, which doesn't work on windows. -jeff From vinnie_shelton@notes.teradyne.com Fri May 11 13:15:14 2001 Received: from showboat.teradyne.com (showboat.teradyne.com [198.51.251.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA05024; Fri, 11 May 2001 13:15:09 -0400 From: vinnie_shelton@notes.teradyne.com Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id NAA22183; Fri, 11 May 2001 13:14:45 -0400 (EDT) Received: from jaypeak.corp.teradyne.com (jaypeak.corp.teradyne.com [131.101.17.23]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id NAA29711; Fri, 11 May 2001 13:14:45 -0400 (EDT) Subject: Re: XEmacs 21.4.2 does not build under cygwin To: "Stephen J. Turnbull" Cc: Alexander Reinwarth , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Date: Fri, 11 May 2001 13:13:30 -0400 Message-ID: X-MIMETrack: Serialize by Router on JayPeak/Teradyne(Release 5.0.4a |July 24, 2000) at 05/11/2001 01:12:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii With this patch, I can build 21.4.2 native under Win NT, but without it, I can not. - vin "Stephen J. Turnbull" @xemacs.org on 05/11/2001 02:42:18 AM Sent by: xemacs-winnt-admin@xemacs.org To: Alexander Reinwarth cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: XEmacs 21.4.2 does not build under cygwin >>>>> "Alexander" == Alexander Reinwarth writes: Alexander> The beta-versions from 21.2-b45 onward, 21.4.0 and Alexander> 21.4.1 as well as 21.5.0 and 21.5.1 built smoothly on Alexander> this machine, nevertheless 21.4.2 does not. This is in part patchup lossage; an incorrect patch to that file was submitted, had to be reverted, and a new one applied. I probably screwed up the application. I've spent a couple of hours installing Cygwin, and I just installed VC++ last week. The first patch following allows me to build native under VC++, but the Cygwin build doesn't run to completion because of a conflict in the sound support. The second patch was submitted by Paul Stodghill and should fix the sound conflict. I'll release 21.4.3 early next week when the Windows team confirms these fixes. Index: src/event-msw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-msw.c,v retrieving revision 1.47.2.1 retrieving revision 1.47 diff -u -r1.47.2.1 -r1.47 --- src/event-msw.c 2001/05/09 09:54:05 1.47.2.1 +++ src/event-msw.c 2001/04/12 18:23:41 1.47 @@ -65,6 +65,7 @@ #include "sysdep.h" #include "objects-msw.h" +#include "events-mod.h" #ifdef HAVE_MSG_SELECT #include "sysfile.h" #include "console-tty.h" Index: configure.in =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v retrieving revision 1.152 diff -u -r1.152 configure.in --- configure.in 2001/05/05 08:26:04 1.152 +++ configure.in 2001/05/10 12:58:32 @@ -4040,6 +4040,14 @@ esac fi + dnl Win32 Native uses native sound + if test -z "$sound_found"; then + if test "$with_msw" = "yes"; then + sound_found=yes + native_sound_lib= + fi + fi + dnl Check for Linux/BSD native sound if test -z "$sound_found"; then for dir in "machine" "sys" "linux"; do @@ -4050,14 +4058,6 @@ [AC_DEFINE_UNQUOTED(SOUNDCARD_H_FILE, "${dir}/soundcard.h")] break) done - fi - - dnl Win32 Native uses native sound - if test -z "$sound_found"; then - if test "$with_msw" = "yes"; then - sound_found=yes - native_sound_lib= - fi fi test "$sound_found" = "yes" && with_native_sound=yes -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From CraigL@Knology.net Fri May 11 23:15:59 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id XAA08126 for ; Fri, 11 May 2001 23:15:59 -0400 Message-Id: <200105120315.XAA08126@gwyn.tux.org> Received: (qmail 30061 invoked from network); 12 May 2001 03:15:58 -0000 Received: from user-24-214-22-213.knology.net (24.214.22.213) by user-24-214-63-14.knology.net with SMTP; 12 May 2001 03:15:58 -0000 Date: Fri, 11 May 2001 23:12:52 -0400 (Eastern Daylight Time) From: Craig Lanning Subject: Re: Random hangs To: Andy Piper cc: xemacs-beta@xemacs.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE In-Reply-To: <4.3.2.7.2.20010511093150.00b15740@san-francisco.beasys.com> References: <4.3.2.7.2.20010511093150.00b15740@san-francisco.beasys.com> X-Mailer: Mahogany, 0.62 'Mars', running under Windows 98 On Fri, 11 May 2001 09:33:38 -0700 Andy Piper wrote: > I just built and updated packages on RH 7.1. I am seeing frequent hangs in > the ftp (efs) process. When I look at the ftp buffer its just sitting there > trying to download a file. If I hit ^G it starts up again. This latter fact > seems to point towards an XEmacs problem rather than slowness in > ftp.xemacs.org. Does anyone else see similar behaviour? > > andy I'm not sure if this is related, but what I'm seeing (on RH 7.1) is long pauses when anything is done that would cause XEmacs to indicate an error to the user. If I try to go up when I'm at the top of the buffer, it pauses, beeps at me, then returns control. I also see a long pause when I am searching (C-s) and I search past the last occurrence. Craig From CraigL@Knology.net Sat May 12 00:30:44 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id AAA11957 for ; Sat, 12 May 2001 00:30:43 -0400 Message-Id: <200105120430.AAA11957@gwyn.tux.org> Received: (qmail 32570 invoked from network); 12 May 2001 04:30:42 -0000 Received: from user-24-214-22-213.knology.net (24.214.22.213) by user-24-214-63-14.knology.net with SMTP; 12 May 2001 04:30:42 -0000 Date: Sat, 12 May 2001 00:27:37 -0400 (Eastern Daylight Time) From: Craig Lanning Subject: 21.5.1: dired.o can't be linked on Win9x To: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org cc: ben@666.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE X-Mailer: Mahogany, 0.62 'Mars', running under Windows 98 [This appears to be caused by a patch that Ben made so I am including him on the cc list.] When I try to do a MinGW build on my Win98 system, I get a runtime error about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" I traced this back to the function user_name_completion in dired.c. The functions NetApiBufferFree and NetUserEnum are not defined on Win9x systems. What is needed from NetUserEnum? Can we get it some other way? Craig From ben@666.com Sat May 12 01:22:24 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id BAA14142 for ; Sat, 12 May 2001 01:22:22 -0400 Received: (qmail 57346 invoked by alias); 12 May 2001 05:22:17 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 57327 invoked by uid 0); 12 May 2001 05:22:17 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 12 May 2001 05:22:17 -0000 Message-ID: <3AFCC8EC.9552E5AE@666.com> Date: Fri, 11 May 2001 22:23:56 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Craig Lanning CC: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: 21.5.1: dired.o can't be linked on Win9x References: <200105120430.VAA00935@proxy3.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Craig Lanning wrote: > > [This appears to be caused by a patch that Ben made so I am including him on > the cc list.] > > When I try to do a MinGW build on my Win98 system, I get a runtime error > about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" > I traced this back to the function user_name_completion in dired.c. > > The functions NetApiBufferFree and NetUserEnum are not defined on Win9x > systems. > > What is needed from NetUserEnum? Can we get it some other way? uh ..... list of current users. i suppose there are none under windows 9x? is there a current username? how do you get it? > > Craig -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From CraigL@Knology.net Sat May 12 01:59:43 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id BAA15938 for ; Sat, 12 May 2001 01:59:42 -0400 Message-Id: <200105120559.BAA15938@gwyn.tux.org> Received: (qmail 2056 invoked from network); 12 May 2001 05:59:42 -0000 Received: from user-24-214-22-213.knology.net (24.214.22.213) by user-24-214-63-14.knology.net with SMTP; 12 May 2001 05:59:42 -0000 Date: Sat, 12 May 2001 01:56:38 -0400 (Eastern Daylight Time) From: Craig Lanning Subject: Re[2]: 21.5.1: dired.o can't be linked on Win9x To: Ben Wing cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE In-Reply-To: <3AFCC8EC.9552E5AE@666.com> References: <200105120430.VAA00935@proxy3.ba.best.com>, <3AFCC8EC.9552E5AE@666.com> X-Mailer: Mahogany, 0.62 'Mars', running under Windows 98 On Fri, 11 May 2001 22:23:56 -0700 Ben Wing wrote: > > > Craig Lanning wrote: > > > > [This appears to be caused by a patch that Ben made so I am including him on > > the cc list.] > > > > When I try to do a MinGW build on my Win98 system, I get a runtime error > > about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" > > I traced this back to the function user_name_completion in dired.c. > > > > The functions NetApiBufferFree and NetUserEnum are not defined on Win9x > > systems. > > > > What is needed from NetUserEnum? Can we get it some other way? > > uh ..... list of current users. i suppose there are none under windows 9x? > > is there a current username? how do you get it? Yes. BOOL GetUserName(LPTSTR,LPDWORD) lib: advapi32 header: winbase.h From steve@turnbull.sk.tsukuba.ac.jp Sat May 12 03:03:04 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA18237 for ; Sat, 12 May 2001 03:03:03 -0400 Received: by localhost id m14yTIU-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Sat, 12 May 2001 15:54:38 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15100.56861.834719.524626@turnbull.sk.tsukuba.ac.jp> Date: Sat, 12 May 2001 15:54:21 +0900 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Bignum support In-Reply-To: References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> So you plan to disallow any bignums smaller or equal to Hrvoje> most-positive-fixnum? That never crossed my mind, Hrvoje> probably due to exposure to Python. I don't think he'd necessarily want to _disallow_ them. I may be wrong, but I seem to remember that Common Lisp assumes that bignums will be automatically canonicalized (but that might just be rationals, complex, quaternions, etc). Anyway, it's an intuitive extension of the canonicalization idea. However, I've been thinking about the annoying CCL interface for a while. There is _zero_ reason why the CCL interface is infix; it could just as easily, with some care, be a restricted Lisp dialect. (It wouldn't just be arithmetic expressions because loop control, I/O, and some complex functions are necessary.) But once you have that, you could do (setq result (declare-arithmetic (let ((i 0) (result 0)) (while (< i bound) (setq result (+ i result)) (setq i (1+ i)))))) Of course when interpreted declare-arithmetic would just eval its argument (you could even have JIT compiling, I suppose), but when compiled you could compile to CCL. The Lisp-CCL compiler could generate two kinds of exceptions, one would be errors for code that isn't legal arithmetic, and the other would simply force the compiler to restart with Emacs Lisp byte-code. In that context, it might be useful for declare-arithmetic to take an argument like :domain 'bignum (arbitrary precision arithmetic) or :domain 'fixnum (error on overflow). The current CCL interpreter neither supports bignums nor (IIRC) does bounds checks, but one can dream, right? Hrvoje> lower the fixnum size without visible penalty. (Why would Hrvoje> we want that? Perhaps to reintroduce small conses.) And BASKIN_ROBBINS_CHAR! Hrvoje> Here it would be nice to have compiler support for that, Hrvoje> so that the compiler can generate fixnum-only opcodes Hrvoje> where it can prove that fixnums are used. But that's not Hrvoje> really possible without lexical scoping, so we can forget Hrvoje> it. Way ahead of me, I see. But you could go the declaration route. Then you would only incur overhead on all-fixnum calculations, and that would be linear in the number of arguments. Presumably that would be worthwhile in many important cases. Hrvoje> With a little cleverness, the all-fixnum case might remain Hrvoje> as fast as it is now. I don't see why would have to be clever, since fixnums aren't lrecords and bignums would have to be. You'd have to decide whether you want marker conversions (eg) or bignum recognition to be faster, but that's it. Hrvoje> OK, you've convinced me. Me too. May I provisionally put "experimental bignum support by Yoshiki Hayashi" in the proposal I'm drafting for the next release? That would mean that you'd like to try to have it ready for a September release. It doesn't mean you promise (I know about the time constraints of first year grad students), you can always withdraw the proposal if you decide it's not feasible. And of course the board would decide whether to accept the proposal, I can't promise it would be in. But it looks very good so far. (N.B. "Experimental" refers to "builder must explicitly configure", not my estimate of quality / stability of the code.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Sat May 12 03:13:56 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA18669 for ; Sat, 12 May 2001 03:13:55 -0400 Received: by localhost id m14yTT2-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Sat, 12 May 2001 16:05:32 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15100.57530.981455.260523@turnbull.sk.tsukuba.ac.jp> Date: Sat, 12 May 2001 16:05:30 +0900 To: Petr Konecny Cc: xemacs-beta@xemacs.org Subject: Re: Core dump on exit in 21.5.1 In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Petr" == Petr Konecny writes: Petr> After reading `configure --help` I added --with-xim=xlib and Petr> it does not dump core anymore. IMHO configure --help is Petr> inconsistent with the behaviour of configure: Yeah, we should fix that. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Sat May 12 03:18:19 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA18842 for ; Sat, 12 May 2001 03:18:18 -0400 Received: by localhost id m14yTXB-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Sat, 12 May 2001 16:09:49 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15100.57775.485170.825212@turnbull.sk.tsukuba.ac.jp> Date: Sat, 12 May 2001 16:09:35 +0900 To: Glynn Clements Cc: Petr Konecny , xemacs-beta@xemacs.org Subject: Re: Core dump on exit in 21.5.1 In-Reply-To: <15100.1017.568779.186182@cerise.nosuchdomain.co.uk> References: <15100.1017.568779.186182@cerise.nosuchdomain.co.uk> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Glynn" == Glynn Clements writes: Glynn> Note that this was a bug in XEmacs, not [Open]Motif. It Glynn> should have been fixed by now, though. Your patch to add a destructor to input-method-motif.c is in 21.4. However, that's Martin's code so I didn't apply to 21.5. I'll do that next week if Martin doesn't, and doesn't object. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From hniksic@arsdigita.com Sat May 12 06:59:59 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA25850 for ; Sat, 12 May 2001 06:59:59 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yX7M-0003K8-00; Sat, 12 May 2001 12:59:24 +0200 Sender: hniksic@florida.arsdigita.de To: "Stephen J. Turnbull" Cc: XEmacs Beta List Subject: Re: Bignum support References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15100.56861.834719.524626@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 12 May 2001 12:59:23 +0200 In-Reply-To: <15100.56861.834719.524626@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Sat, 12 May 2001 15:54:21 +0900") Message-ID: Lines: 62 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> So you plan to disallow any bignums smaller or equal to > Hrvoje> most-positive-fixnum? That never crossed my mind, > Hrvoje> probably due to exposure to Python. > > I don't think he'd necessarily want to _disallow_ them. Internally, why not? The user will never see the difference, and it allows us to retain the simple XINT interface whenever we're dealing with fixnums. > Hrvoje> Here it would be nice to have compiler support for that, > Hrvoje> so that the compiler can generate fixnum-only opcodes > Hrvoje> where it can prove that fixnums are used. But that's not > Hrvoje> really possible without lexical scoping, so we can forget > Hrvoje> it. > > Way ahead of me, I see. But you could go the declaration route. The declarations might work in some cases, but the speed win would be questionable. Declarations win in CL because once you declare A and B as fixnums, the compiler has the license compile (+ A B) into a machine integer addition. XEmacs interpreter is in a very different position, which is not made any easier by the fact that due to dynamic scoping anyone and anything can access the values of the variables and make XEmacs crash. > Hrvoje> With a little cleverness, the all-fixnum case might remain > Hrvoje> as fast as it is now. > > I don't see why would have to be clever Well, maybe it's trivial for you. :-) The cleverness I was referring to would extend the "check that all arguments are numbers logic": for (i = 0; i < nargs; i++) CHECK_NUMBER (arg[i]); into something like: for (i = 0, have_bignums = 0; i < nargs; i++) have_bignums += CHECK_NUMBER_OR_BIGNUM_AND_BY_THE_WAY_IF_ITS_A_BIGNUM_RETURN_ONE (arg[i]); if (!have_bignums) ... do the all-fixnum thing ... > May I provisionally put "experimental bignum support by Yoshiki > Hayashi" in the proposal I'm drafting for the next release? That > would mean that you'd like to try to have it ready for a September > release. It doesn't mean you promise (I know about the time > constraints of first year grad students), you can always withdraw the > proposal if you decide it's not feasible. And of course the board > would decide whether to accept the proposal, I can't promise it would > be in. But it looks very good so far. (N.B. "Experimental" refers to > "builder must explicitly configure", not my estimate of quality / > stability of the code.) I assume the status of "experimentalness" can be revised if the code proves to be stable and reliable? From ben@666.com Sat May 12 07:08:57 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id HAA26104 for ; Sat, 12 May 2001 07:08:56 -0400 Received: (qmail 93045 invoked by alias); 12 May 2001 11:08:53 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 93024 invoked by uid 0); 12 May 2001 11:08:52 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 12 May 2001 11:08:52 -0000 Message-ID: <3AFD1A28.9A6C4205@666.com> Date: Sat, 12 May 2001 04:10:32 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs beta list Subject: find-*-source-path Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit i just added this: * lib-complete.el: * lib-complete.el (find-library-source-path): New. * lib-complete.el (find-library): add a variable to control where `find-library' looks, analogous to `find-function-source-path'. should i instead call it something like `find-file-source-path' and modify find-function to use the same? or just use find-function-source-path? or other? -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Sat May 12 07:09:50 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id HAA26136 for ; Sat, 12 May 2001 07:09:50 -0400 Received: (qmail 93876 invoked by alias); 12 May 2001 11:09:49 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 93867 invoked by uid 0); 12 May 2001 11:09:49 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 12 May 2001 11:09:49 -0000 Message-ID: <3AFD1A61.D93D2912@666.com> Date: Sat, 12 May 2001 04:11:29 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: XEmacs Beta List Subject: Re: [BUG] Font-lock refuses to turn on in some buffers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit there's no need for this "help" any more, since i implemented deferred font locking. i'm about to take it out. Hrvoje Niksic wrote: > > XEmacs font-lock has a "feature" where it refuses to start in buffers > whose name begins with SPC. The idea begind the feature is to prevent > accidental fontification of various temporary buffers. > > As accidental fontification goes, the argument stands. But I consider > it really evil that it refuses to work even when turned on > *explicitly*, and the same even when its own code turns it on. > > Here is a weird bug I've been seeing: Gnus tries to fontify part of > the buffer by effectively doing the following: > > (insert (with-temp-buffer > (funcall desired-major-mode) > (font-lock-fontify-buffer) > ... some code that forces all text-prop extents to be > duplicable ... > (buffer-string))) > > This works, but leaves everything except strings and comments > unfontified. This bug had me baffled for a long time, because all my > attempts to repeat it in "laboratory conditions" failed. Finally I > tracked down the problem to this: > > font-lock-fontify-buffer temporarily sets font-lock-mode because some > of its magic depends on font-lock-mode being on. But since the buffer > name begins with SPC, font-lock-mode silently (which is evil!) refuses > to turn itself on, and fontification fails in a random way. > > I think the optimization should be changed to only affect turning on > font-lock with font-lock-auto-fontify and friends. If somebody > explicitly turns on font-lock, either through > `font-lock-fontify-buffer' or otherwise, it has to just work, > regardless of what the buffer happens to be named! > > If that is for whatever reason undesirable, we should at least > implement a `force' argument for font-lock-mode which you can call and > be sure that font-lock will be used. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From hniksic@arsdigita.com Sat May 12 07:11:45 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA26222 for ; Sat, 12 May 2001 07:11:44 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yXIm-0003Mv-00; Sat, 12 May 2001 13:11:12 +0200 Sender: hniksic@florida.arsdigita.de To: Ben Wing Cc: XEmacs Beta List Subject: Re: [BUG] Font-lock refuses to turn on in some buffers References: <3AFD1A61.D93D2912@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 12 May 2001 13:11:12 +0200 In-Reply-To: <3AFD1A61.D93D2912@666.com> (Ben Wing's message of "Sat, 12 May 2001 04:11:29 -0700") Message-ID: Lines: 6 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > there's no need for this "help" any more, since i implemented > deferred font locking. i'm about to take it out. Perfect. Thanks. From ben@666.com Sat May 12 08:34:18 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id IAA28866 for ; Sat, 12 May 2001 08:34:18 -0400 Received: (qmail 67872 invoked by alias); 12 May 2001 12:34:17 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 67859 invoked by uid 0); 12 May 2001 12:34:17 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 12 May 2001 12:34:17 -0000 Message-ID: <3AFD2E2D.ADB5D55F@666.com> Date: Sat, 12 May 2001 05:35:57 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Craig Lanning CC: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: 21.5.1: dired.o can't be linked on Win9x References: <200105120430.VAA00935@proxy3.ba.best.com>, <3AFCC8EC.9552E5AE@666.com> <200105120559.BAA15937@gwyn.tux.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit i just sent a patch to fix the link problems. i'll send another tomorrow that implements GetUserName. Craig Lanning wrote: > > On Fri, 11 May 2001 22:23:56 -0700 Ben Wing wrote: > > > > > > > Craig Lanning wrote: > > > > > > [This appears to be caused by a patch that Ben made so I am including him on > > > the cc list.] > > > > > > When I try to do a MinGW build on my Win98 system, I get a runtime error > > > about being "linked to missing export NETAPI32.DLL:NetApiBufferFree" > > > I traced this back to the function user_name_completion in dired.c. > > > > > > The functions NetApiBufferFree and NetUserEnum are not defined on Win9x > > > systems. > > > > > > What is needed from NetUserEnum? Can we get it some other way? > > > > uh ..... list of current users. i suppose there are none under windows 9x? > > > > is there a current username? how do you get it? > > Yes. > BOOL GetUserName(LPTSTR,LPDWORD) > lib: advapi32 > header: winbase.h -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From Adrian.Aichner@t-online.de Sat May 12 09:26:51 2001 Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA30728 for ; Sat, 12 May 2001 09:26:51 -0400 Received: from fwd07.sul.t-online.de by mailout00.sul.t-online.com with smtp id 14yZQB-0005ib-04; Sat, 12 May 2001 15:26:59 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.68]) by fwd07.sul.t-online.com with esmtp id 14yZQC-14ez4qC; Sat, 12 May 2001 15:27:00 +0200 To: XEmacs Beta List Subject: Change of algorithm to write (custom-set-* ...) in 21.5-b1? X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net Hi All, I just noticed in 21.5-b1 that saving a changed variable from a *Custom...* buffer via the Save button. performs major re-ordering of the (custom-set-* ...) sections. This has not happended in 21.1 and 21.4.2 and is a major pain for people like me who regularily ediff their .emacs file for recent changes. Is this a known problem/feature? Best regards, Adrian -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From Adrian.Aichner@t-online.de Sat May 12 11:34:24 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA03287 for ; Sat, 12 May 2001 11:34:22 -0400 Received: from fwd07.sul.t-online.de by mailout02.sul.t-online.com with smtp id 14ybPl-0008Pq-01; Sat, 12 May 2001 17:34:41 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.68]) by fwd07.sul.t-online.com with esmtp id 14ybPU-2FNs0mC; Sat, 12 May 2001 17:34:24 +0200 To: Ben Wing Cc: Adrian Aichner , XEmacs Beta List Subject: Re: mouse-track-insert bug (windows native) now also in 21.4.1, 21.5-b0 References: <3AEFD8B6.419E1406@666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 72 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Ben" == Ben Wing writes: Ben> Adrian Aichner wrote: >> >> See the thread starting at >> http://list-archive.xemacs.org/xemacs-beta/200006/msg00136.html >> >> I was looking forward to 21.4 for a long time because this problem was >> fixed there. Ben> are you sure? Yes. I just verified this got broken again on native Windows between 21.2.40 and 21.2.47. It never worked on native Windows in 21.1. It has been confirmed to work there under X. Can you think of any likely suspects? I'll try to investigate a bit with cvs diff. Best regards, Adrian >> >> Now, alas, the problem is also in 21.4.1 and 21.5-b0. >> >> Can we try to fix this now? >> >> I will need some help with this. >> >> Ben, one suspect is this: >> >> > From: Ben Wing >> > Subject: [PATCH] misc changes, some for 21.4 >> > To: xemacs-patches@xemacs.org >> > Date: Sat, 28 Apr 2001 03:50:28 -0400 >> > Message-Id: <200104280750.DAA29568@gwyn.tux.org> >> >> I'm running out of time for today. >> >> Perhaps you can have a look at this. I sure miss C-double-click >> between buffers! >> >> C-button1 at that spot runs the command mouse-track-insert >> >> Best regards, >> >> Adrian >> >> -- >> Adrian Aichner >> mailto:adrian@xemacs.org >> http://www.xemacs.org/ Ben> -- Ben> ben Ben> I'm sometimes slow in getting around to reading my mail, so if you Ben> want to reach me faster, call 520-661-6661. Ben> See http://www.666.com/ben/chronic-pain/ for the hell I've been Ben> through. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From Adrian.Aichner@t-online.de Sat May 12 13:32:40 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA07539 for ; Sat, 12 May 2001 13:32:39 -0400 Received: from fwd07.sul.t-online.de by mailout02.sul.t-online.com with smtp id 14ydGE-0005lK-06; Sat, 12 May 2001 19:32:58 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.68]) by fwd07.sul.t-online.com with esmtp id 14ydG3-11PQECC; Sat, 12 May 2001 19:32:47 +0200 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Ben Wing , XEmacs Beta List Subject: Re: mouse-track-insert bug (windows native) now also in 21.4.1, 21.5-b0 References: <3AEFD8B6.419E1406@666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 107 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "APA" == Adrian Aichner writes: >>>>> "Ben" == Ben Wing writes: Ben> Adrian Aichner wrote: >>> >>> See the thread starting at >>> http://list-archive.xemacs.org/xemacs-beta/200006/msg00136.html >>> >>> I was looking forward to 21.4 for a long time because this problem was >>> fixed there. Ben> are you sure? APA> Yes. I just verified this got broken again on native Windows APA> between 21.2.40 and 21.2.47. This analysis was wrong. mouse-track-insert between buffers DOES work in 21.2-b40, 21.5-b1, and even 21.1.14 until one performs C-x C-b (list-buffers) Try this: 1. Start XEmacs 2. C-x 2 (split-window-vertically) 3. C-x b (switch-to-buffer) tmp RET 4. Depress Control key in tmp buffer, move mouse into *scratch* buffer and double click a word there. This works fine. Word will be inserted in tmp buffer. Great! Now do C-x C-b (list-buffers) and mouse-track-insert now longer works! Instead it will activate a region on the double-clicked work and display set mark in the echo area. Any clues anybody? Adrian APA> It never worked on native Windows in 21.1. It has been APA> confirmed to work there under X. APA> Can you think of any likely suspects? APA> I'll try to investigate a bit with cvs diff. APA> Best regards, APA> Adrian >>> >>> Now, alas, the problem is also in 21.4.1 and 21.5-b0. >>> >>> Can we try to fix this now? >>> >>> I will need some help with this. >>> >>> Ben, one suspect is this: >>> >>> > From: Ben Wing >>> > Subject: [PATCH] misc changes, some for 21.4 >>> > To: xemacs-patches@xemacs.org >>> > Date: Sat, 28 Apr 2001 03:50:28 -0400 >>> > Message-Id: <200104280750.DAA29568@gwyn.tux.org> >>> >>> I'm running out of time for today. >>> >>> Perhaps you can have a look at this. I sure miss C-double-click >>> between buffers! >>> >>> C-button1 at that spot runs the command mouse-track-insert >>> >>> Best regards, >>> >>> Adrian >>> >>> -- >>> Adrian Aichner >>> mailto:adrian@xemacs.org >>> http://www.xemacs.org/ Ben> -- Ben> ben Ben> I'm sometimes slow in getting around to reading my mail, so if you Ben> want to reach me faster, call 520-661-6661. Ben> See http://www.666.com/ben/chronic-pain/ for the hell I've been Ben> through. APA> -- APA> Adrian Aichner APA> mailto:adrian@xemacs.org APA> http://www.xemacs.org/ -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From gshapiro@gshapiro.net Sat May 12 13:40:49 2001 Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA07793 for ; Sat, 12 May 2001 13:40:48 -0400 Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.4.Beta0/8.11.4.Beta0) id f4CHehv99099; Sat, 12 May 2001 10:40:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15101.30107.553926.33388@horsey.gshapiro.net> Date: Sat, 12 May 2001 10:40:43 -0700 From: Gregory Neil Shapiro To: xemacs-beta@xemacs.org Subject: 21.5.1: etags: buffer-tag-table-list endless loop X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid In XEmacs 21.5 (beta1) "anise" [Lucid] (i386-unknown-freebsd4.3) of Fri May 11 2001 on horsey.gshapiro.net configured using `configure --site-prefixes=/usr/local --with-database=berkdb --with-pop' After upgrading to 21.5.1 (from 21.5.0), find-tags stopped working. I tracked it down to buffer-tag-table-list and change 1.12 to that file. Specifically this: @@ -185,10 +190,13 @@ ;; Current directory (when (file-readable-p (concat default-directory "TAGS")) (push (concat default-directory "TAGS") result)) - ;; Parent directory - (let ((parent-tag-file (expand-file-name "../TAGS" default-directory))) - (when (file-readable-p parent-tag-file) - (push parent-tag-file result))) + ;; Parent directories + (when tags-check-parent-directories-for-tag-files + (let ((cur default-directory)) + (while (file-exists-p (setq cur (expand-file-name ".." cur))) + (let ((parent-tag-file (expand-file-name "TAGS" cur))) + (when (file-readable-p parent-tag-file) + (push parent-tag-file result)))))) ;; tag-table-alist (let* ((key (or buffer-file-name (concat default-directory (buffer-name)))) This change has a bug in that it will never get out of the while loop. Using the debugger, it would check each directory going up the tree but wouldn't stop at the root. This led to: /usr/local/src/../TAGS /usr/local/../TAGS /usr/../TAGS /../TAGS /../../TAGS /../../../TAGS ... There is always a ".." for the root directory and nothing in the code ever breaks out of the while. That is probably why the old code checked for "../TAGS" instead of setting directory to ".." and checking for the TAGS file. From jmincy@muniversal.com Sat May 12 14:46:10 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA10359 for ; Sat, 12 May 2001 14:45:56 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14yeOp-0001zk-00 ; Sat, 12 May 2001 14:45:55 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15101.33937.70000.502003@antarres.muniversal.com> Date: Sat, 12 May 2001 14:44:33 -0400 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Ben Wing , XEmacs Beta List Subject: Re: mouse-track-insert bug (windows native) now also in 21.4.1, 21.5-b0 In-Reply-To: References: <3AEFD8B6.419E1406@666.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Adrian Aichner writes: This analysis was wrong. mouse-track-insert between buffers DOES work in 21.2-b40, 21.5-b1, and even 21.1.14 until one performs I just verified the same results in 21.1.13 windows. Now do C-x C-b (list-buffers) and mouse-track-insert now longer works! Instead it will activate a region on the double-clicked work and display set mark in the echo area. Electric-buffer-list has the same effect as list-buffers. The funny thing thing is that I never realized that mouse-track-insert was supposed to work with clicking. (I guess that is what the obviously named mouse-track-click-hook is supposed to do). Long ago, I patched my version of mouse-track-insert to extract out the region clicked on by backward-sexp through forward-sexp. -jeff (defun mouse-track-insert (event &optional delete) "Make a selection with the mouse and insert it at point...." (interactive "*e") (setq mouse-track-insert-selected-region nil) (let ((mouse-track-drag-up-hook 'mouse-track-insert-drag-up-hook) (mouse-track-click-hook 'mouse-track-insert-click-hook) s) (save-excursion ....) ;; >>> added this. JWM <<< (if (or (null s) (equal s "")) (save-excursion (save-window-excursion (mouse-set-point event) (setq s (buffer-substring (progn (backward-sexp) (point)) (progn (forward-sexp) (point))))))) ;; <<< >>> (or (null s) (equal s "") (insert s)))) From $}xinix{$@esperi.demon.co.uk Sat May 12 19:10:24 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA20587 for ; Sat, 12 May 2001 19:10:23 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id AAA21011 for ; Sun, 13 May 2001 00:02:28 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id AAA28440; Sun, 13 May 2001 00:02:26 +0100 Sender: nix@esperi.demon.co.uk Newsgroups: comp.emacs.xemacs Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> From: Nix <$}xinix{$@esperi.demon.co.uk> X-Emacs: if SIGINT doesn't work, try a tranquilizer. Date: 13 May 2001 00:02:26 +0100 Message-ID: <87ofsy5fy5.fsf@loki.wkstn.nix> Organization: the Core Lines: 53 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) In-Reply-To: <87y9s38t3y.fsf@loki.wkstn.nix> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Posted-To: comp.emacs.xemacs The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. [Cc:ed to xemacs-beta. I am not subscribed to this list; please Cc me on any replies. If this is an obvious MULE-like thing that people have been coping with for ages, please forgive me; I've never built anything MULEish into my Emacsen before.] On 11 May 2001, Nix stipulated: > > I've gone from 21.1.14 to 21.4.2 on my i586-pc-linux-gnu box, and all of > a sudden term-mode is misbehaving, viz a directory listing now looks > like this: > > nix@loki 142 % ls -l > total 51 > -rwxr-xr-x 1 compiler emacsers 1389 Aug 16 2000 eicq-user-install.sh [snip classic typewriter `staggering'] Diagnosed. I built with --with-file-coding on a Unix platform, so XEmacs is looking at the data coming to the file and transparently translating CR/LF to LF. All very well, except that in term mode, CR/LF's come in and are interpreted by `term-emulate-terminal' in a DOSsish fashion, with CR and LF serving their ancient teletype purposes; as this is how TTYs work, this is entirely correct. What is *not* correct is XEmacs picking up on the CR/LFs and translating them to LFs! I'd fix term-mode, if it wasn't that setting the `buffer-file-coding-system' to `no-conversion' still gives the stair-stepping effect, and that even before that it's `raw-text', so XEmacs shouldn't be touching the bytestream from the process at all. (It's questionable whether `--with-file-coding' should touch process streams in any case; it'll be built in for people trying to transfer files between DOSsish and Unixish environments, not processes!) So this looks like an XEmacs bug; however, I don't have a clue how to go about fixing it; as I said above, I'm a neophyte at *using* MULE, let alone debugging it. (Reproduction of the bug is easy, as near as I can tell; build --with-file-coding on a Unix box and run term-mode or anything based on it, like tshell. Bingo.) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From hniksic@arsdigita.com Sat May 12 19:43:40 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA21565 for ; Sat, 12 May 2001 19:43:39 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yj1m-0006HG-00; Sun, 13 May 2001 01:42:26 +0200 Sender: hniksic@florida.arsdigita.de To: Nix <$}xinix{$@esperi.demon.co.uk> Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 13 May 2001 01:42:26 +0200 In-Reply-To: <87ofsy5fy5.fsf@loki.wkstn.nix> (Nix's message of "13 May 2001 00:02:26 +0100") Message-ID: Lines: 27 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nix <$}xinix{$@esperi.demon.co.uk> writes: > All very well, except that in term mode, CR/LF's come in and are > interpreted by `term-emulate-terminal' in a DOSsish fashion, with CR and > LF serving their ancient teletype purposes; as this is how TTYs work, > this is entirely correct. > > What is *not* correct is XEmacs picking up on the CR/LFs and translating > them to LFs! Thanks for the analysis. I've successfully repeated the bug in my Mule-enabled XEmacs, and I see the same problem. A quick fix that worked for me is to evaluate this from another (whichever) buffer: (with-current-buffer (get-buffer "*terminal*") (set-buffer-process-coding-system 'binary 'binary)) This sets the "process coding system" in the "*Terminal*" buffer to `binary', which means "no conversion whatsoever, thankyouverymuch". > I'd fix term-mode, if it wasn't that setting the > `buffer-file-coding-system' to `no-conversion' That's because `no-conversion' actually means "no charset conversion". Line endings still get converted. (Yes, it's confusing. It will probably be changed in one of the future releases.) From nix@esperi.demon.co.uk Sat May 12 20:30:17 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA23305 for ; Sat, 12 May 2001 20:30:15 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id BAA21288; Sun, 13 May 2001 01:24:58 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id BAA30602; Sun, 13 May 2001 01:24:56 +0100 Sender: nix@esperi.demon.co.uk To: Hrvoje Niksic Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> X-Emacs: don't try this at home, kids! From: Nix Date: 13 May 2001 01:24:55 +0100 In-Reply-To: Message-ID: <87y9s23xk8.fsf@loki.wkstn.nix> Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On 13 May 2001, Hrvoje Niksic gibbered: > Nix <$}xinix{$@esperi.demon.co.uk> writes: > >> What is *not* correct is XEmacs picking up on the CR/LFs and translating >> them to LFs! > > Thanks for the analysis. I've successfully repeated the bug in my > Mule-enabled XEmacs, and I see the same problem. Good, it's not my bizarre roll-yer-own Linux install that's breaking it then. (That's rare. ;) ) > (set-buffer-process-coding-system 'binary 'binary)) Great, that's gone into the term-exec-hook in the site-start here, and my users are happy (and impressed by the speed of the response :) ) >> I'd fix term-mode, if it wasn't that setting the >> `buffer-file-coding-system' to `no-conversion' > > That's because `no-conversion' actually means "no charset > conversion". Line endings still get converted. (Yes, it's Ah. > confusing. It will probably be changed in one of the future > releases.) I dunno, it makes a kind of sense; the line ending conversion is in a different dimension to the charset conversion (LF / CRLF / CR, versus ISO-foo / KOI8-R / US-ASCII / who-knows-what)... -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From hniksic@arsdigita.com Sat May 12 20:36:50 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA23631 for ; Sat, 12 May 2001 20:36:50 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yjsO-0006SK-00; Sun, 13 May 2001 02:36:48 +0200 Sender: hniksic@florida.arsdigita.de To: Nix Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> <87y9s23xk8.fsf@loki.wkstn.nix> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 13 May 2001 02:36:48 +0200 In-Reply-To: <87y9s23xk8.fsf@loki.wkstn.nix> (Nix's message of "13 May 2001 01:24:55 +0100") Message-ID: Lines: 28 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nix writes: > > confusing. It will probably be changed in one of the future > > releases.) > > I dunno, it makes a kind of sense; Not to most people. People generally expect "no-conversion" to mean exactly that -- no conversion. Additionally, in FSF Emacs, "no-conversion" means what XEmacs calls "binary". > the line ending conversion is in a different dimension to the > charset conversion (LF / CRLF / CR, versus ISO-foo / KOI8-R / > US-ASCII / who-knows-what)... Good point. In general, one should be able to stack "coding systems", e.g. a "gzip" coding system piped into a "NL detection coding system" piped into a "charset detection coding system" (for people who need that). However, this is currently not possible. Because of that, line endings are implemented as a horrible kludge -- for each coding system foo, you have a foo-dos, foo-unix, and foo-mac version. This splendid design was inherited from the original Mule, not conceived by the XEmacs people. From rick@firewall.germs.org Sat May 12 23:30:12 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA31700 for ; Sat, 12 May 2001 23:30:12 -0400 Received: from r7a002382as.hlb.cable.rcn.com ([209.122.138.175] helo=firewall.germs.org) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14ymS4-0003Ik-00 for xemacs-beta@xemacs.org; Sat, 12 May 2001 23:21:52 -0400 Received: from firewall.germs.org (rick@localhost [127.0.0.1]) by firewall.germs.org (8.9.3/8.9.3) with ESMTP id WAA15466 for ; Sat, 12 May 2001 22:59:18 -0400 Message-Id: <200105130259.WAA15466@firewall.germs.org> Reply-To: Rick Campbell X-Face: #<@""pDMxa>Mr$Wp[^l7e1RwB6]&7pRp,f=|)6y5?t45X$y(xx.x^?k~;-d>s:SL86Qt82U 'M!RC3LrDvD/LjiYdGO!:\/\qx?YabgGC9%xw5%0-W05LRvyu9vB9TYk%5PN|C*0WgrXD-L0'g3j;h X-Windows: Some voids are better left unfilled. Organization: Campbell Central From: Rick Campbell To: xemacs-beta@xemacs.org Subject: Can't view images?!? Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Sat, 12 May 2001 22:59:17 -0400 Sender: rick@firewall.germs.org Content-Type: multipart/mixed; boundary="Multipart_Sat_May_12_22:59:02_2001-1" Content-Transfer-Encoding: 7bit --Multipart_Sat_May_12_22:59:02_2001-1 Content-Type: text/plain; charset=US-ASCII I just finished building 21.4.2 on my home machine (Slackware 7.0). Despite every indication that it should be supporting images, the only real image support that I've seen is X-Face stuff via mh-e. Visiting an image file and using image-toggle-decoding never does anything close to showing an image. I've also built 21.4.1 on freshly installed Slackware 7.1 and SuSE 7.1 systems with identical results results on Slackware 7.1 and even worse on SuSE. In both cases, building and installing XEmacs was literally the first thing that I did after installing the OS. On SuSE 7.1 (Personal) I installed everything and the 21.4.1 ./configure won't even complete. Anyway, I've been using 21.1 (patch 12) "Channel Islands" at home and it can view images just fine. It's also a home built -- I hardly ever use pre-built binaries. Anyway, does anyone have any suggestions as to how to see images in an Emacs buffer with the latest releases? Rick --Multipart_Sat_May_12_22:59:02_2001-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="xemacs-21.4.2-build.log" Content-Transfer-Encoding: 7bit ~/archives/xemacs-21.4.2 $ ./configure --prefix=/usr/misc/packages/xemacs/21.4.2 checking whether ln -s works... yes checking host system type... i586-pc-linux checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking for GNU libc... yes Extracting information from the machine- and system-dependent headers... checking for buggy gcc versions... no checking for dynodump... no checking for malloc_set_state... yes checking whether __after_morecore_hook exists... yes checking for ranlib... ranlib checking for a BSD compatible install... /usr/bin/ginstall -c checking for bison... bison -y checking for a.out.h... yes checking for elf.h... yes checking for cygwin/version.h... no checking for fcntl.h... yes checking for inttypes.h... yes checking for libgen.h... yes checking for locale.h... yes checking for mach/mach.h... no checking for sys/param.h... yes checking for sys/pstat.h... no checking for sys/time.h... yes checking for sys/timeb.h... yes checking for sys/un.h... yes checking for ulimit.h... yes checking for unistd.h... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for ANSI C header files... yes checking whether time.h and sys/time.h may both be included... yes checking for sys_siglist declaration in signal.h or unistd.h... yes checking for utime... yes checking return type of signal handlers... void checking for size_t... yes checking for pid_t... yes checking for uid_t in sys/types.h... yes checking for mode_t... yes checking for off_t... yes checking for ssize_t... yes checking for socklen_t... yes checking for struct timeval... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for working const... yes checking whether make sets ${MAKE}... yes checking whether byte ordering is bigendian... no checking size of short... 2 checking size of int... 4 checking size of long... 4 checking size of long long... 8 checking size of void *... 4 checking for long file names... yes checking for sin... no checking for sin in -lm... yes checking type of mail spool file locking checking for lockf... yes checking for flock... yes checking whether the -xildoff compiler flag is required... no checking for specified window system checking for X... libraries /usr/X11/lib, headers /usr/X11/include checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for X defines extracted by xmkmf checking for X11/Intrinsic.h... yes checking for XOpenDisplay in -lX11... yes checking for XShapeSelectInput in -lXext... yes checking for XtOpenDisplay in -lXt... yes checking the version of X11 being used... R6 checking for XConvertCase... yes checking for X11/Xlocale.h... yes checking for XRegisterIMInstantiateCallback... yes checking for standard XRegisterIMInstantiateCallback prototype... no checking for XmuReadBitmapDataFromFile in -lXmu... yes checking for main in -lXbsd... no checking for MS-Windows checking for main in -lgdi32... no checking for X11/extensions/shape.h... yes Using X11. checking for WM_COMMAND option checking for X11/Xauth.h... yes checking for XauGetAuthByAddr in -lXau... yes checking for tt_c.h... no checking for Tt/tt_c.h... no checking for desktop/tt_c.h... no checking for Dt/Dt.h... no configure: warning: No CDE without generic Drag'n'Drop support configure: warning: No OffiX without generic Drag'n'Drop support checking for LDAP checking for ldap.h... no checking for PostgreSQL checking for libpq-fe.h... no checking for pgsql/libpq-fe.h... no checking for postgresql/libpq-fe.h... no checking for graphics libraries checking for Xpm - no older than 3.4f... yes checking for "FOR_MSW" xpm... no checking for compface.h... yes checking for UnGenFace in -lcompface... yes checking for inflate in -lc... no checking for inflate in -lz... yes checking for jpeglib.h... yes checking for jpeg_destroy_decompress in -ljpeg... yes checking for pow... yes checking for png.h... yes checking for png_read_image in -lpng... yes checking for workable png version information... yes checking for tiffio.h... yes checking for TIFFClientOpen in -ltiff... yes checking for X11 graphics libraries checking for the Athena widgets checking for XawScrollbarSetThumb in -lXaw... yes checking for threeDClassRec in -lXaw... no checking for X11/Xaw/ThreeD.h... no checking for X11/Xaw/XawInit.h... yes checking for Xm/Xm.h... yes checking for XmStringFree in -lXm... yes checking for Lesstif... yes checking for layout_object_getvalue in -li18n... no checking for cbrt... yes checking for closedir... yes checking for dup2... yes checking for eaccess... no checking for fmod... yes checking for fpathconf... yes checking for frexp... yes checking for ftime... yes checking for getaddrinfo... yes checking for gethostname... yes checking for getnameinfo... yes checking for getpagesize... yes checking for gettimeofday... yes checking for getcwd... yes checking for getwd... yes checking for logb... yes checking for lrand48... yes checking for matherr... yes checking for mkdir... yes checking for mktime... yes checking for perror... yes checking for poll... yes checking for random... yes checking for rename... yes checking for res_init... yes checking for rint... yes checking for rmdir... yes checking for select... yes checking for setitimer... yes checking for setpgid... yes checking for setlocale... yes checking for setsid... yes checking for sigblock... yes checking for sighold... yes checking for sigprocmask... yes checking for snprintf... yes checking for stpcpy... yes checking for strerror... yes checking for tzset... yes checking for ulimit... yes checking for usleep... yes checking for waitpid... yes checking for vsnprintf... yes checking for fsync... yes checking for ftruncate... yes checking for umask... yes checking for getpt... yes checking for _getpty... no checking for grantpt... yes checking for unlockpt... yes checking for ptsname... yes checking for killpg... yes checking for tcgetpgrp... yes checking for openpty... no checking for openpty in -lutil... yes checking for pty.h... yes checking for stropts.h... yes checking for isastream... yes checking for strtio.h... no checking for getloadavg... yes checking for sys/loadavg.h... no checking whether netdb declares h_errno... yes checking for sigsetjmp... yes checking whether localtime caches TZ... no checking whether gettimeofday accepts one or two arguments... two checking for inline... inline checking for working alloca.h... yes checking for alloca... yes checking for vfork.h... no checking for working vfork... yes checking for working strcoll... yes checking for getpgrp... yes checking whether getpgrp takes no argument... yes checking for working mmap... yes checking for M_MMAP_THRESHOLD... yes checking for termios.h... yes checking for socket... yes checking for netinet/in.h... yes checking for arpa/inet.h... yes checking for sun_len member in struct sockaddr_un... no checking for ip_mreq struct in netinet/in.h... yes checking for msgget... yes checking for sys/ipc.h... yes checking for sys/msg.h... yes checking for dirent.h... yes checking for nlist.h... no checking for sound support checking for machine/soundcard.h... no checking for sys/soundcard.h... yes checking for audio/audiolib.h... no checking for esd-config... yes checking for esd_play_stream... yes checking for TTY-related features checking for tgetent in -lncurses... yes checking for ncurses/curses.h... yes checking for ncurses/term.h... yes checking for gpm.h... yes checking for Gpm_Open in -lgpm... yes checking for database support checking for ndbm.h... no checking for Berkeley db.h... db.h checking for Berkeley DB version... 2 checking for db_open... no checking for db_open in -ldb... yes checking for module support checking for dlfcn.h... yes checking for dlopen in -lc... checking for dlopen in -ldl... checking how to build dynamic libraries for i586-pc-linux checking how to produce PIC code... -fPIC checking if PIC flag -fPIC really works... yes checking if C compiler can produce shared libraries... yes checking for ld used by GCC... /usr/i386-slackware-linux/bin/ld checking if the linker is GNU ld... yes checking for dlerror... yes checking for _dlerror... no XEmacs 21.4.2 "Developer-Friendly Unix APIs" configured for `i586-pc-linux'. Compilation / Installation: Source code location: /home/rick/archives/xemacs-21.4.2 Installation prefix: /usr/misc/packages/xemacs/21.4.2 Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11/include - X Windows libraries location: /usr/X11/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. creating ./config.status creating Makefile.in creating lib-src/Makefile.in creating lwlib/Makefile.in creating src/Makefile.in creating src/paths.h creating lib-src/config.values creating lib-src/ellcc.h creating src/config.h creating lwlib/config.h creating ./Makefile creating ./GNUmakefile creating lib-src/Makefile creating lib-src/GNUmakefile creating lwlib/Makefile creating lwlib/GNUmakefile creating src/Makefile creating src/GNUmakefile ~/archives/xemacs-21.4.2 $ make Producing `src/Emacs.ad.h' from `etc/Emacs.ad'. Resetting `src/sheap-adjust.h'. cd ./lib-src && make all make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/lib-src' gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H -I/usr/X11/include /home/rick/archives/xemacs-21.4.2/lib-src/gnuslib.c /home/rick/archives/xemacs-21.4.2/lib-src/gnuslib.c: In function `connect_to_internet_server': /home/rick/archives/xemacs-21.4.2/lib-src/gnuslib.c:330: warning: comparison between signed and unsigned gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H -I/usr/X11/include /home/rick/archives/xemacs-21.4.2/lib-src/gnuclient.c gnuslib.o -L/usr/X11/lib -lXau -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o gnuclient gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/ellcc.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o ellcc gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/getopt.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/getopt1.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H \ -DINHIBIT_STRING_HEADER /home/rick/archives/xemacs-21.4.2/src/regex.c gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H -DVERSION='"21.4.2"' /home/rick/archives/xemacs-21.4.2/lib-src/etags.c getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o etags /home/rick/archives/xemacs-21.4.2/lib-src/etags.c: In function `C_entries': /home/rick/archives/xemacs-21.4.2/lib-src/etags.c:2777: warning: `typdefcblev' might be used uninitialized in this function gcc -DCTAGS -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H -DVERSION='"21.4.2"' /home/rick/archives/xemacs-21.4.2/lib-src/etags.c getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o ctags /home/rick/archives/xemacs-21.4.2/lib-src/etags.c: In function `C_entries': /home/rick/archives/xemacs-21.4.2/lib-src/etags.c:2777: warning: `typdefcblev' might be used uninitialized in this function gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/b2m.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o b2m gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H -DVERSION='"21.4.2"' /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o ootags /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c: In function `main': /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c:893: warning: `opt' might be used uninitialized in this function /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c: In function `prolog_pred': /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c:4415: warning: comparison between signed and unsigned /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c: In function `erlang_func': /home/rick/archives/xemacs-21.4.2/lib-src/ootags.c:4569: warning: comparison between signed and unsigned gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H -I/usr/X11/include /home/rick/archives/xemacs-21.4.2/lib-src/gnuserv.c gnuslib.o -L/usr/X11/lib -lXau -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o gnuserv /home/rick/archives/xemacs-21.4.2/lib-src/gnuserv.c: In function `permitted': /home/rick/archives/xemacs-21.4.2/lib-src/gnuserv.c:493: warning: comparison between signed and unsigned /home/rick/archives/xemacs-21.4.2/lib-src/gnuserv.c: In function `setup_table': /home/rick/archives/xemacs-21.4.2/lib-src/gnuserv.c:607: warning: comparison between signed and unsigned /home/rick/archives/xemacs-21.4.2/lib-src/gnuserv.c:633: warning: comparison between signed and unsigned gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/fakemail.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o fakemail gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/wakeup.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o wakeup gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/profile.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o profile gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/make-docfile.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o make-docfile /home/rick/archives/xemacs-21.4.2/lib-src/make-docfile.c: In function `scan_c_file': /home/rick/archives/xemacs-21.4.2/lib-src/make-docfile.c:515: warning: comparison between signed and unsigned gcc -Demacs -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/digest-doc.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o digest-doc gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/sorted-doc.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o sorted-doc gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/movemail.c /home/rick/archives/xemacs-21.4.2/lib-src/pop.c \ getopt.o getopt1.o regex.o -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o movemail /home/rick/archives/xemacs-21.4.2/lib-src/movemail.c: In function `main': /home/rick/archives/xemacs-21.4.2/lib-src/movemail.c:443: warning: comparison between signed and unsigned /tmp/ccezrTJw.o: In function `lock_dot': /home/rick/archives/xemacs-21.4.2/lib-src/movemail.c:591: the use of `mktemp' is dangerous, better use `mkstemp' gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/cvtmail.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o cvtmail gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/yow.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o yow /home/rick/archives/xemacs-21.4.2/lib-src/yow.c: In function `yow': /home/rick/archives/xemacs-21.4.2/lib-src/yow.c:164: warning: comparison between signed and unsigned gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/hexl.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o hexl gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/mmencode.c -o mmencode /home/rick/archives/xemacs-21.4.2/lib-src/mmencode.c: In function `fromqp': /home/rick/archives/xemacs-21.4.2/lib-src/mmencode.c:357: warning: comparison between signed and unsigned gcc -Demacs -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/make-path.c -o make-path gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -I../src -I/home/rick/archives/xemacs-21.4.2/lib-src -I/home/rick/archives/xemacs-21.4.2/src -DHAVE_CONFIG_H /home/rick/archives/xemacs-21.4.2/lib-src/make-dump-id.c -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o -o make-dump-id make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/lib-src' cd ./lwlib && make all make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/lwlib' gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include lwlib.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include lwlib-utils.c lwlib-utils.c: In function `XtApplyUntilToWidgets': lwlib-utils.c:122: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include lwlib-config.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include lwlib-Xm.c lwlib-Xm.c: In function `xm_update_one_value': lwlib-Xm.c:916: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include xlwmenu.c xlwmenu.c: In function `close_to_reference_time': xlwmenu.c:351: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include xlwscrollbar.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include xlwtabs.c xlwtabs.c: In function `TabsSetValues': xlwtabs.c:629: warning: comparison between signed and unsigned xlwtabs.c:670: warning: comparison between signed and unsigned xlwtabs.c: In function `TabsSelect': xlwtabs.c:1069: warning: comparison between signed and unsigned xlwtabs.c: In function `DrawTabs': xlwtabs.c:1395: warning: comparison between signed and unsigned xlwtabs.c:1405: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include xlwgcs.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -I. -DHAVE_CONFIG_H -I/usr/X11/include lwlib-Xlw.c lwlib-Xlw.c: In function `xlw_update_tab_control': lwlib-Xlw.c:435: warning: comparison between signed and unsigned rm -f liblw.a ar cq liblw.a lwlib.o lwlib-utils.o lwlib-config.o lwlib-Xm.o xlwmenu.o xlwscrollbar.o xlwtabs.o xlwgcs.o lwlib-Xlw.o make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/lwlib' cd ./src && make all make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/src' gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include pre-crt0.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include abbrev.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include alloc.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include blocktype.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include buffer.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include bytecode.c bytecode.c: In function `funcall_compiled_function': bytecode.c:486: warning: comparison between signed and unsigned bytecode.c: In function `execute_optimized_program': bytecode.c:634: warning: `opcode' might be used uninitialized in this function bytecode.c: In function `Fbyte_code': bytecode.c:2402: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include callint.c callint.c: In function `Fcall_interactively': callint.c:249: warning: `argcount' might be used uninitialized in this function callint.c:545: warning: `args' might be used uninitialized in this function callint.c:550: warning: `visargs' might be used uninitialized in this function callint.c:554: warning: `varies' might be used uninitialized in this function callint.c:555: warning: `arg_from_tty' might be used uninitialized in this function callint.c:556: warning: `argnum' might be used uninitialized in this function callint.c:571: warning: `prompt_start' might be used uninitialized in this function callint.c:572: warning: `prompt_limit' might be used uninitialized in this function callint.c:573: warning: `prompt_length' might be used uninitialized in this function callint.c:591: warning: `prompt_start' might be used uninitialized in this function callint.c:591: warning: `prompt_length' might be used uninitialized in this function callint.c:591: warning: `args' might be used uninitialized in this function callint.c:591: warning: `nargs' might be used uninitialized in this function callint.c:603: warning: `prompt_start' might be used uninitialized in this function callint.c:603: warning: `prompt_length' might be used uninitialized in this function callint.c:603: warning: `args' might be used uninitialized in this function callint.c:603: warning: `nargs' might be used uninitialized in this function callint.c:612: warning: `prompt_start' might be used uninitialized in this function callint.c:612: warning: `prompt_length' might be used uninitialized in this function callint.c:612: warning: `args' might be used uninitialized in this function callint.c:612: warning: `nargs' might be used uninitialized in this function callint.c:622: warning: `prompt_start' might be used uninitialized in this function callint.c:622: warning: `prompt_length' might be used uninitialized in this function callint.c:622: warning: `args' might be used uninitialized in this function callint.c:622: warning: `nargs' might be used uninitialized in this function callint.c:640: warning: `prompt_start' might be used uninitialized in this function callint.c:640: warning: `prompt_length' might be used uninitialized in this function callint.c:640: warning: `args' might be used uninitialized in this function callint.c:640: warning: `nargs' might be used uninitialized in this function callint.c:686: warning: `prompt_start' might be used uninitialized in this function callint.c:686: warning: `prompt_length' might be used uninitialized in this function callint.c:686: warning: `args' might be used uninitialized in this function callint.c:686: warning: `nargs' might be used uninitialized in this function callint.c:696: warning: `prompt_start' might be used uninitialized in this function callint.c:696: warning: `prompt_length' might be used uninitialized in this function callint.c:696: warning: `args' might be used uninitialized in this function callint.c:696: warning: `nargs' might be used uninitialized in this function callint.c:707: warning: `prompt_start' might be used uninitialized in this function callint.c:707: warning: `prompt_length' might be used uninitialized in this function callint.c:707: warning: `args' might be used uninitialized in this function callint.c:707: warning: `nargs' might be used uninitialized in this function callint.c:720: warning: `prompt_start' might be used uninitialized in this function callint.c:720: warning: `prompt_length' might be used uninitialized in this function callint.c:720: warning: `args' might be used uninitialized in this function callint.c:720: warning: `nargs' might be used uninitialized in this function callint.c:740: warning: `prompt_start' might be used uninitialized in this function callint.c:740: warning: `prompt_length' might be used uninitialized in this function callint.c:740: warning: `args' might be used uninitialized in this function callint.c:740: warning: `nargs' might be used uninitialized in this function callint.c:765: warning: `prompt_start' might be used uninitialized in this function callint.c:765: warning: `prompt_length' might be used uninitialized in this function callint.c:765: warning: `args' might be used uninitialized in this function callint.c:765: warning: `nargs' might be used uninitialized in this function callint.c:807: warning: `prompt_start' might be used uninitialized in this function callint.c:807: warning: `prompt_length' might be used uninitialized in this function callint.c:807: warning: `args' might be used uninitialized in this function callint.c:807: warning: `nargs' might be used uninitialized in this function callint.c:822: warning: `prompt_start' might be used uninitialized in this function callint.c:822: warning: `prompt_length' might be used uninitialized in this function callint.c:822: warning: `args' might be used uninitialized in this function callint.c:822: warning: `nargs' might be used uninitialized in this function callint.c:840: warning: `prompt_start' might be used uninitialized in this function callint.c:840: warning: `prompt_length' might be used uninitialized in this function callint.c:840: warning: `args' might be used uninitialized in this function callint.c:840: warning: `nargs' might be used uninitialized in this function callint.c:847: warning: `prompt_start' might be used uninitialized in this function callint.c:847: warning: `prompt_length' might be used uninitialized in this function callint.c:847: warning: `args' might be used uninitialized in this function callint.c:847: warning: `nargs' might be used uninitialized in this function callint.c:854: warning: `prompt_start' might be used uninitialized in this function callint.c:854: warning: `prompt_length' might be used uninitialized in this function callint.c:854: warning: `args' might be used uninitialized in this function callint.c:854: warning: `nargs' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include callproc.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include casefiddle.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include casetab.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include chartab.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include cmdloop.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include cmds.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include console.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include console-stream.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include data.c data.c: In function `Faref': data.c:718: warning: comparison between signed and unsigned data.c: In function `Faset': data.c:772: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include device.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include dired.c dired.c: In function `user_name_completion': dired.c:644: warning: comparison between signed and unsigned dired.c:644: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include doc.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include doprnt.c doprnt.c: In function `emacs_doprnt_1': doprnt.c:602: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include dynarr.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include editfns.c editfns.c: In function `Ftemp_directory': editfns.c:640: warning: comparison between signed and unsigned editfns.c: In function `Fencode_time': editfns.c:1218: warning: `tzstring' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include elhash.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include emacs.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include eval.c eval.c: In function `grow_specpdl': eval.c:4794: warning: comparison between signed and unsigned eval.c:4798: warning: comparison between signed and unsigned eval.c:4808: warning: comparison between signed and unsigned eval.c: In function `specbind': eval.c:4894: warning: comparison between signed and unsigned eval.c: In function `record_unwind_protect': eval.c:4933: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include events.c events.c: In function `Fmake_event': events.c:497: warning: `keyword' might be used uninitialized in this function events.c:497: warning: `hare_keyword' might be used uninitialized in this function events.c:497: warning: `tortoise_keyword' might be used uninitialized in this function events.c:497: warning: `len_keyword' might be used uninitialized in this function events.c:548: warning: `modifiers' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include filelock.c filelock.c: In function `current_lock_owner': filelock.c:228: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include unexelf.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include balloon_help.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include balloon-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include dgif_lib.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include gif_io.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include menubar.c menubar.c: In function `Fmenu_find_real_submenu': menubar.c:185: warning: `submenu' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include scrollbar.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include dialog.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include toolbar.c toolbar.c: In function `Fset_default_toolbar_position': toolbar.c:235: warning: `cur' might be used uninitialized in this function toolbar.c:236: warning: `new' might be used uninitialized in this function toolbar.c: In function `update_frame_toolbars': toolbar.c:735: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include menubar-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include scrollbar-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include dialog-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include toolbar-x.c In file included from /usr/X11/include/Xm/PrimitiveP.h:28, from xmprimitivep.h:31, from EmacsFrameP.h:30, from toolbar-x.c:35: /usr/X11/include/Xm/XmP.h:1056: warning: declaration of `message' shadows global declaration /usr/X11/include/Xm/XmP.h:1057: warning: declaration of `message' shadows global declaration gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include gui-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include realpath.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include inline.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include linuxplay.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include esd.c esd.c: In function `esd_play_sound_data': esd.c:116: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include miscplay.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include console-tty.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include device-tty.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include event-tty.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include frame-tty.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include objects-tty.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include redisplay-tty.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include cm.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include terminfo.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include gpmevent.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include event-unixoid.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include database.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include sysdll.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include emodules.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include process-unix.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include event-stream.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include extents.c extents.c: In function `Fextent_at': extents.c:4399: warning: `fl' might be used uninitialized in this function extents.c:4411: warning: `at_flag' might be used uninitialized in this function extents.c: In function `Fextents_at': extents.c:4449: warning: `fl' might be used uninitialized in this function extents.c:4461: warning: `at_flag' might be used uninitialized in this function extents.c: In function `Fset_extent_begin_glyph': extents.c:5084: warning: `layout' might be used uninitialized in this function extents.c: In function `Fset_extent_end_glyph': extents.c:5084: warning: `layout' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include faces.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include fileio.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include filemode.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include floatfns.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include fns.c fns.c: In function `print_bit_vector': fns.c:76: warning: comparison between signed and unsigned fns.c: In function `Fload_average': fns.c:3177: warning: implicit declaration of function `getloadavg' fns.c: In function `Fget': fns.c:2567: warning: `val' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include font-lock.c font-lock.c: In function `find_context': font-lock.c:518: warning: comparison between signed and unsigned font-lock.c:624: warning: comparison between signed and unsigned font-lock.c:633: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include frame.c frame.c: In function `delete_frame_internal': frame.c:1568: warning: `ecran' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include general.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include glyphs.c glyphs.c: In function `Fset_instantiator_property': glyphs.c:482: warning: `elt' might be used uninitialized in this function glyphs.c:483: warning: `len' might be used uninitialized in this function glyphs.c: In function `normalize_image_instantiator': glyphs.c:378: warning: `typevec' might be used uninitialized in this function glyphs.c: In function `check_for_ignored_expose': glyphs.c:4424: warning: comparison between signed and unsigned glyphs.c:4425: warning: comparison between signed and unsigned glyphs.c:4426: warning: comparison between signed and unsigned glyphs.c:4426: warning: comparison between signed and unsigned glyphs.c: In function `find_matching_subwindow': glyphs.c:4495: warning: comparison between signed and unsigned glyphs.c:4497: warning: comparison between signed and unsigned glyphs.c:4500: warning: comparison between signed and unsigned glyphs.c:4502: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include glyphs-eimage.c In file included from glyphs-eimage.c:67: /usr/include/png.h:1270: warning: declaration of `error' shadows global declaration /usr/include/png.h:1274: warning: declaration of `error' shadows global declaration /usr/include/png.h:1278: warning: declaration of `message' shadows global declaration /usr/include/png.h:1282: warning: declaration of `message' shadows global declaration glyphs-eimage.c: In function `our_skip_input_data': glyphs-eimage.c:237: warning: comparison between signed and unsigned glyphs-eimage.c: In function `jpeg_instantiate': glyphs-eimage.c:455: warning: comparison between signed and unsigned glyphs-eimage.c: In function `gif_read_from_memory': glyphs-eimage.c:571: warning: comparison between signed and unsigned glyphs-eimage.c: In function `png_read_from_memory': glyphs-eimage.c:788: warning: comparison between signed and unsigned glyphs-eimage.c: In function `tiff_instantiate': glyphs-eimage.c:1291: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include glyphs-widget.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include gui.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include gutter.c gutter.c: In function `update_gutter_geometry': gutter.c:582: warning: comparison between signed and unsigned gutter.c: In function `Fset_default_gutter_position': gutter.c:740: warning: `cur' might be used uninitialized in this function gutter.c:741: warning: `new' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include hash.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include imgproc.c imgproc.c: In function `get_histogram': imgproc.c:60: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include indent.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include insdel.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include intl.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include keymap.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include line-number.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include lread.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include lstream.c lstream.c: In function `Lstream_adding': lstream.c:418: warning: comparison between signed and unsigned lstream.c:418: warning: comparison between signed and unsigned lstream.c: In function `Lstream_read_more': lstream.c:539: warning: comparison between signed and unsigned lstream.c:539: warning: comparison between signed and unsigned lstream.c: In function `Lstream_unread': lstream.c:627: warning: comparison between signed and unsigned lstream.c:627: warning: comparison between signed and unsigned lstream.c: In function `resizing_buffer_writer': lstream.c:1374: warning: comparison between signed and unsigned lstream.c:1374: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include macros.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include marker.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include md5.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include minibuf.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include objects.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include opaque.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include print.c print.c: In function `print_internal': print.c:1226: warning: `i' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include process.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include profile.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include rangetab.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include redisplay.c redisplay.c: In function `point_in_line_start_cache': redisplay.c:7411: warning: comparison between signed and unsigned redisplay.c:7422: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include redisplay-output.c redisplay-output.c: In function `redisplay_unmap_subwindows': redisplay-output.c:1178: warning: comparison between signed and unsigned redisplay-output.c:1180: warning: comparison between signed and unsigned redisplay-output.c:1183: warning: comparison between signed and unsigned redisplay-output.c:1185: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include regex.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include search.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include select.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include signal.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include sound.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include specifier.c specifier.c: In function `Fadd_spec_to_specifier': specifier.c:1968: warning: `add_meth' might be used uninitialized in this function specifier.c:428: warning: `i' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include strftime.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include symbols.c symbols.c: In function `oblookup': symbols.c:345: warning: `tail' might be used uninitialized in this function symbols.c: In function `defsymbol_massage_name_1': symbols.c:3299: warning: comparison between signed and unsigned symbols.c:3301: warning: comparison between signed and unsigned symbols.c: In function `defkeyword_massage_name': symbols.c:3374: warning: comparison between signed and unsigned symbols.c: In function `deferror_massage_name_and_message': symbols.c:3510: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include syntax.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include sysdep.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include undo.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include console-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include device-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include event-Xt.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include frame-x.c In file included from /usr/X11/include/Xm/PrimitiveP.h:28, from xmprimitivep.h:31, from EmacsFrameP.h:30, from frame-x.c:40: /usr/X11/include/Xm/XmP.h:1056: warning: declaration of `message' shadows global declaration /usr/X11/include/Xm/XmP.h:1057: warning: declaration of `message' shadows global declaration gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include glyphs-x.c glyphs-x.c: In function `convert_EImage_to_XImage': glyphs-x.c:254: warning: comparison between signed and unsigned glyphs-x.c:254: warning: comparison between signed and unsigned glyphs-x.c: In function `x_finalize_image_instance': glyphs-x.c:446: warning: comparison between signed and unsigned glyphs-x.c: In function `x_xpm_instantiate': glyphs-x.c:1309: warning: `dpy' might be used uninitialized in this function glyphs-x.c:1310: warning: `xs' might be used uninitialized in this function glyphs-x.c:1311: warning: `cmap' might be used uninitialized in this function glyphs-x.c:1312: warning: `depth' might be used uninitialized in this function glyphs-x.c:1313: warning: `visual' might be used uninitialized in this function glyphs-x.c:1317: warning: `result' might be used uninitialized in this function glyphs-x.c:1321: warning: `type' might be used uninitialized in this function glyphs-x.c:1322: warning: `force_mono' might be used uninitialized in this function glyphs-x.c:1364: warning: `type' might be used uninitialized in this function glyphs-x.c:1370: warning: `__s' might be used uninitialized in this function glyphs-x.c:1513: warning: `xs' might be used uninitialized in this function gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include objects-x.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include redisplay-x.c In file included from /usr/X11/include/Xm/PrimitiveP.h:28, from xmprimitivep.h:31, from EmacsFrameP.h:30, from redisplay-x.c:34: /usr/X11/include/Xm/XmP.h:1056: warning: declaration of `message' shadows global declaration /usr/X11/include/Xm/XmP.h:1057: warning: declaration of `message' shadows global declaration redisplay-x.c: In function `x_output_string': redisplay-x.c:983: warning: comparison between signed and unsigned redisplay-x.c:985: warning: comparison between signed and unsigned redisplay-x.c:1017: warning: comparison between signed and unsigned redisplay-x.c:1019: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include select-x.c In file included from select-x.c:45: /usr/X11/include/Xm/CutPaste.h:81: warning: declaration of `index' shadows global declaration gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include xgccache.c xgccache.c: In function `gc_cache_hash': xgccache.c:107: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include widget.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include window.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include lastfile.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include vm-limit.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include EmacsFrame.c In file included from /usr/X11/include/Xm/PrimitiveP.h:28, from xmprimitivep.h:31, from EmacsFrameP.h:30, from EmacsFrame.c:36: /usr/X11/include/Xm/XmP.h:1056: warning: declaration of `message' shadows global declaration /usr/X11/include/Xm/XmP.h:1057: warning: declaration of `message' shadows global declaration EmacsFrame.c: In function `EmacsFrameSetValues': EmacsFrame.c:521: warning: comparison between signed and unsigned gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include EmacsShell.c gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include -DDEFINE_TOP_LEVEL_EMACS_SHELL /home/rick/archives/xemacs-21.4.2/src/EmacsShell-sub.c mv EmacsShell-sub.o TopLevelEmacsShell.o gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include -DDEFINE_TRANSIENT_EMACS_SHELL /home/rick/archives/xemacs-21.4.2/src/EmacsShell-sub.c mv EmacsShell-sub.o TransientEmacsShell.o gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11/include EmacsManager.c gcc -nostdlib -L/usr/X11/lib -Wl,-export-dynamic -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o unexelf.o balloon_help.o balloon-x.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o realpath.o inline.o linuxplay.o esd.o miscplay.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o gpmevent.o event-unixoid.o database.o sysdll.o emodules.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o lastfile.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o ../lwlib/liblw.a -lXm -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o `gcc -print-libgcc-file-name` ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... rm -f ../lib-src/DOC; \ ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/make-docfile.el -- \ -o ../lib-src/DOC -d /home/rick/archives/xemacs-21.4.2/src -i ../lib-src/../site-packages \ abbrev.c alloc.c blocktype.c buffer.c bytecode.c callint.c callproc.c casefiddle.c casetab.c chartab.c cmdloop.c cmds.c console.c console-stream.c data.c device.c dired.c doc.c doprnt.c dynarr.c editfns.c elhash.c emacs.c eval.c events.c filelock.c unexelf.c balloon_help.c balloon-x.c dgif_lib.c gif_io.c menubar.c scrollbar.c dialog.c toolbar.c menubar-x.c scrollbar-x.c dialog-x.c toolbar-x.c gui-x.c realpath.c inline.c linuxplay.c esd.c miscplay.c console-tty.c device-tty.c event-tty.c frame-tty.c objects-tty.c redisplay-tty.c cm.c terminfo.c gpmevent.c event-unixoid.c database.c sysdll.c emodules.c process-unix.c event-stream.c extents.c faces.c fileio.c filemode.c floatfns.c fns.c font-lock.c frame.c general.c glyphs.c glyphs-eimage.c glyphs-widget.c gui.c gutter.c hash.c imgproc.c indent.c insdel.c intl.c keymap.c line-number.c lread.c lstream.c macros.c marker.c md5.c minibuf.c objects.c opaque.c print.c process.c profile.c rangetab.c redisplay.c redisplay-output.c regex.c search.c select.c signal.c sound.c specifier.c strftime.c symbols.c syntax.c sysdep.c undo.c console-x.c device-x.c event-Xt.c frame-x.c glyphs-x.c objects-x.c redisplay-x.c select-x.c xgccache.c widget.c window.c Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/make-docfile.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading custom... Loading widget... Loading custom ...done Loading process... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... Spawning make-docfile ... Spawning make-docfile ...done ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/loadup.el dump Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/loadup.el... Using load-path (/home/rick/archives/xemacs-21.4.2/lisp) Using module-load-path (/home/rick/archives/xemacs-21.4.2/modules) Loading very-early-lisp... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/backquote.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/bytecomp-runtime.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/find-paths.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/packages.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/setup-paths.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/dump-paths.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/subr.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/replace.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/version.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/cl.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/cl-extra.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/cl-seq.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/widget.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/custom.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/cus-start.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/cmdloop.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/keymap.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/syntax.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/device.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/console.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/obsolete.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/specifier.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/faces.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/glyphs.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/objects.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/extents.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/events.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/text-props.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/process.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/multicast.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/frame.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/map-ynp.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/simple.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/keydefs.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/abbrev.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/derived.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/minibuf.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/list-mode.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/modeline.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/cus-file.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/startup.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/misc.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/help-nomule.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/help.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/files-nomule.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/files.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/lib-complete.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/format.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/indent.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/isearch-mode.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/buffer.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/buff-menu.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/undo-stack.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/window.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/window-xemacs.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/paths.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/lisp.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/page.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/register.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/iso8859-1.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/paragraphs.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/easymenu.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/lisp-mode.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/text-mode.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/fill.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/auto-save.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/movemail.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/float-sup.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/itimer.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/itimer-autosave.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/printer.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/gui.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/mouse.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/mode-motion.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/toolbar.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/scrollbar.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/menubar.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/dialog.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/gutter.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/select.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/menubar-items.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/gutter-items.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/toolbar-items.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/dialog-items.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-faces.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-iso8859-1.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-mouse.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-select.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-scrollbar.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-misc.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-init.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-win-xfree86.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/x-win-sun.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/tty-init.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/fontl-hooks.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/auto-show.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/loadhist.elc... Loading /home/rick/archives/xemacs-21.4.2/lisp/loaddefs.elc... Loading site-load... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name xemacs Testing for Lisp shadows ... make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/src' Building finder database ... Wrote /home/rick/archives/xemacs-21.4.2/lisp/finder-inf.el Building finder database ...(done) cd ./src && make dump-elcs make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/src' ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/src' /home/rick/archives/xemacs-21.4.2/src/xemacs -batch -vanilla \ -l update-elc-2.el -f batch-update-elc-2 lisp Removing old or spurious .elcs in directory tree `lisp'... Removing old or spurious .elcs in directory tree `lisp'...done Recompiling updated .els in directory tree `lisp'... Compiling /home/rick/archives/xemacs-21.4.2/lisp/finder-inf.el... Wrote /home/rick/archives/xemacs-21.4.2/lisp/finder-inf.elc Recompiling updated .els in directory tree `lisp'...done cd /home/rick/archives/xemacs-21.4.2/man && make info make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/man' make[1]: Nothing to be done for `info'. make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/man' ~/archives/xemacs-21.4.2 $ make install cd ./lib-src && make all make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/lib-src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/lib-src' cd ./lwlib && make all make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/lwlib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/lwlib' cd ./src && make all make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/src' ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/src' cd ./src && make dump-elcs make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/src' ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/src' /home/rick/archives/xemacs-21.4.2/src/xemacs -batch -vanilla \ -l update-elc-2.el -f batch-update-elc-2 lisp Removing old or spurious .elcs in directory tree `lisp'... Removing old or spurious .elcs in directory tree `lisp'...done Recompiling updated .els in directory tree `lisp'... Recompiling updated .els in directory tree `lisp'...done cd /home/rick/archives/xemacs-21.4.2/man && make info make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/man' make[1]: Nothing to be done for `info'. make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/man' /home/rick/archives/xemacs-21.4.2/src/xemacs -batch -l check-features.el ./lib-src/make-path /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/etc /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/lisp /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/info /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux \ /usr/misc/packages/xemacs/21.4.2/man/man1 /usr/misc/packages/xemacs/21.4.2/bin /usr/misc/packages/xemacs/21.4.2/lib /usr/misc/packages/xemacs/21.4.2/lib /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/lisp \ /usr/misc/packages/xemacs/21.4.2/lib/xemacs/site-lisp /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/modules /usr/misc/packages/xemacs/21.4.2/lib/xemacs/site-modules for subdir in lib-src src; do \ (cd ./${subdir} && make install prefix=/usr/misc/packages/xemacs/21.4.2 \ exec_prefix=/usr/misc/packages/xemacs/21.4.2 bindir=/usr/misc/packages/xemacs/21.4.2/bin libdir=/usr/misc/packages/xemacs/21.4.2/lib \ archlibdir=/usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux) ; done make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/lib-src' Installing utilities run internally by XEmacs. ./make-path /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux if test "`(cd /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux && /bin/pwd)`" != "`/bin/pwd`"; then \ for f in gnuserv fakemail wakeup profile make-docfile digest-doc sorted-doc movemail cvtmail yow hexl mmencode; do \ (cd .. && /usr/bin/ginstall -c lib-src/$f /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/$f) ; \ done ; \ fi if test "`(cd /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux && /bin/pwd)`" \ != "`(cd /home/rick/archives/xemacs-21.4.2/lib-src && /bin/pwd)`"; then \ for f in rcs2log vcdiff gzip-el.sh add-big-package.sh; do \ (cd .. && /usr/bin/ginstall -c /home/rick/archives/xemacs-21.4.2/lib-src/$f /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/$f); \ done ; \ fi Installing utilities for users to run. for file in gnuclient ellcc etags ctags b2m ootags ; do \ (cd .. && /usr/bin/ginstall -c lib-src/${file} /usr/misc/packages/xemacs/21.4.2/bin/${file}) ; \ done for file in gnudoit gnuattach rcs-checkin ; do \ (cd .. && /usr/bin/ginstall -c /home/rick/archives/xemacs-21.4.2/lib-src/${file} /usr/misc/packages/xemacs/21.4.2/bin/${file}) ; \ done make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/lib-src' make[1]: Entering directory `/home/rick/archives/xemacs-21.4.2/src' ./temacs -nd -batch -l /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el Loading /home/rick/archives/xemacs-21.4.2/src/../lisp/update-elc.el... Loading very-early-lisp... Loading find-paths.el... Loading packages.el... Loading setup-paths.el... Loading dump-paths.el... Loading /home/rick/archives/xemacs-21.4.2/lisp/dumped-lisp.el... ../lib-src/make-path /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/include /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/include/m /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/include/s Copying include files for ellcc... make[1]: Leaving directory `/home/rick/archives/xemacs-21.4.2/src' if test "`(cd /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux && /bin/pwd)`" != \ "`(cd ./lib-src && /bin/pwd)`"; then \ if test -f ../Installation; then \ /usr/bin/ginstall -c -m 644 ../Installation /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/Installation; \ fi; \ /usr/bin/ginstall -c -m 644 lib-src/config.values /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/config.values; \ /usr/bin/ginstall -c -m 644 lib-src/DOC /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux/DOC; \ for subdir in `find /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/i586-pc-linux -type d ! -name RCS ! -name SCCS ! -name CVS -print` ; \ do (cd ${subdir} && rm -f -r RCS CVS SCCS \#* *~) ; done ; \ else true; fi /usr/bin/ginstall -c src/xemacs /usr/misc/packages/xemacs/21.4.2/bin/xemacs-21.4.2 chmod 0755 /usr/misc/packages/xemacs/21.4.2/bin/xemacs-21.4.2 cd /usr/misc/packages/xemacs/21.4.2/bin && rm -f ./xemacs && ln -s xemacs-21.4.2 ./xemacs if test "/usr/misc/packages/xemacs/21.4.2" != "/usr/misc/packages/xemacs/21.4.2"; then \ ./lib-src/make-path /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2; \ for dir in \ lib/xemacs \ lib/xemacs-21.4.2/etc \ lib/xemacs-21.4.2/info \ lib/xemacs-21.4.2/lisp; do \ if test ! -d /usr/misc/packages/xemacs/21.4.2/${dir}; then \ ln -s /usr/misc/packages/xemacs/21.4.2/${dir} /usr/misc/packages/xemacs/21.4.2/${dir}; fi; \ done; \ fi set /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/etc /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/lisp ; \ for dir in /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/etc /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/lisp ; do \ if test ! -d ${dir} ; then mkdir ${dir} ; fi ; \ done ; \ for dir in /home/rick/archives/xemacs-21.4.2/etc /home/rick/archives/xemacs-21.4.2/lisp ; do \ dest=$1 ; shift ; \ test -d ${dir} \ -a "`(cd ${dir} && /bin/pwd)`" != \ "`(cd ${dest} && /bin/pwd)`" \ && (echo "Copying ${dir}..." ; \ (cd ${dir} && tar -cf - . ) | \ (cd ${dest} && umask 022 && tar -xf - );\ chmod 0755 ${dest}; \ for subdir in `find ${dest} -type d ! -name RCS ! -name SCCS ! -name CVS -print` ; do \ (cd ${subdir} && rm -f -r RCS CVS SCCS \#* *~) ; \ done) ; \ done Copying /home/rick/archives/xemacs-21.4.2/etc... Copying /home/rick/archives/xemacs-21.4.2/lisp... if test "`(cd /home/rick/archives/xemacs-21.4.2/info && /bin/pwd)`" != \ "`(cd /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/info && /bin/pwd)`" && cd /home/rick/archives/xemacs-21.4.2/info; then \ if test ! -f /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/info/dir -a -f dir ; then \ /usr/bin/ginstall -c -m 644 /home/rick/archives/xemacs-21.4.2/info/dir /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/info/dir ; \ fi ; \ for file in *.info* ; do \ /usr/bin/ginstall -c -m 644 ${file} /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/info/${file} ; \ chmod 0644 /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/info/${file}; \ done ; \ fi cd /home/rick/archives/xemacs-21.4.2/etc && \ for page in xemacs etags ctags gnuserv gnuclient gnuattach gnudoit; do \ /usr/bin/ginstall -c -m 644 /home/rick/archives/xemacs-21.4.2/etc/${page}.1 /usr/misc/packages/xemacs/21.4.2/man/man1/${page}.1 ; \ chmod 0644 /usr/misc/packages/xemacs/21.4.2/man/man1/${page}.1 ; \ done If you would like to save approximately 2M of disk space, do make gzip-el or you may run /home/rick/archives/xemacs-21.4.2/lib-src/gzip-el.sh lispdir from the command line. Where lispdir is where the lisp files were installed, i.e., /usr/misc/packages/xemacs/21.4.2/lib/xemacs-21.4.2/lisp --Multipart_Sat_May_12_22:59:02_2001-1-- From karlheg@hegbloom.net Sun May 13 02:59:49 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA07560 for ; Sun, 13 May 2001 02:59:48 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4D6xlm6024061 for ; Sat, 12 May 2001 23:59:47 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4D6xliv024058; Sat, 12 May 2001 23:59:47 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: [21.4.2] TTY only compilation broken - Qscrollbar_line_up undefined From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 12 May 2001 23:59:47 -0700 Message-ID: <87lmo1ybrw.fsf@bittersweet.intra.hegbloom.net> Lines: 63 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Not sure how to fix this. Please advise. uname -a: Linux karl 2.4.3 #2 SMP Sat May 5 00:16:46 PDT 2001 i686 unknown /usr/local/src/PKG/sid/main/xemacs/xemacs/configure '--extra-verbose' '--error-checking=none' '--debug=no' '--cppflags=' '--cflags=-Os -ggdb -Wall -Wno-switch' '--ldflags=' '--prefix=/usr' '--statedir=/var/state' '--infodir=/usr/share/info/xemacs-21.4-21.4' '--infopath=/usr/local/share/info/:/usr/local/info/:/usr/share/info/xemacs-21.4-21.4/:/usr/share/info/:/usr/info/' '--lispdir=/usr/share/xemacs-21.4/21.4/lisp' '--package-path=::/usr/local/share/xemacs::/usr/share/xemacs' '--with-socks=no' '--mail-locking=dot' '--with-pop' '--with-gpm=no' '--docdir=/usr/lib/xemacs/21.4/i386-debian_minimalist-linux/minimalist' '--with-x11=no' '--with-gpm=no' '--with-sound=none' '--with-database=no' '--with-ldap=no' '--with-postgresql=no' '--with-socks=no' '--with-modules=no' '--with-mule=no' '--with-file-coding=no' 'i386-debian_minimalist-linux' XEmacs 21.4.2 "Developer-Friendly Unix APIs" configured for `i386-debian_minimalist-linux'. Compilation / Installation: Source code location: /usr/local/src/PKG/sid/main/xemacs/xemacs Installation prefix: /usr Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -Os -ggdb -Wall -Wno-switch Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: TTY: Compiling in support for ncurses. Images: Sound: Databases: Internationalization: Mail: Compiling in support for POP mail retrieval. Compiling in support for "dot-locking" mail spool file locking method. Other Features: [ ... ] gcc -c -Os -ggdb -Wall -Wno-switch -Demacs -I. -DHAVE_CONFIG_H /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c: In function `is_scrollbar_event': /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3772: `Qscrollbar_line_up' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3772: (Each undeclared identifier is reported only once /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3772: for each function it appears in.) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3773: `Qscrollbar_line_down' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3774: `Qscrollbar_page_up' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3775: `Qscrollbar_page_down' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3776: `Qscrollbar_to_top' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3777: `Qscrollbar_to_bottom' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3778: `Qscrollbar_vertical_drag' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3779: `Qscrollbar_char_left' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3780: `Qscrollbar_char_right' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3781: `Qscrollbar_page_left' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3782: `Qscrollbar_page_right' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3783: `Qscrollbar_to_left' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3784: `Qscrollbar_to_right' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3785: `Qscrollbar_horizontal_drag' undeclared (first use in this function) /usr/local/src/PKG/sid/main/xemacs/xemacs/src/event-stream.c:3786: warning: control reaches end of non-void function make[1]: *** [event-stream.o] Error 1 make[1]: Leaving directory `/usr/local/src/PKG/sid/main/xemacs/debian.xemacs/xemacs-21.4-minimalist-build/src' From youngs@xemacs.org Sun May 13 05:46:59 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA17861 for ; Sun, 13 May 2001 05:46:57 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4D9krl28254 for ; Sun, 13 May 2001 19:46:53 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4CBEVkq023737; Sat, 12 May 2001 21:14:31 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: jde/setnu.el References: <15092.11542.60000.650214@shrdlu.muniversal.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 21:14:31 +1000 In-Reply-To: (Adrian.Aichner@t-online.de's message of "05 May 2001 19:42:11 +0200") Message-ID: Lines: 19 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "APA" == Adrian Aichner writes: APA> Kyle Jones wrote one APA> setnu.el APA> a few years ago. APA> See APA> http://www.wonderworks.com/ APA> It does not appear to be part of XEmacs, though. It is. Look in the JDE package. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Sun May 13 05:47:00 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA17863 for ; Sun, 13 May 2001 05:46:58 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4D9khl28155; Sun, 13 May 2001 19:46:44 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4CBP4Jf023748; Sat, 12 May 2001 21:25:04 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: Paul Kinnucan Subject: Re: jde/setnu.el References: <15092.11542.60000.650214@shrdlu.muniversal.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 21:25:04 +1000 In-Reply-To: <15092.11542.60000.650214@shrdlu.muniversal.com> (Jeff Mincy's message of "Sat, 5 May 2001 12:40:54 -0400") Message-ID: Lines: 16 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "JM" == Jeff Mincy writes: JM> BTW, it seems like jde is the wrong place for this file? JM> Wouldn't text-modes or something be more appropriate? Yeah probably. Paul, would you have any objections to me moving setnu.el out of your JDE package? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Sun May 13 05:47:07 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA17882 for ; Sun, 13 May 2001 05:47:06 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4D9l2l28408 for ; Sun, 13 May 2001 19:47:03 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4C8kF3Y032748; Sat, 12 May 2001 18:46:15 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: find-function & load-history References: <15091.58000.258819.143117@turnbull.sk.tsukuba.ac.jp> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 18:46:13 +1000 In-Reply-To: (npak@ispras.ru's message of "07 May 2001 17:12:52 +0400") Message-ID: Lines: 25 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "NVP" == Nick V Pakoulin writes: NVP> intro: "SY" == Steve Youngs writes: SY> |--==> "SJT" == Stephen J Turnbull writes: >>>>>>>>"SY" == Steve Youngs writes: SY> How can I make [find-function] show me [...] the installed version? SJT> (setq find-function-source-path nil) should work. SY> Nope, tried that. It doesn't work, sorry. Any other ideas? NVP> Replace in `load-history' filenames for dumped filee. Make an evil hack: NVP> (dolist (entry load-history) NVP> (when (string-match "/build/directory/" (car entry)) NVP> (setcar entry NVP> (replace-match "/installation/directory/" NVP> t t (car entry))))) That works. Thanks. :-) -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Sun May 13 05:47:16 2001 Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [203.2.75.229]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA17900 for ; Sun, 13 May 2001 05:47:14 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail005.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4D9l0l12407; Sun, 13 May 2001 19:47:01 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4CAtlUh023718; Sat, 12 May 2001 20:55:47 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: "John A. Turner" Subject: Re: mule question References: <15070.11973.9609.164337@denmark.blueskystudios.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 12 May 2001 20:55:47 +1000 In-Reply-To: <15070.11973.9609.164337@denmark.blueskystudios.com> ("John A. Turner"'s message of "Wed, 18 Apr 2001 20:18:13 -0400") Message-ID: Lines: 29 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii First off, please accept my apologies for taking so long to respond to this. |--==> "JAT" == John A Turner writes: JAT> but now when I start my non-mule xemacs I see these warnings: JAT> (1) (warning/warning) Autoload error in: JAT> /usr/net/rnd/lib/xemacs/mule-packages/lisp/skk/auto-autoloads: JAT> Cannot open load file: mule This definitely shouldn't happen. A non-Mule XEmacs won't see the packages in ./mule-packages/. Or, at least it won't by default. What's in your load-path? Could we see your: ~/.emacs or ~/.xemacs/init.el M-x describe-installation please. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From Adrian.Aichner@t-online.de Sun May 13 06:11:16 2001 Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA18666; Sun, 13 May 2001 06:11:15 -0400 Received: from fwd03.sul.t-online.de by mailout04.sul.t-online.com with smtp id 14ysqT-0003A1-01; Sun, 13 May 2001 12:11:25 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.63]) by fwd03.sul.t-online.com with esmtp id 14ysqZ-0xFlOyC; Sun, 13 May 2001 12:11:31 +0200 To: XEmacs Review Mailing List Cc: XEmacs Beta List Subject: make-local-variable.*hook: Incorrect usage in packages and core? X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) Date: 13 May 2001 12:10:56 +0200 Lines: 57 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Sender: 520002458184-0001@t-dialin.net --=-=-= Hi All, I'd like to solicit your feedback on this issue. Yesterday I found the cause for mouse-track-insert not to work between buffers, at least under native Windows, today I found more: buff-meu.el, compile.el, info.el all incorrectly make `mouse-track-click-hook' local via `make-local-variable'. mouse-track-insert between buffers works fine until either of C-x C-b (list-buffers), M-x compile, or C-h i (info) are executed. According to documentation of `add-hook', `make-local-hook' should be used for hook variables instead. Documentation of `make-local-hook' has a worrying, uninformative hint about non-normal hooks, which will have to be changed one by one. Can anyone here elaborate on this hint? A few questions arise: 1. Does mouse-track-insert work between buffers under X, after running any of the offenders above? 2. Should mouse-track-click-hook be used as a local hook by buff-meu.el, compile.el, info.el? 3. Should all instances of (make-local-variable A) (add-hook A B) be converted to (make-local-hook A) (add-hook A B) Here is what I found in core lisp: --=-=-= Content-Disposition: attachment; filename=igrep-make-local-variable--hook.err cd c:\Hacking\XEmacs\xemacs-21.5\ c:\cygwin\bin\find c:\Hacking\XEmacs\xemacs-21.5 -type d "(" -name RCS -o -name CVS -o -name SCCS ")" -prune -o -type f "!" -name "*~" "!" -name "*,v" "!" -name "s.*" -name "*.el" -print0 | xargs -0 -e egrep -n -e "make-local-variable.*hook" NUL Compilation started at Sun May 13 10:17:41 2001 +0200 (W. Europe Daylight Time) c:\Hacking\XEmacs\xemacs-21.5/lisp/files.el:2807: (make-local-variable 'revert-buffer-internal-hook) c:\Hacking\XEmacs\xemacs-21.5/lisp/info.el:3021: (make-local-variable 'mouse-track-click-hook) c:\Hacking\XEmacs\xemacs-21.5/lisp/minibuf.el:435: (make-local-variable 'mode-motion-hook) c:\Hacking\XEmacs\xemacs-21.5/lisp/minibuf.el:439: (make-local-variable 'mouse-track-click-hook) c:\Hacking\XEmacs\xemacs-21.5/lisp/subr.el:121:Do not use `make-local-variable' to make a hook variable buffer-local. c:\Hacking\XEmacs\xemacs-21.5/lisp/subr.el:127: (make-local-variable hook) c:\Hacking\XEmacs\xemacs-21.5/lisp/subr.el:157: ;; Detect the case where make-local-variable was used on a hook c:\Hacking\XEmacs\xemacs-21.5/lisp/subr.el:213: ;; Detect the case where make-local-variable was used on a hook c:\Hacking\XEmacs\xemacs-21.5/lisp/view-less.el:200: (add-hook (make-local-variable 'change-major-mode-hook) igrep finished at Sun May 13 10:19:07 --=-=-= This is what I found in xemacs-packages lisp: --=-=-= Content-Disposition: attachment; filename=igrep-make-local-variable--hook.err cd c:\Hacking\XEmacs\xemacs-packages\ c:\cygwin\bin\find c:\Hacking\XEmacs\xemacs-packages -type d "(" -name RCS -o -name CVS -o -name SCCS ")" -prune -o -type f "!" -name "*~" "!" -name "*,v" "!" -name "s.*" -name "*.el" -print0 | xargs -0 -e egrep -n -e "make-local-variable.*hook" NUL Compilation started at Sun May 13 09:48:42 2001 +0200 (W. Europe Daylight Time) c:\Hacking\XEmacs\xemacs-packages/comm/bbdb/lisp/bbdb.el:1414: (make-local-variable 'write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/comm/eicq/eicq.el:977: (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/comm/eicq/eicq.el:989: (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/comm/gnats/gnats.el:403: (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/comm/gnus/gnus/lisp/gnus-msg.el:1278: (make-local-variable 'message-setup-hook) c:\Hacking\XEmacs\xemacs-packages/comm/mh-e/mh-comp.el:746: (make-local-variable 'auto-fill-hook) c:\Hacking\XEmacs\xemacs-packages/comm/mh-e/mh-e.el:849: (make-local-variable 'write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/comm/net-utils/emacsbug.el:149: (make-local-variable 'mail-send-hook) c:\Hacking\XEmacs\xemacs-packages/comm/vm/vm-window.el:489: (make-local-variable 'vm-undisplay-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/libs/build/build.el:119: (set (make-local-variable 'auto-save-hook) c:\Hacking\XEmacs\xemacs-packages/libs/build/build.el:915: (set (make-local-variable 'auto-save-hook) c:\Hacking\XEmacs\xemacs-packages/libs/build-old/build.el:119: (set (make-local-variable 'auto-save-hook) c:\Hacking\XEmacs\xemacs-packages/libs/build-old/build.el:893: (set (make-local-variable 'auto-save-hook) c:\Hacking\XEmacs\xemacs-packages/libs/dired/dired.el:1604: (add-hook (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/libs/dired/dired.el:1608: (add-hook (make-local-variable 'post-command-hook) c:\Hacking\XEmacs\xemacs-packages/libs/edebug/auto-autoloads.el:12:(defcustom edebug-all-defs nil "*If non-nil, evaluation of any defining forms will instrument for Edebug.\nThis applies to `eval-defun', `eval-region', `eval-buffer', and\n`eval-current-buffer'. `eval-region' is also called by\n`eval-last-sexp', and `eval-print-last-sexp'.\n\nYou can use the command `edebug-all-defs' to toggle the value of this\nvariable. You may wish to make it local to each buffer with\n(make-local-variable 'edebug-all-defs) in your\n`emacs-lisp-mode-hook'." :type 'boolean :group 'edebug) c:\Hacking\XEmacs\xemacs-packages/libs/mail-lib/mail-abbrevs.el:160: (make-local-variable 'pre-abbrev-expand-hook) c:\Hacking\XEmacs\xemacs-packages/libs/mail-lib/mail-abbrevs.el:545: (make-local-variable 'pre-abbrev-expand-hook) c:\Hacking\XEmacs\xemacs-packages/libs/Sun/sun-eos-debugger-extra.el:314: (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/compile.el:952: (make-local-variable 'mouse-track-click-hook) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/edmacro.el:178: (set (make-local-variable 'edmacro-finish-hook) finish-hook) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/edmacro.el:179: (set (make-local-variable 'edmacro-store-hook) store-hook) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/outline.el:279: (make-local-variable 'change-major-mode-hook) c:\Hacking\XEmacs\xemacs-packages/lisp/build/build.el:119: (set (make-local-variable 'auto-save-hook) c:\Hacking\XEmacs\xemacs-packages/lisp/build/build.el:893: (set (make-local-variable 'auto-save-hook) c:\Hacking\XEmacs\xemacs-packages/lisp/mail-lib/mail-abbrevs.el:160: (make-local-variable 'pre-abbrev-expand-hook) c:\Hacking\XEmacs\xemacs-packages/lisp/mail-lib/mail-abbrevs.el:545: (make-local-variable 'pre-abbrev-expand-hook) c:\Hacking\XEmacs\xemacs-packages/lisp/prog-modes/make-mode.el:692: (make-local-variable 'local-write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/lisp/prog-modes/rexx-mode.el:420: (make-local-variable 'comment-indent-hook) c:\Hacking\XEmacs\xemacs-packages/oa/calc/macedit.el:635: (make-local-variable 'MacEdit-finish-hook) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/file-part.el:85: (make-local-variable 'write-contents-hooks) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/file-part.el:86: (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/file-part.el:109: (make-local-variable 'write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/file-part.el:110: (make-local-variable 'kill-buffer-hook) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/file-part.el:112: (make-local-variable 'first-change-hook) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/func-menu.el:1782: (make-local-variable 'post-command-hook) c:\Hacking\XEmacs\xemacs-packages/oa/sgml/sgml-mode.el:284: (make-local-variable 'skeleton-end-hook) c:\Hacking\XEmacs\xemacs-packages/oa/speedbar/dframe.el:353: (progn (make-local-variable 'temp-buffer-show-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/hexl.el:202: (make-local-variable 'hexl-mode-old-write-contents-hooks) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/hexl.el:204: (make-local-variable 'write-contents-hooks) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/whitespace-mode.el:441: (make-local-variable 'post-command-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:434: (make-local-variable 'mouse-track-down-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:435: (make-local-variable 'mouse-track-drag-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:436: (make-local-variable 'mouse-track-up-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:437: (make-local-variable 'mouse-track-drag-up-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:438: (make-local-variable 'mouse-track-click-hook) c:\Hacking\XEmacs\xemacs-packages/os/eterm/term.el:475: (make-local-variable 'term-command-hook) c:\Hacking\XEmacs\xemacs-packages/os/eterm/term.el:506: (make-local-variable 'term-exec-hook) c:\Hacking\XEmacs\xemacs-packages/os/os-utils/arc-mode.el:532: (make-local-variable 'local-write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/os/os-utils/arc-mode.el:846: (make-local-variable 'local-write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/os/os-utils/uncompress.el:82: (make-local-variable 'write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/os/view-process/view-process-xemacs.el:359: (make-local-variable 'mode-motion-hook) c:\Hacking\XEmacs\xemacs-packages/prog/jde/lisp/jde.el:655: (make-local-variable 'tags-table-format-hooks) c:\Hacking\XEmacs\xemacs-packages/prog/prog-modes/make-mode.el:692: (make-local-variable 'local-write-file-hooks) c:\Hacking\XEmacs\xemacs-packages/prog/prog-modes/rexx-mode.el:420: (make-local-variable 'comment-indent-hook) c:\Hacking\XEmacs\xemacs-packages/prog/sh-script/sh-script.el:776: (make-local-variable 'skeleton-end-hook) c:\Hacking\XEmacs\xemacs-packages/prog/vc/vc.el:1079: (make-local-variable 'vc-log-after-operation-hook) c:\Hacking\XEmacs\xemacs-packages/prog/vc/vc.el:1611: (make-local-variable 'ediff-quit-hook) c:\Hacking\XEmacs\xemacs-packages/prog/vc-cc/vc.el:844: (make-local-variable 'vc-log-after-operation-hook) c:\Hacking\XEmacs\xemacs-packages/prog/vhdl/vhdl-mode.el:4244: (make-local-variable 'after-save-hook) c:\Hacking\XEmacs\xemacs-packages/prog/vhdl/vhdl-mode.el:11341: (make-local-variable 'hs-minor-mode-hook) c:\Hacking\XEmacs\xemacs-packages/prog/vhdl/vhdl-mode.el:11808: (make-local-variable 'ps-print-hook) c:\Hacking\XEmacs\xemacs-packages/wp/auctex/tex.el:1560: (make-local-variable 'comment-indent-hook) igrep finished at Sun May 13 09:51:35 --=-=-= Content-Disposition: attachment; filename=igrep-mouse-track-click-hook.err cd c:\Hacking\XEmacs\xemacs-packages\ c:\cygwin\bin\find c:\Hacking\XEmacs\xemacs-packages -type d "(" -name RCS -o -name CVS -o -name SCCS ")" -prune -o -type f "!" -name "*~" "!" -name "*,v" "!" -name "s.*" -name "*.el" -print0 | xargs -0 -e egrep -n -e "mouse-track-click-hook" NUL Compilation started at Sun May 13 09:53:43 2001 +0200 (W. Europe Daylight Time) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/compile.el:952: (make-local-variable 'mouse-track-click-hook) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/compile.el:953: (add-hook 'mouse-track-click-hook 'compile-mouse-maybe-goto-error) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/ffap.el:77:;; (add-hook 'mouse-track-click-hook 'ffap-mouse-track-click) c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/ffap.el:1590: "A possible entry for `mouse-track-click-hook'. c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/ffap.el:1593:\(add-hook 'mouse-track-click-hook 'ffap-mouse-track-click\)" c:\Hacking\XEmacs\xemacs-packages/libs/xemacs-base/ffap.el:1698: ;; (add-hook 'mouse-track-click-hook 'ffap-mouse-track-click) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/foldout.el:533:(defun foldout-mouse-track-click-hook (event click-count) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/foldout.el:558: (add-hook 'mouse-track-click-hook c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/foldout.el:559: 'foldout-mouse-track-click-hook))) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/foldout.el:562: (add-hook 'mouse-track-click-hook c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/foldout.el:563: 'foldout-mouse-track-click-hook))) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/id-select.el:64:;; for the variable, mouse-track-click-hook, for how this is done.) A c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/id-select.el:94:;; (add-hook 'mouse-track-click-hook 'id-select-double-click-hook) c:\Hacking\XEmacs\xemacs-packages/oa/edit-utils/id-select.el:254: (add-hook 'mouse-track-click-hook 'id-select-double-click-hook) c:\Hacking\XEmacs\xemacs-packages/oa/speedbar/dframe.el:829: ;; Emacs only. XEmacs handles this via `mouse-track-click-hook'. c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:438: (make-local-variable 'mouse-track-click-hook) c:\Hacking\XEmacs\xemacs-packages/oa/text-modes/xpm-mode.el:443: (setq mouse-track-click-hook nil) igrep exited abnormally with code 123 at Sun May 13 09:56:36 --=-=-= -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-115 D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com --=-=-=-- From ben@666.com Sun May 13 07:10:48 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id HAA20265 for ; Sun, 13 May 2001 07:10:47 -0400 Received: (qmail 10368 invoked by alias); 13 May 2001 11:10:45 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 10353 invoked by uid 0); 13 May 2001 11:10:45 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 13 May 2001 11:10:45 -0000 Message-ID: <3AFE6C0A.FE4F934C@666.com> Date: Sun, 13 May 2001 04:12:10 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Aichner CC: XEmacs Review Mailing List , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian Aichner wrote: > > Hi All, I'd like to solicit your feedback on this issue. > > Yesterday I found the cause for mouse-track-insert not to work between > buffers, at least under native Windows, today I found more: > > buff-meu.el, compile.el, info.el all incorrectly make > `mouse-track-click-hook' local via `make-local-variable'. > > mouse-track-insert between buffers works fine until either of > C-x C-b (list-buffers), > M-x compile, or > C-h i (info) > are executed. > > According to documentation of `add-hook', `make-local-hook' should be > used for hook variables instead. > > Documentation of `make-local-hook' has a worrying, uninformative hint > about non-normal hooks, which will have to be changed one by one. > > Can anyone here elaborate on this hint? what make-local-hook and add-local-hook do in addition to calling `make-local-variable' is put in a `t' somewhere in the hook, which will cause the global hooks to be run as well. otherwise, you get *only* the local hooks run, which is obviously wrong. the thing is, the routine that calls the hook has to know about this `t' business. there are different routines out there to do this, and each one has to be modified. that's what the hint means. in point of fact, there are a number of standard routines `run-hook-with-args-till-success' and so on that implement common hook semantics, so most if not all hooks already works correctly with `make-local-hook'. mouse-track hooks have their own function to run the hook [mouse-track-run-hook], which also handles the `t' correctly. [although probably we should fix this to use a standard hook.] > > A few questions arise: > > 1. Does mouse-track-insert work between buffers under X, after running > any of the offenders above? > > 2. Should mouse-track-click-hook be used as a local hook by > buff-meu.el, compile.el, info.el? > > 3. Should all instances of > (make-local-variable A) > (add-hook A B) > be converted to > (make-local-hook A) > (add-hook A B) yes. remember that you need some special args in `add-hook' to actually get a local hook. i made a better function add-local-hook to do this, but it's 21.4 and up only. > > Here is what I found in core lisp: > > -------------------------------------------------------------------------------- > > igrep-make-local-variable--hook.errName: igrep-make-local-variable--hook.err > Type: Plain Text (text/plain) > > -------------------------------------------------------------------------------- > > This is what I found in xemacs-packages lisp: > > -------------------------------------------------------------------------------- > > igrep-make-local-variable--hook.errName: igrep-make-local-variable--hook.err > Type: Plain Text (text/plain) > > igrep-mouse-track-click-hook.errName: igrep-mouse-track-click-hook.err > Type: Plain Text (text/plain) > > -------------------------------------------------------------------------------- > > -- > Adrian Aichner Teradyne GmbH, European Design Center > Integra Test Division Telephone +49/89/41861(0)-208 > Dingolfinger Strasse 2 Fax +49/89/41861-115 > D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From nix@esperi.demon.co.uk Sun May 13 07:14:55 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA20363 for ; Sun, 13 May 2001 07:14:47 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id CAA21501; Sun, 13 May 2001 02:28:14 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id CAA31200; Sun, 13 May 2001 02:28:09 +0100 Sender: nix@esperi.demon.co.uk To: Hrvoje Niksic Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> <87y9s23xk8.fsf@loki.wkstn.nix> X-Emacs: it's like swatting a fly with a supernova. From: Nix Date: 13 May 2001 02:28:03 +0100 In-Reply-To: Message-ID: <87ofsy3un0.fsf@loki.wkstn.nix> Lines: 67 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On 13 May 2001, Hrvoje Niksic stipulated: > Additionally, in FSF Emacs, "no-conversion" means what XEmacs calls > "binary". Oh, great. :( > Good point. In general, one should be able to stack "coding systems", > e.g. a "gzip" coding system piped into a "NL detection coding system" > piped into a "charset detection coding system" (for people who need > that). Sort of like Streams? That would be very nice; it would obsolete big chunks of mailcrypt, jka-compr, uncompress... even term-mode's `term-emulate-terminal', come to think of it. In fact, probably by the time you've got that generic, `input filter' and `output filter' are better terms for this stackable thing than `coding system'. This is sort of a generalization both of coding systems and of the existing asynchronous subprocess filters; almost certainly both of these could be reimplemented in terms of the filter stack. (And maybe, even, my pet dream could come true, and enough of redisplay could be migrated into here to make the lack of Lisp-runnability within the C redisplay code a moot point...) Hmm. One question, actually. The Golden Rules of Redisplay (no GC, no Lisp); are they there because having Lisp touch the *_set variables while redisplay is running could be nasty? If so, why doesn't redisplay take a copy of these variables and work from that copy? (In fact, unless Lisp code *unsets* the *_set variables, I can't see how this could cause any problem... obviously I'm misunderstanding the reason for the Golden Rules.) I really would like a Lisp-mutable redisplay; the unmutability from Lisp of redisplay is one of my three great grouches about XEmacs. (The other grouches are: - the inflexibility of specifiers; you should be able to attach arbitrary Lisp predicates to them; maybe you can, but the docs for them are unclear enough that it's hard to tell... examples would be good ;) I should write some... - the way that XEmacs's C-side data hiding has spawned a million different set- and get- constructs and irritatingly over-opaque data structures. Things like e.g. keymaps should appear to the Lisp layer as directly Lisp-manipulable objects, so that `read' and `print' can work on them. It seems to me that symbol-value-magic symbols have allowed this for a long time, but obviously not, or it'd be implemented... I've got half- completed patches that exploit common-lisp style #x() syntax to do this, so you can set and update many opaque objects from the lisp reader, with the letter indicating the type of formerly opaque object, as in Common Lisp... if you want, I can clean them up (and they'll require a good bit of cleanup; the patches were initially a proof-of-concept, and clean they are not) and submit them. -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From Adrian.Aichner@t-online.de Sun May 13 08:57:21 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA22872; Sun, 13 May 2001 08:57:20 -0400 Received: from fwd03.sul.t-online.de by mailout02.sul.t-online.com with smtp id 14yvRN-0007Fe-00; Sun, 13 May 2001 14:57:41 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.63]) by fwd03.sul.t-online.com with esmtp id 14yvRP-0L4iPIC; Sun, 13 May 2001 14:57:43 +0200 To: Ben Wing Cc: Adrian Aichner , XEmacs Review Mailing List , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: <3AFE6C0A.FE4F934C@666.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 135 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Ben" == Ben Wing writes: Ben> Adrian Aichner wrote: >> >> Hi All, I'd like to solicit your feedback on this issue. >> >> Yesterday I found the cause for mouse-track-insert not to work between >> buffers, at least under native Windows, today I found more: >> >> buff-meu.el, compile.el, info.el all incorrectly make >> `mouse-track-click-hook' local via `make-local-variable'. >> >> mouse-track-insert between buffers works fine until either of >> C-x C-b (list-buffers), >> M-x compile, or >> C-h i (info) >> are executed. >> >> According to documentation of `add-hook', `make-local-hook' should be >> used for hook variables instead. >> >> Documentation of `make-local-hook' has a worrying, uninformative hint >> about non-normal hooks, which will have to be changed one by one. >> >> Can anyone here elaborate on this hint? Ben> what make-local-hook and add-local-hook do in addition to calling Ben> `make-local-variable' is put in a `t' somewhere in the hook, which will cause Ben> the global hooks to be run as well. otherwise, you get *only* the local hooks Ah, I read that in the docs. Ben> run, which is obviously wrong. the thing is, the routine that calls the hook Ben> has to know about this `t' business. there are different routines out there to Ben> do this, and each one has to be modified. that's what the hint means. in point Ben> of fact, there are a number of standard routines Ben> `run-hook-with-args-till-success' and so on that implement common hook Ben> semantics, so most if not all hooks already works correctly with Ben> `make-local-hook'. mouse-track hooks have their own function to run the hook Ah, so these are the "normal" hooks? So it's more like standard vs. non-standard hook implementation? Ben> [mouse-track-run-hook], which also handles the `t' correctly. [although probably Ben> we should fix this to use a standard hook.] Thanks for the details! Ben, I could not get correct behavior of mouse-track-insert between buffers, even when I make the hook local correctly in buff-menu.el. Do you also see this broken behavior? Should `Buffer-menu-maybe-mouse-select' work correctly as a local mouse-track-insert-click-hook? >> >> A few questions arise: >> >> 1. Does mouse-track-insert work between buffers under X, after running >> any of the offenders above? >> >> 2. Should mouse-track-click-hook be used as a local hook by >> buff-meu.el, compile.el, info.el? >> >> 3. Should all instances of >> (make-local-variable A) >> (add-hook A B) >> be converted to >> (make-local-hook A) >> (add-hook A B) Ben> yes. remember that you need some special args in `add-hook' to actually get a Ben> local hook. Yep, I played with this yesterday, also tried to append (instead of prepend) the hook, to no avail. I had to add `Buffer-menu-maybe-mouse-select' to the global hook value of mouse-track-insert-click-hook to get correct mouse-track-insert behavior. Do you understand this? Ben> i made a better function add-local-hook to do this, but it's 21.4 and up only. OK, I will convert to arguments: (hook function &optional append local) semantics for compatibility with 21.1, if we come to an agreement what should be done. Best regards, Adrian >> >> Here is what I found in core lisp: >> >> -------------------------------------------------------------------------------- >> >> igrep-make-local-variable--hook.errName: igrep-make-local-variable--hook.err >> Type: Plain Text (text/plain) >> >> -------------------------------------------------------------------------------- >> >> This is what I found in xemacs-packages lisp: >> >> -------------------------------------------------------------------------------- >> >> igrep-make-local-variable--hook.errName: igrep-make-local-variable--hook.err >> Type: Plain Text (text/plain) >> >> igrep-mouse-track-click-hook.errName: igrep-mouse-track-click-hook.err >> Type: Plain Text (text/plain) >> >> -------------------------------------------------------------------------------- >> >> -- >> Adrian Aichner Teradyne GmbH, European Design Center >> Integra Test Division Telephone +49/89/41861(0)-208 >> Dingolfinger Strasse 2 Fax +49/89/41861-115 >> D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com Ben> -- Ben> ben Ben> I'm sometimes slow in getting around to reading my mail, so if you Ben> want to reach me faster, call 520-661-6661. Ben> See http://www.666.com/ben/chronic-pain/ for the hell I've been Ben> through. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From hniksic@arsdigita.com Sun May 13 09:14:23 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA23559 for ; Sun, 13 May 2001 09:14:22 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yvhT-0000ak-00; Sun, 13 May 2001 15:14:19 +0200 Sender: hniksic@florida.arsdigita.de To: Nix Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> <87y9s23xk8.fsf@loki.wkstn.nix> <87ofsy3un0.fsf@loki.wkstn.nix> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 13 May 2001 15:14:19 +0200 In-Reply-To: <87ofsy3un0.fsf@loki.wkstn.nix> (Nix's message of "13 May 2001 02:28:03 +0100") Message-ID: Lines: 80 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nix writes: > > Good point. In general, one should be able to stack "coding > > systems", e.g. a "gzip" coding system piped into a "NL detection > > coding system" piped into a "charset detection coding system" (for > > people who need that). > > Sort of like Streams? Right. XEmacs internally has very powerful Lstreams, which are capable of "stacking", but we have yet to come up with a good interface for exposing them to Lisp level. > That would be very nice; it would obsolete big chunks of mailcrypt, > jka-compr, uncompress... even term-mode's `term-emulate-terminal', > come to think of it. In fact, probably by the time you've got that > generic, `input filter' and `output filter' are better terms for > this stackable thing than `coding system'. Exactly. A form of "coding system" would probably remain, because when you finally import the bytes into XEmacs, you have to convert them to chars of a certain charset. At this point the coding systems would still be useful. > This is sort of a generalization both of coding systems and of the > existing asynchronous subprocess filters; almost certainly both of > these could be reimplemented in terms of the filter stack. I'm not sure I would generalize to that point, but perhaps it's possible. > Hmm. One question, actually. The Golden Rules of Redisplay (no GC, > no Lisp); are they there because having Lisp touch the *_set > variables while redisplay is running could be nasty? I'm not sure about the "no GC" rule, but the no Lisp rule is there because of efficiency and robustness. Efficiency means that Lisp code might be too expensive to call within redisplay. Robustness means that there is no good way to handle Lisp errors while you're in redisplay "critical section". It's just too dangerous. There have been discussions about how to circumvent the Golden Rules. One of them is to allow a safe subset of Lisp to be run, sort of like CCL is currently allowed. > - the inflexibility of specifiers; you should be able to attach > arbitrary Lisp predicates to them; maybe you can, but the docs for > them are unclear enough that it's hard to tell... examples would be > good ;) I should write some... You can, to an extent. But you cannot make them completely dynamic. Remember that a) specifiers are cached, and b) specifiers are resolved from within redisplay. The Golden Rules strike back. :-) > - the way that XEmacs's C-side data hiding has spawned a million > different set- and get- constructs and irritatingly over-opaque data > structures. Things like e.g. keymaps should appear to the Lisp layer > as directly Lisp-manipulable objects, so that `read' and `print' can > work on them. We can discuss that. I have personally made steps in that direction by implemented ways to create arbitrary events and adding read/print syntax to hash tables. Could you explain why you need a read/print syntax for keymaps? Speaking of keymaps, remember that they are not opaque objects because of our perversion. When you change key definitions, the keymap code actually recalculates internal caches that make operations like `where-is' fast, which is extremely important for menus. > I've got half- completed patches that exploit common-lisp style #x() > syntax to do this, so you can set and update many opaque objects > from the lisp reader, with the letter indicating the type of formerly > opaque object, as in Common Lisp... if you want, I can clean them up > (and they'll require a good bit of cleanup; the patches were initially > a proof-of-concept, and clean they are not) and submit them. I would like to know more about the changes you envisioned. For instance, could you post a Lisp code snippet of how updating an opaque object from the reader would work with your patches applied. From hniksic@arsdigita.com Sun May 13 09:18:07 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA23685; Sun, 13 May 2001 09:18:06 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yvl8-0000bV-00; Sun, 13 May 2001 15:18:06 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Patch Reviews , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 13 May 2001 15:18:06 +0200 In-Reply-To: (Adrian.Aichner@t-online.de's message of "13 May 2001 12:10:56 +0200") Message-ID: Lines: 13 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian.Aichner@t-online.de (Adrian Aichner) writes: > Documentation of `make-local-hook' has a worrying, uninformative hint > about non-normal hooks, which will have to be changed one by one. It is safe to use `make-local-hook' with mouse hooks; I have personally added support for that. Take a look at `mouse-track-run-hook'. 1997-12-12 Hrvoje Niksic * mouse.el (mouse-track-run-hook): Understand `make-local-hook' convention. From alexm@hsys.msk.ru Sun May 13 09:36:11 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA24269 for ; Sun, 13 May 2001 09:36:10 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp132-207.dialup.mtu-net.ru [62.118.132.207]) by mtu.ru (Postfix) with ESMTP id E7E2A733F for ; Sun, 13 May 2001 17:36:07 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 2432 invoked by uid 1000); 13 May 2001 13:33:35 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15102.36143.240455.718548@tyranny.hsys.msk.ru> Date: Sun, 13 May 2001 17:33:35 +0400 (MSD) To: xemacs-beta@xemacs.org Cc: morozov@novosoft.ru Subject: order of ~/.xemacs/init.el and ~/.xemacs/custom.el X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid I retransmit a kind of bug report posted to local newsgroup: Suppose there is a (desktop-read) in init.el, and (custom-set-variables '(user-mail-address "morozov@novosoft.ru")), in custom.el. Now if desktop being read contains .html file then html-mode asks again and again: "Your mail address: alex@localhost" or something like that, because it is not yet customized. Surely one can move (setq user-mail-address "") to init.el, before (desktop-read), but there must be a more generic way to address that issue, what do you think? There probably exists a reason not to simply swap the order of execution of init.el and custom.el... Probably there could appear something like "phase3.el"? --alexm From Adrian.Aichner@t-online.de Sun May 13 10:10:22 2001 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA25286; Sun, 13 May 2001 10:10:21 -0400 Received: from fwd06.sul.t-online.de by mailout05.sul.t-online.com with smtp id 14ywZt-0006pF-05; Sun, 13 May 2001 16:10:33 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.82]) by fwd06.sul.t-online.com with esmtp id 14ywZu-134ocKC; Sun, 13 May 2001 16:10:34 +0200 To: Hrvoje Niksic Cc: XEmacs Patch Reviews , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Adrian.Aichner@t-online.de (Adrian Aichner) writes: >> Documentation of `make-local-hook' has a worrying, uninformative hint >> about non-normal hooks, which will have to be changed one by one. Hrvoje> It is safe to use `make-local-hook' with mouse hooks; I Hrvoje> have personally added support for that. Take a look at Hrvoje> `mouse-track-run-hook'. Hi Hrvoje, does mouse-track-insert work for you between buffers? Does it work after you do C-x C-b (list-buffers) ? Adrian Hrvoje> 1997-12-12 Hrvoje Niksic Hrvoje> * mouse.el (mouse-track-run-hook): Understand `make-local-hook' Hrvoje> convention. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From hniksic@arsdigita.com Sun May 13 10:40:48 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA26349; Sun, 13 May 2001 10:40:47 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yx37-0000xq-00; Sun, 13 May 2001 16:40:45 +0200 Sender: hniksic@florida.arsdigita.de To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: XEmacs Patch Reviews , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 13 May 2001 16:40:45 +0200 In-Reply-To: (Adrian.Aichner@t-online.de's message of "13 May 2001 16:10:04 +0200") Message-ID: Lines: 5 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian.Aichner@t-online.de (Adrian Aichner) writes: > does mouse-track-insert work for you between buffers? It doesn't. From ben@666.com Sun May 13 11:36:17 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id LAA27948 for ; Sun, 13 May 2001 11:36:17 -0400 Received: (qmail 37998 invoked by alias); 13 May 2001 15:36:16 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 37972 invoked by uid 0); 13 May 2001 15:36:15 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 13 May 2001 15:36:15 -0000 Message-ID: <3AFEAA45.15261CA1@666.com> Date: Sun, 13 May 2001 08:37:41 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: Nix , xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> <87y9s23xk8.fsf@loki.wkstn.nix> <87ofsy3un0.fsf@loki.wkstn.nix> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hrvoje Niksic wrote: > > Nix writes: > > > > Good point. In general, one should be able to stack "coding > > > systems", e.g. a "gzip" coding system piped into a "NL detection > > > coding system" piped into a "charset detection coding system" (for > > > people who need that). > > > > Sort of like Streams? > > Right. XEmacs internally has very powerful Lstreams, which are > capable of "stacking", but we have yet to come up with a good > interface for exposing them to Lisp level. this is half-implemented already in my latest mule ws. i created a "chain" coding system that lets you chain more than one coding system together, and use it to implement mswindows-unicode currently [mswindows-multibyte -> mswindows-multibyte-to-unicode], although eventually this needs to be switched. mswindows-multibyte-to-unicode is thus the first ever coding system that translates between something other than byte->char or char->byte [it's byte->byte]. i need to add some coding system methods to indicate what's at each end of the coding systems, so that incompatible kinds don't get chained together. file-coding is also substantially rewritten so that there are coding-system methods -- i.e. nice abstraction instead of nasty switch statements. not quite done though. > > > That would be very nice; it would obsolete big chunks of mailcrypt, > > jka-compr, uncompress... even term-mode's `term-emulate-terminal', > > come to think of it. In fact, probably by the time you've got that > > generic, `input filter' and `output filter' are better terms for > > this stackable thing than `coding system'. > > Exactly. A form of "coding system" would probably remain, because > when you finally import the bytes into XEmacs, you have to convert > them to chars of a certain charset. At this point the coding systems > would still be useful. > > > This is sort of a generalization both of coding systems and of the > > existing asynchronous subprocess filters; almost certainly both of > > these could be reimplemented in terms of the filter stack. > > I'm not sure I would generalize to that point, but perhaps it's > possible. > > > Hmm. One question, actually. The Golden Rules of Redisplay (no GC, > > no Lisp); are they there because having Lisp touch the *_set > > variables while redisplay is running could be nasty? > > I'm not sure about the "no GC" rule, but the no Lisp rule is there > because of efficiency and robustness. Efficiency means that Lisp code > might be too expensive to call within redisplay. Robustness means > that there is no good way to handle Lisp errors while you're in > redisplay "critical section". It's just too dangerous. in yet another workspace of mine [rotting away, sadly], i completely rewrote the way that errors are trapped internally, so that it's now actually possible to safely run lisp inside of redisplay. in some lifetime i might get around to finishing this workspace up and merging it. [it also implements a separate stderr stream for processes.] > > There have been discussions about how to circumvent the Golden Rules. > One of them is to allow a safe subset of Lisp to be run, sort of like > CCL is currently allowed. > > > - the inflexibility of specifiers; you should be able to attach > > arbitrary Lisp predicates to them; maybe you can, but the docs for > > them are unclear enough that it's hard to tell... examples would be > > good ;) I should write some... > > You can, to an extent. But you cannot make them completely dynamic. > Remember that a) specifiers are cached, and b) specifiers are resolved > from within redisplay. The Golden Rules strike back. :-) > > > - the way that XEmacs's C-side data hiding has spawned a million > > different set- and get- constructs and irritatingly over-opaque data > > structures. Things like e.g. keymaps should appear to the Lisp layer > > as directly Lisp-manipulable objects, so that `read' and `print' can > > work on them. > > We can discuss that. I have personally made steps in that direction > by implemented ways to create arbitrary events and adding read/print > syntax to hash tables. Could you explain why you need a read/print > syntax for keymaps? > > Speaking of keymaps, remember that they are not opaque objects because > of our perversion. When you change key definitions, the keymap code > actually recalculates internal caches that make operations like > `where-is' fast, which is extremely important for menus. > > > I've got half- completed patches that exploit common-lisp style #x() > > syntax to do this, so you can set and update many opaque objects > > from the lisp reader, with the letter indicating the type of formerly > > opaque object, as in Common Lisp... if you want, I can clean them up > > (and they'll require a good bit of cleanup; the patches were initially > > a proof-of-concept, and clean they are not) and submit them. > > I would like to know more about the changes you envisioned. For > instance, could you post a Lisp code snippet of how updating an opaque > object from the reader would work with your patches applied. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From alexm@hsys.msk.ru Sun May 13 11:49:29 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA28526 for ; Sun, 13 May 2001 11:49:28 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp98-121.dialup.mtu-net.ru [212.188.98.121]) by mtu.ru (Postfix) with ESMTP id AF4F5734A for ; Sun, 13 May 2001 19:49:25 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 3100 invoked by uid 1000); 13 May 2001 15:48:09 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Alexey Mahotkin To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: 'ascii-character property broken (Was (set-xkb-cyrillic-charset) References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.42878.842212.851171@tyranny.hsys.msk.ru> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 13 May 2001 19:48:08 +0400 In-Reply-To: Alexey Mahotkin's message of "Thu, 10 May 2001 00:24:30 +0400 (MSD)" Message-ID: <874rup2qtj.fsf@tyranny.hsys.msk.ru> Lines: 71 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "AM" == Alexey Mahotkin writes: AM> Details (substitute actual characters instead of (0xFF) and (0xCA)): AM> (put 'Cyrillic_HARDSIGN 'ascii-character ?\xff) ===> ?(0xFF) AM> (get 'Cyrillic_HARDSIGN 'ascii-character) ===> ?(0xFF) AM> But when I try to type that character, it shows AM> (0xCA) AM> and after that: AM> (get 'Cyrillic_HARDSIGN 'ascii-character) ===> ?(0xCA) AM> setting it again with `put' yields the same results. The only place where there is (put 'ascii-character x_keysym_to_character()) with hardcoded 8859-5 value is in maybe_define_x_key_as_self_inserting_character. I've used gdb, set breakpoint to maybe_define_x_key_as_self_inserting_character if (keysym == 0x6ff) (0x6ff == 1791 == Cyrillic_HARDSIGN) Every time I type HARDSIGN, breakpoint appears, with the following backtrace: (gdb) bt #0 maybe_define_x_key_as_self_inserting_character (keysym=1791, symbol=138277596) at /var/src/xemacs-21.4.1/src/event-Xt.c:188 #1 0x816531a in x_reset_key_mapping (d=0x8239058) at /var/src/xemacs-21.4.1/src/event-Xt.c:356 #2 0x81699e0 in emacs_Xt_mapping_action (w=0x84463c8, event=0xbffff62c) at /var/src/xemacs-21.4.1/src/event-Xt.c:864 #3 0x400fa683 in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 #4 0x400faaeb in _XtMatchAtom () from /usr/X11R6/lib/libXt.so.6 #5 0x400fb004 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6 #6 0x400fb25d in _XtTraverseStateTree () from /usr/X11R6/lib/libXt.so.6 #7 0x400ce27d in XtCallCallbackList () from /usr/X11R6/lib/libXt.so.6 #8 0x400e3a4b in _XtRefreshMapping () from /usr/X11R6/lib/libXt.so.6 #9 0x400d96de in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #10 0x400e3f51 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #11 0x8168bb9 in emacs_Xt_next_event (emacs_event=0x840f970) at /var/src/xemacs-21.4.1/src/event-Xt.c:2703 #12 0x80d08ee in event_stream_next_event (event=0x840f970) at /var/src/xemacs-21.4.1/src/event-stream.c:499 #13 0x80d1a4c in next_event_internal (target_event=138475888, allow_queued=1) at /var/src/xemacs-21.4.1/src/event-stream.c:1959 #14 0x80d1de7 in Fnext_event (event=138475888, prompt=136251236) at /var/src/xemacs-21.4.1/src/event-stream.c:2178 #15 0x8091143 in Fcommand_loop_1 () at /var/src/xemacs-21.4.1/src/cmdloop.c:574 #16 0x80913bd in command_loop_1 (dummy=136251236) at /var/src/xemacs-21.4.1/src/cmdloop.c:494 . . . hope that next lines are irrelevant . . . As you see, there is x_reset_key_mapping() every time I type a Cyrillic character. I do not think it is feature.... Any thoughts? I have XFree 3.6.6 (-11potato, I'm running Debian). Thank you, --alexm From alexm@hsys.msk.ru Sun May 13 12:05:51 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA29326 for ; Sun, 13 May 2001 12:05:41 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp139-3.dialup.mtu-net.ru [62.118.139.3]) by mtu.ru (Postfix) with ESMTP id EB8987318 for ; Sun, 13 May 2001 20:05:35 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 650 invoked by uid 1000); 13 May 2001 16:04:40 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Alexey Mahotkin To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: 'ascii-character property broken (Was (set-xkb-cyrillic-charset) Keywords: 913414472 References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.42878.842212.851171@tyranny.hsys.msk.ru> <874rup2qtj.fsf@tyranny.hsys.msk.ru> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 13 May 2001 20:04:40 +0400 In-Reply-To: Alexey Mahotkin's message of "13 May 2001 19:48:08 +0400" Message-ID: <878zk1kzfr.fsf@tyranny.hsys.msk.ru> Lines: 49 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "AM" == Alexey Mahotkin writes: AM> (gdb) bt #0 maybe_define_x_key_as_self_inserting_character AM> (keysym=1791, symbol=138277596) at AM> /var/src/xemacs-21.4.1/src/event-Xt.c:188 #1 0x816531a in AM> x_reset_key_mapping (d=0x8239058) at AM> /var/src/xemacs-21.4.1/src/event-Xt.c:356 #2 0x81699e0 in AM> emacs_Xt_mapping_action (w=0x84463c8, event=0xbffff62c) at AM> /var/src/xemacs-21.4.1/src/event-Xt.c:864 #3 0x400fa683 in _XtMatchAtom AM> () from /usr/X11R6/lib/libXt.so.6 AM> As you see, there is x_reset_key_mapping() every time I type a Cyrillic AM> character. I do not think it is feature.... Any thoughts? Here is how the Cyrillic_HARDSIGN (Shift + Cyrillic_hardsign) handled by xev: MappingNotify event, serial 27, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 127 MappingNotify event, serial 27, synthetic NO, window 0x0, request MappingModifier, first_keycode 216, count 26 KeyPress event, serial 28, synthetic NO, window 0x4800001, root 0x26, subw 0x0, time 1927226739, (197,-96), root:(325,53), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 characters: "" KeyPress event, serial 28, synthetic NO, window 0x4800001, root 0x26, subw 0x0, time 1927227077, (197,-96), root:(325,53), state 0x1, keycode 35 (keysym 0x6ff, Cyrillic_HARDSIGN), same_screen YES, XLookupString gives 0 characters: "" KeyRelease event, serial 28, synthetic NO, window 0x4800001, root 0x26, subw 0x0, time 1927227119, (197,-96), root:(325,53), state 0x1, keycode 35 (keysym 0x6ff, Cyrillic_HARDSIGN), same_screen YES, XLookupString gives 0 characters: "" KeyRelease event, serial 28, synthetic NO, window 0x4800001, root 0x26, subw 0x0, time 1927227139, (197,-96), root:(325,53), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 characters: "" I do not know what is MappingNotify and is there really a need to x_reset_key_mapping() every time it appears... --alexm From hniksic@arsdigita.com Sun May 13 12:21:38 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA30837 for ; Sun, 13 May 2001 12:21:37 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14yycA-0001HC-00; Sun, 13 May 2001 18:21:02 +0200 Sender: hniksic@florida.arsdigita.de To: Ben Wing Cc: Nix , xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> <87y9s23xk8.fsf@loki.wkstn.nix> <87ofsy3un0.fsf@loki.wkstn.nix> <3AFEAA45.15261CA1@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 13 May 2001 18:21:01 +0200 In-Reply-To: <3AFEAA45.15261CA1@666.com> (Ben Wing's message of "Sun, 13 May 2001 08:37:41 -0700") Message-ID: Lines: 28 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > > Right. XEmacs internally has very powerful Lstreams, which are > > capable of "stacking", but we have yet to come up with a good > > interface for exposing them to Lisp level. > > this is half-implemented already in my latest mule ws. > > i created a "chain" coding system that lets you chain more than one > coding system together, [...] > mswindows-multibyte-to-unicode is thus the first ever coding system that > translates between something other than byte->char or char->byte [it's > byte->byte]. i need to add some coding system methods to indicate what's at > each end of the coding systems, so that incompatible kinds don't get > chained together. This concern has been raised by Olivier Galibert: current coding systems conceptually convert bytes to characters or vice versa. I can imagine existence of three kinds of coding systems: x. byte<->byte, such as `gzip' or `uuencode' y. byte<->char (char<->byte in the other direction), such as `utf8' z. char<->char, such as newline-hide-cr One coding system of type Y would be mandatory, but otherwise combinations such as XXYZZZ (or ZZZYXX in the other dirction) would be possible. From alexm@hsys.msk.ru Sun May 13 13:11:17 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA14792 for ; Sun, 13 May 2001 13:11:12 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.5) with ESMTP id 7905501 for xemacs-beta@xemacs.org; Sun, 13 May 2001 21:11:05 +0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp139-16.dialup.mtu-net.ru [62.118.139.16]) by mtu.ru (Postfix) with ESMTP id 7483E7325 for ; Sun, 13 May 2001 21:11:10 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 2151 invoked by uid 1000); 13 May 2001 17:08:49 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Alexey Mahotkin To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: 'ascii-character property broken (Was (set-xkb-cyrillic-charset) Keywords: 913414472 References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15097.8052.613253.195665@gargle.gargle.HOWL> <15097.14106.248066.722346@turnbull.sk.tsukuba.ac.jp> <15097.42878.842212.851171@tyranny.hsys.msk.ru> <874rup2qtj.fsf@tyranny.hsys.msk.ru> <878zk1kzfr.fsf@tyranny.hsys.msk.ru> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 13 May 2001 21:08:49 +0400 In-Reply-To: Alexey Mahotkin's message of "13 May 2001 20:04:40 +0400" Message-ID: <87zochjhwe.fsf@tyranny.hsys.msk.ru> Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "AM" == Alexey Mahotkin writes: >>>>> "AM" == Alexey Mahotkin writes: AM> (gdb) bt #0 maybe_define_x_key_as_self_inserting_character AM> (keysym=1791, symbol=138277596) at AM> /var/src/xemacs-21.4.1/src/event-Xt.c:188 #1 0x816531a in Sorry, it currently seems like I'm using broken language switcher (xrus). I'm investigating the issue... Please hold the line :) --alexm From baz@barriebremner.com Sun May 13 13:20:29 2001 Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA15290 for ; Sun, 13 May 2001 13:20:28 -0400 Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14yzXg-0006SK-00 for xemacs-beta@xemacs.org; Sun, 13 May 2001 18:20:28 +0100 Received: from modem-88.ar-sakalthur.dialup.pol.co.uk ([62.136.127.216] helo=flux.localdomain) by mail17.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14yzXf-0002iV-00 for xemacs-beta@xemacs.org; Sun, 13 May 2001 18:20:27 +0100 Received: (qmail 16392 invoked by uid 500); 13 May 2001 17:20:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15102.49750.703425.459781@flux.localdomain> Date: Sun, 13 May 2001 18:20:22 +0100 From: Barrie Bremner To: xemacs-beta@xemacs.org Subject: 21.5-b1 "anise" crashed whilst using VM - what now? X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Uptime: 1 week 1 day 48 minutes Sorry, I'm a bit useless, being a non programmer (one day I'll learn more than just printf "Hello World"; :-), however when things go pear shaped with the Beta(s) what are the commands to be run, what information is required, and in which format should it be submitted? Better still is there a document in place which covers all this? (I'd offer to write one if not, but I clearly know nothing :-) 21.5-b1 died on me without a peep whilst I was using VM - just as I hit the space bar for the next message. Cheers. Baz. P.S. Yeap, guess I shouldn't even be looking at betas, but I'd like to help some how! -- Barrie J. Bremner OpenPGP public key ID: 5164F553 baz [at] barriebremner.com http://barriebremner.com/ From Adrian.Aichner@t-online.de Sun May 13 13:56:59 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA16887 for ; Sun, 13 May 2001 13:56:58 -0400 Received: from fwd03.sul.t-online.de by mailout06.sul.t-online.com with smtp id 14z06q-0006wJ-0H; Sun, 13 May 2001 19:56:48 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.227]) by fwd03.sul.t-online.com with esmtp id 14z077-0TShtIC; Sun, 13 May 2001 19:57:05 +0200 To: Barrie Bremner Cc: xemacs-beta@xemacs.org Subject: Re: 21.5-b1 "anise" crashed whilst using VM - what now? References: <15102.49750.703425.459781@flux.localdomain> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 53 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Barrie" == Barrie Bremner writes: Barrie> Sorry, Barrie> I'm a bit useless, being a non programmer (one day I'll Barrie> learn more than just printf "Hello World"; :-), however Barrie> when things go pear shaped with the Beta(s) what are the Barrie> commands to be run, what information is required, and in Barrie> which format should it be submitted? Barrie> Better still is there a document in place which covers all Barrie> this? (I'd offer to write one if not, but I clearly know Barrie> nothing :-) Barrie> 21.5-b1 died on me without a peep whilst I was using VM - Barrie> just as I hit the space bar for the next message. Hi Barrie, see under ** Reporting Problems in C-h B (describe-beta) Did you get a stack backtrace? If yes, send us that please. You'll need to compile XEmacs with -g so that the stack backtrace contains useful symbolic information. Hope this helps, Adrian Barrie> Cheers. Barrie> Baz. Barrie> P.S. Yeap, guess I shouldn't even be looking at betas, but I'd like to Barrie> help some how! Barrie> -- Barrie> Barrie J. Bremner OpenPGP public key ID: 5164F553 Barrie> baz [at] barriebremner.com http://barriebremner.com/ -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From karlheg@hegbloom.net Sun May 13 15:57:39 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA20643 for ; Sun, 13 May 2001 15:57:38 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4DJvam6006940 for ; Sun, 13 May 2001 12:57:36 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4DJvaGV006937; Sun, 13 May 2001 12:57:36 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: [etc/xemacs-ja.1] Shouldn't it be named "xemacs.ja.1"? From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 13 May 2001 12:57:36 -0700 Message-ID: <874rupxbrj.fsf@bittersweet.intra.hegbloom.net> Lines: 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "dh_installman" looks for man pages with names formed like "xemacs.ja.1" to find non-english man pages so it can install them in the right location; eg: /usr/share/man/ja/man1. Isn't that a pretty standard naming convention? Shouldn't that man page be renamed? (perhaps copy the ,v in CVS to the new name, then cvs remove the old one to preserve history) From baz@barriebremner.com Sun May 13 15:58:07 2001 Received: from cmailg7.svr.pol.co.uk (cmailg7.svr.pol.co.uk [195.92.195.177]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA20669 for ; Sun, 13 May 2001 15:58:06 -0400 Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by cmailg7.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14z20D-0007n2-00 for xemacs-beta@xemacs.org; Sun, 13 May 2001 20:58:05 +0100 Received: from modem-56.naso-tang.dialup.pol.co.uk ([62.137.41.56] helo=flux.localdomain) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14z207-0002lp-00 for xemacs-beta@xemacs.org; Sun, 13 May 2001 20:57:59 +0100 Received: (qmail 17062 invoked by uid 500); 13 May 2001 19:57:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15102.59202.104536.906705@flux.localdomain> Date: Sun, 13 May 2001 20:57:54 +0100 From: Barrie Bremner To: xemacs-beta@xemacs.org Subject: Back trace of 21.5-b1 "anise" crash X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Uptime: 1 week 1 day 3 hours 27 minutes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id PAA20669 Hi all, This crash occured whilst using VM 6.92 under anise - hit space bar for next message, and XEmacs died. Here's what the coredump gives, again excuse me if this isn't quite right. Newbie alert! [baz@flux baz]$ gdb /usr/local/bin/xemacs core-anise-with-vm GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/bin/xemacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libXaw.so.7...done. Loaded symbols for /usr/X11R6/lib/libXaw.so.7 Reading symbols from /usr/lib/libtiff.so.3...done. Loaded symbols for /usr/lib/libtiff.so.3 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libdb-3.1.so...done. Loaded symbols for /lib/libdb-3.1.so Reading symbols from /usr/lib/libgpm.so.1...done. Loaded symbols for /usr/lib/libgpm.so.1 Reading symbols from /usr/lib/libncurses.so.5...done. Loaded symbols for /usr/lib/libncurses.so.5 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_nisplus.so.2...done. Loaded symbols for /lib/libnss_nisplus.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 #0 0x403c8801 in __kill () from /lib/i686/libc.so.6 (gdb) where #0 0x403c8801 in __kill () from /lib/i686/libc.so.6 #1 0x080b453b in fatal_error_signal (sig=11) at emacs.c:535 #2 #3 0x080911b3 in bytecode_arithop (obj1=25, obj2=0, opcode=Bplus) at bytecode.c:387 #4 0x080921e8 in execute_optimized_program (program=0x86c36c0 "Ã\n\t\b#Ä\n\t\b#\\\207!", stack_depth=5, constants_data=0x8366a78) at bytecode.c:1057 #5 0x0809166e in funcall_compiled_function (fun=137756060, nargs=1, args=0xbfffdfa0) at bytecode.c:518 #6 0x080bc496 in Ffuncall (nargs=2, args=0xbfffdf9c) at eval.c:3563 #7 0x08091a77 in execute_optimized_program (program=0x86c3628 "ÃÄ!«9Ä\t!Å\032\211\030\211\022\211@ÆÇ!¥ \210\nA\211\022\211@ÈÇ!¥ \210\nA\211\022\211@ÆÇ!¥ \210\nA\211\022\211@ÈÇ!¥ \210\b*\207É\t!\207tio!", stack_depth=5, constants_data=0x86c7db0) at bytecode.c:746 #8 0x0809166e in funcall_compiled_function (fun=141317476, nargs=1, args=0xbfffe11c) at bytecode.c:518 #9 0x080bc496 in Ffuncall (nargs=2, args=0xbfffe118) at eval.c:3563 #10 0x0811c080 in mapcar1 (leni=2, vals=0xbfffe170, function=140624652, sequence=144796916) at fns.c:2961 #11 0x0811c40a in Fmapcar (function=140624652, sequence=144796916) at fns.c:3067 #12 0x080bc386 in Ffuncall (nargs=3, args=0xbfffe254) at eval.c:3528 #13 0x08091a77 in execute_optimized_program ( program=0x86c34c8 "Æ\211\211\211\211\211\211\036\017\031\e\032\034\035\030ÇÈÉ \"\020\bA«{\b\025\rA«÷\rA\024Ê\r@!\022Ê\f@!\023\n@\013@U­\bË\n8Ë\0138U\021\nA@\013A@U­\bÌ\n8Ì\0138U\026\017\t¬\013\016\017¬\a\rA\211\025ªÃ\t«\b\r@@Í=¬\f\016\017«\026\r@@Î=«\017\r@\f@C¤\210\r\fA¡\210ª\237\r\t«\004ͪ\002Î\r@\f@E \210\r\fA¡\210ª\211\b@.\a\207alisA", stack_depth=8, constants_data=0x86c5260) at bytecode.c:746 #14 0x0809166e in funcall_compiled_function (fun=141204268, nargs=0, args=0xbfffe3d8) at bytecode.c:518 #15 0x080bc496 in Ffuncall (nargs=1, args=0xbfffe3d4) at eval.c:3563 #16 0x08091a77 in execute_optimized_program (program=0x86c33e0 "\n¬\tÆ\f!\022Ç\f!\021\r¬\rÈ \025Ç\r!\020Æ\r!\026\017É\e\f@§«>\r@§\205­", stack_depth=7, constants_data=0x86c7c68) at bytecode.c:746 #17 0x0809166e in funcall_compiled_function (fun=141317140, nargs=3, args=0xbfffe548) at bytecode.c:518 #18 0x080bc496 in Ffuncall (nargs=4, args=0xbfffe544) at eval.c:3563 #19 0x08091a77 in execute_optimized_program (program=0x86c3278 "Æ\t!Ç\t!È\035\036\030\036\031\016\035\203£", stack_depth=9, constants_data=0x86c52b8) at bytecode.c:746 #20 0x0809166e in funcall_compiled_function (fun=141204296, nargs=2, args=0xbfffe6c8) at bytecode.c:518 #21 0x080bc496 in Ffuncall (nargs=3, args=0xbfffe6c4) at eval.c:3563 #22 0x08091a77 in execute_optimized_program ( program=0x86c31e8 "Æ Ç\211\211\211\211\034\035\030\e\036\025\036\026\016\023@\020\016\023A@\025\016\024«\006\n¬\003È\022\n«'Ç\031\nS\r8\211\024¬\006ÉÊ\n\"\210Ë\f@\016\024\"\021Ì\fA@\t\"\210ÍÎ\f8\t\")ª0Ï\b!\210Ð \237\023Ñ\216\r­\"Ò\013@!\210Ë\r@@!\210Ì\r@A@!\210ÍÎ\r@8!\210\rA\025\013A\023ªÝ).\006\207é", stack_depth=7, constants_data=0x86c51a8) at bytecode.c:746 #23 0x0809166e in funcall_compiled_function (fun=141204184, nargs=2, args=0xbfffe838) at bytecode.c:518 #24 0x080bc496 in Ffuncall (nargs=3, args=0xbfffe834) at eval.c:3563 #25 0x08091a77 in execute_optimized_program ( program=0xbfffe8c0 "\016)¬\006ÆÇÈ\"\210ÉÊË È\211\211\211\211\211\e\036#\036\"\034\036$\036%\036*\032\031\016&«\023\013¬\020\016&@\016'\236\023\016&A\211\026&¬ï\013¬\006Ì\016'\236\023\013¬\006ÆÇÈ\"\210Í\013!\023ÎÏ!\026\"\bÐ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ªzp\026$\r\024ªs\bÒ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ª_p\026%\r\024ªX\bÓ=«\005p\024ªO\bÔ=«\005\r\024ªF\bÕ=«\005p\024ª=\bÖ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ª)\r\024p\026\"ª\"\016+×=«\027\r«\006Ñ\r!"..., stack_depth=10, constants_data=0x8534c00) at bytecode.c:746 #26 0x0809458f in Fbyte_code (instructions=140151684, constants=139676656, stack_depth=21) at bytecode.c:2405 #27 0x080bbab9 in Feval (form=139106244) at eval.c:3331 #28 0x080b915d in internal_catch (tag=137585596, func=0x80bb274 , arg=139106244, threw=0x0) at eval.c:1317 #29 0x080925a0 in execute_rare_opcode (stack_ptr=0xbfffee08, program_ptr=0x866f49b "\207\021", opcode=Bcatch) at bytecode.c:1252 #30 0x0809186f in execute_optimized_program (program=0x866f498 "ÀÁ\215\207\021", stack_depth=2, constants_data=0x8551768) at bytecode.c:656 #31 0x0809166e in funcall_compiled_function (fun=140561112, nargs=2, args=0xbfffef64) at bytecode.c:518 #32 0x080bc496 in Ffuncall (nargs=3, args=0xbfffef60) at eval.c:3563 #33 0x080bcb4b in Fapply (nargs=2, args=0xbffff088) at eval.c:3804 #34 0x080bc451 in Ffuncall (nargs=3, args=0xbffff084) at eval.c:3549 #35 0x08091a77 in execute_optimized_program ( program=0x862bcf8 "\r;«\005Æ\r!\025p\036\027Ç\216\r­\004È\r!\211\034­\004É\f!\e\f«\f\n«\t\016\030¬\005Ê\013!\210\f«\016\n«\013Ë \013=¬\005Ì\013!\210\r«2\n«/\016\017«\024Í\r!¬\017\212\rq\210ÎÏ!\210)Ð\r!ªM\t\b>­\013ÑÒ\016\026\"­\004Í\r!?­;Ó\r!ª6\r«)\n¬&\016\024«\020Í\r!«\013\212\rq\210ÎÔ!)ª\035\t\b>­\006ÑÒ\016\026\"?­\020Õ\r!ª\013\t\b>­\006ÑÒ\016\026\",\2079", stack_depth=4, constants_data=0x860f060) at bytecode.c:746 #36 0x0809166e in funcall_compiled_function (fun=140560944, nargs=4, args=0xbffff1f8) at bytecode.c:518 #37 0x080bc496 in Ffuncall (nargs=5, args=0xbffff1f4) at eval.c:3563 #38 0x08091a77 in execute_optimized_program ( program=0x87df9b8 "Æ Ç\211\0366\0367\036>\0168«\021È\0168!¬\005ÉÊ!\210\0168q\210ª\013\016BË>¬\005ÉÌ!\210Í \210Î \210Ï \210\016C­\025\016D?­\020Ð\0169@!?­\b\016E­\004\013Ñ=\0267\016?«\005\016?q\210`Òp!\035\036F\r«\bÓÔ\r!!¬\036ÕpÖ×\016:ØD$\210Òp!\025Ù\r!dU«\006Ú\re\"\210Ö\0266*\016>¬\026\0166¬\022\0167¬\016\013Ñ=«TÛdÒp!\"«L\0166¬0Òp!Ç\034\035Ù\r!\024\212ÜÝ\r!!\210)ÞÝ\r!!\210ÕÇ\211ß\016:ØD$\210Òp!\211\025«\006"..., stack_depth=9, constants_data=0x8768eb8) at bytecode.c:746 #39 0x0809166e in funcall_compiled_function (fun=141815604, nargs=1, args=0xbffff374) at bytecode.c:518 #40 0x080bc496 in Ffuncall (nargs=2, args=0xbffff370) at eval.c:3563 #41 0x080962e2 in Fcall_interactively (function=140641820, record_flag=137013204, keys=137013204) at callint.c:1008 #42 0x080baf01 in Fcommand_execute (cmd=140641820, record_flag=137013204, keys=137013204) at eval.c:2970 #43 0x080f5440 in execute_command_event (command_builder=0x850c210, event=140339984) at event-stream.c:3914 #44 0x080f6242 in Fdispatch_event (event=140339984) at event-stream.c:4246 #45 0x0809c72e in Fcommand_loop_1 () at cmdloop.c:583 #46 0x080b9351 in condition_case_1 (handlers=137013300, bfun=0x809c944 , barg=137013204, hfun=0x809c9e8 , harg=137013204) at eval.c:1651 #47 0x0809cbbc in command_loop_2 (dummy=137013204) at cmdloop.c:256 #48 0x080b915d in internal_catch (tag=137089324, func=0x809cb78 , arg=137013204, threw=0x0) at eval.c:1317 #49 0x0809bfa8 in initial_command_loop (load_me=137013204) at cmdloop.c:305 #50 0x080b54c7 in xemacs_21_5_b1_i686_pc_linux () at emacs.c:2346 #51 0x080b5c27 in main () at emacs.c:2775 #52 0x403b7177 in __libc_start_main (main=0x80b5b1c
, argc=1, ubp_av=0xbffff9c4, init=0x807e504 <_init>, fini=0x82063b0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff9bc) at ../sysdeps/generic/libc-start.c:129 (gdb) quit [baz@flux baz]$ -- Barrie J. Bremner OpenPGP public key ID: 5164F553 baz [at] barriebremner.com http://barriebremner.com/ From Adrian.Aichner@t-online.de Sun May 13 17:37:10 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA23694; Sun, 13 May 2001 17:37:09 -0400 Received: from fwd04.sul.t-online.de by mailout06.sul.t-online.com with smtp id 14z3Y8-0004J8-0C; Sun, 13 May 2001 23:37:12 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.59]) by fwd04.sul.t-online.com with esmtp id 14z3YQ-0jqDVQC; Sun, 13 May 2001 23:37:30 +0200 To: Hrvoje Niksic Cc: Adrian.Aichner@t-online.de (Adrian Aichner), XEmacs Patch Reviews , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Adrian.Aichner@t-online.de (Adrian Aichner) writes: >> does mouse-track-insert work for you between buffers? Hrvoje> It doesn't. Before I make any wrong assumptions: What is the (emacs-version) you verified this bug on? Mine is (emacs-version) "XEmacs 21.4 \"Developer-Friendly Unix APIs\" [Lucid] (i586-pc-win32) of Sat May 12 2001 on D5DC120J" Thanks, Adrian -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From Adrian.Aichner@t-online.de Sun May 13 17:41:14 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA23830; Sun, 13 May 2001 17:41:13 -0400 Received: from fwd04.sul.t-online.de by mailout06.sul.t-online.com with smtp id 14z3cA-0004J8-05; Sun, 13 May 2001 23:41:22 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.59]) by fwd04.sul.t-online.com with esmtp id 14z3cU-15CFzkC; Sun, 13 May 2001 23:41:42 +0200 To: Hrvoje Niksic Cc: XEmacs Patch Reviews , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Adrian.Aichner@t-online.de (Adrian Aichner) writes: >> Documentation of `make-local-hook' has a worrying, uninformative hint >> about non-normal hooks, which will have to be changed one by one. Hrvoje> It is safe to use `make-local-hook' with mouse hooks; I Hrvoje> have personally added support for that. Take a look at Hrvoje> `mouse-track-run-hook'. Hmmh, I can't make mouse-track-insert (using double-click) work between buffers, even when properly localizing mouse-track-click-hook. Are the local hooks in buff-menu.el and libs/xemacs-base/compile.el designed to cooperate with mouse-track-insert (using double-click) between buffers? Does this work for anybody, under X perhaps? Adrian Hrvoje> 1997-12-12 Hrvoje Niksic Hrvoje> * mouse.el (mouse-track-run-hook): Understand `make-local-hook' Hrvoje> convention. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From youngs@xemacs.org Sun May 13 22:27:42 2001 Received: from mail007.syd.optusnet.com.au (mail007.syd.optusnet.com.au [203.2.75.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA03715 for ; Sun, 13 May 2001 22:27:40 -0400 Received: from slackware.mynet.pc (wdcax13-094.dialup.optusnet.com.au [198.142.220.94]) by mail007.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4E2RWS13069; Mon, 14 May 2001 12:27:32 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4E2LD34004757; Mon, 14 May 2001 12:21:13 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: Rick Campbell Subject: Re: Can't view images?!? References: <200105130259.WAA15466@firewall.germs.org> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 14 May 2001 12:21:13 +1000 In-Reply-To: <200105130259.WAA15466@firewall.germs.org> (Rick Campbell's message of "Sat, 12 May 2001 22:59:17 -0400") Message-ID: Lines: 39 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "RC" == Rick Campbell writes: RC> I just finished building 21.4.2 on my home machine (Slackware 7.0). RC> Despite every indication that it should be supporting images, the only RC> real image support that I've seen is X-Face stuff via mh-e. Visiting RC> an image file and using image-toggle-decoding never does anything RC> close to showing an image. ,----[ put this in ~/.xemacs/init.el (or .emacs) ] | ;:*======================= | ;:* Image formats | (add-to-list 'format-alist | '(image/jpeg "JPEG image" "\377\330\377\340\000\020JFIF" | image-decode-jpeg nil t image-mode)) | (add-to-list 'format-alist | '(image/gif "GIF image" "GIF8[79]" | image-decode-gif nil t image-mode)) | (add-to-list 'format-alist | '(image/png "Portable Network Graphics" "\211PNG" | image-decode-png nil t image-mode)) | ;; XPM files are C program text, and as such should not | ;; be autodecoded by default. Uncomment if you like. | ;(add-to-list 'format-alist | ; '(image/x-xpm "XPM image" "/\\* XPM \\*/" | ; image-decode-xpm nil t image-mode)) | (add-to-list 'format-alist | '(image/tiff "TIFF image" "II\\*\000" | image-decode-tiff nil t image-mode)) ;; TIFF 6.0 big-endian | (add-to-list 'format-alist | '(image/tiff "TIFF image" "MM\000\\*" | image-decode-tiff nil t image-mode)) ;; TIFF 6.0 little-endian `---- -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From steve@turnbull.sk.tsukuba.ac.jp Mon May 14 02:42:46 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA18570 for ; Mon, 14 May 2001 02:42:42 -0400 Received: by localhost id m14zBvw-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 14 May 2001 15:34:20 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15103.31851.761695.361533@turnbull.sk.tsukuba.ac.jp> Date: Mon, 14 May 2001 15:34:19 +0900 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Bignum support In-Reply-To: References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15100.56861.834719.524626@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> "Stephen J. Turnbull" writes: >> I don't think he'd necessarily want to _disallow_ [bignums]. Hrvoje> Internally, why not? The user will never see the Hrvoje> difference, and it allows us to retain the simple XINT Hrvoje> interface whenever we're dealing with fixnums. Because it might be more efficient to do an entire calculation in bignum (see below), then canonicalize at the end, rather than do canonicalizations at every point. >> Way ahead of me, I see. But you could go the declaration >> route. Hrvoje> The declarations might work in some cases, but the speed Hrvoje> win would be questionable. Declarations win in CL because Hrvoje> once you declare A and B as fixnums, the compiler has the Hrvoje> license compile (+ A B) into a machine integer addition. Hrvoje> XEmacs interpreter is in a very different position, which But CCL is _much_ faster than the Lisp interpreter. Hrvoje> is not made any easier by the fact that due to dynamic Hrvoje> scoping anyone and anything can access the values of the Hrvoje> variables and make XEmacs crash. I don't see how. I'm talking about declaring an entire sexp as an arithmetic expression, and if the compiler detected anything that might have a side-effect on a variable used in the expression, it would refuse to optimize that expression as "pure arithmetic". You would typecheck all variable values on entry, and signal error if they weren't numerical. This could be a big win in, say, image code. If such strong checking is unacceptable, you wouldn't use the declaration. > Hrvoje> With a little cleverness, the all-fixnum case might remain > Hrvoje> as fast as it is now. > I don't see why would have to be clever Hrvoje> Well, maybe it's trivial for you. :-) The cleverness I Hrvoje> was referring to would extend the "check that all Hrvoje> arguments are numbers logic": I don't understand your description of the logic. I thought it was something more like for (i = 0; i < nargs; i++) { if (ISA_NUMBER (arg[i]) arg[i] = XINT(arg[i]); else if (ISA_MARKER (arg[i]) arg[i] = COERCE_MARKER_TO_C_INT (arg[i]) /* ... */ else error("Argument %d can't be coerced to number", i); } So I would turn that into for (i = 0; i < nargs; i++) { if (ISA_FIXNUM (arg[i])) ; else if (ISA_BIGNUM (arg[i])) have_bignums = 1; else if (ISA_MARKER (arg[i])) arg[i] = MARKER_TO_LISP_INT (arg[i]) /* ... */ else error("Argument %d can't be coerced to number", i); } Then you do if (have_bignums) for (i = 0; i < nargs; i++) if (ISA_FIXNUM (arg[i])) /* or maybe do XINT (arg[i])? */ arg[i] = FIXNUM_TO_BIGNUM_REP (arg[i]); else arg[i] = BIGNUM_TO_BIGNUM_REP (arg[i]); Hrvoje> I assume the status of "experimentalness" can be revised Hrvoje> if the code proves to be stable and reliable? If you mean change the name to "optional feature" or something like that, sure. If you mean change the default in configure after feature freeze, no. I won't do it without the Board's explicit authorization. People who want the feature can ask for it in configure until the following release. I am shooting for a public release of new features every six months at this point. I'm hoping that if we can get a September release out, people will start to take the process seriously and I can hand over the reins to somebody else for the March 2002 release. I think that's soon enough to certify a feature proposed in May 2001 as "stable and reliable." We're seeing a lot of efficiency complaints about 21.4. It's not enough to be "stable and reliable", you also need to have a reasonable value/performance tradeoff before making a feature default to on. I took shortcuts on some features for 21.4, and I still think it was justified, knowing as little as I did at the time. But in the future I want to be more careful. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Mon May 14 03:01:14 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA19305 for ; Mon, 14 May 2001 03:01:09 -0400 Received: by localhost id m14zCCx-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 14 May 2001 15:51:55 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15103.32907.490375.397597@turnbull.sk.tsukuba.ac.jp> Date: Mon, 14 May 2001 15:51:55 +0900 To: karlheg@hegbloom.net (Karl M. Hegbloom) Cc: XEmacs Beta Subject: [etc/xemacs-ja.1] Shouldn't it be named "xemacs.ja.1"? In-Reply-To: <874rupxbrj.fsf@bittersweet.intra.hegbloom.net> References: <874rupxbrj.fsf@bittersweet.intra.hegbloom.net> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Karl" == Karl M Hegbloom writes: Karl> "dh_installman" looks for man pages with names formed like Karl> "xemacs.ja.1" to find non-english man pages so it can Karl> install them in the right location; eg: Karl> /usr/share/man/ja/man1. Karl> Isn't that a pretty standard naming convention? Never heard of it before as a convention. Seems preferable to me to have separate directories for different languages rather than have them all clutter up the same directory with many copies of the same thing, most useless to most users and developers. Karl> Shouldn't that man page be renamed? (perhaps copy the ,v in Karl> CVS to the new name, then cvs remove the old one to preserve Karl> history) Not before checking non-Debian systems to see what they do. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From sperber@informatik.uni-tuebingen.de Mon May 14 03:35:34 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA20511 for ; Mon, 14 May 2001 03:35:33 -0400 Received: from spectravideo-328.informatik.uni-tuebingen.de (spectravideo-328 [134.2.13.188]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0AB2B1060 for ; Mon, 14 May 2001 09:35:31 +0200 (MST) Received: (from sperber@localhost) by spectravideo-328.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4E7ZVT09401; Mon, 14 May 2001 09:35:31 +0200 (CEST) (envelope-from sperber) Sender: sperber@informatik.uni-tuebingen.de To: xemacs-beta@xemacs.org Subject: Re: Bignum support References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 14 May 2001 09:35:30 +0200 In-Reply-To: (Hrvoje Niksic's message of "11 May 2001 15:41:44 +0200") Message-ID: Lines: 20 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> I see. Here it would be nice to have compiler support for that, so Hrvoje> that the compiler can generate fixnum-only opcodes where it can prove Hrvoje> that fixnums are used. Given ELisp's tectonic speed, it's unlikely that bignum arithmetic will matter much. It sure doesn't matter enough for most interpreter based Lisp and Scheme systems bother. Hrvoje> But that's not really possible without lexical scoping, so we Hrvoje> can forget it. Huh? No. These two things don't really have anything to do with each other. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From karlheg@hegbloom.net Mon May 14 03:46:01 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA20839 for ; Mon, 14 May 2001 03:46:00 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4E7jvm6006938 for ; Mon, 14 May 2001 00:45:57 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4E7jves006935; Mon, 14 May 2001 00:45:57 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: I've been working on my Debian package rules again. From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 14 May 2001 00:45:57 -0700 Message-ID: <877kzknzka.fsf@bittersweet.intra.hegbloom.net> Lines: 57 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii It runs "fakeroot debian/rules -j2 stage" now, for an x11 binary, a minimalist tty only binary, the support etc, support elc and el, a doc-info and a doc-html package. (wow, this new computer sure is fast!) If you've got Debian "sid" (unstable) installed, you can try it if you like. (waste a few minutes for the heck of it) It is not finished yet, but interesting, perhaps. It will be a few more weekends before it's ready to use for generatation of uploadable Debian packages. This had too much work done on it to just throw away, so I'm finally going to finish it and make it available for others to use. It's quite the set of makefiles, if I do say so myself. There's probably about 60-80 hours of work into it, all told. (not much total time, considering I began the project in 1999!) The setup is partially tested with release-21-4 from today's CVS. The patches directory contains a few patches that should be applied, by hand, for now, first. % cd # run an xemacs source checkout, or stand next to the one you've got. % export CVSROOT=:pserver:anoncvs@cvs.hegbloom.net:/var/cvs/debian % cvs login % cvs -z3 checkout debian.xemacs % cd xemacs % ln -s ../debian.xemacs debian Tell me if none of that works for you. Targets are, roughly: fakeroot debian/rules [-j2] config ... ... build ... ... stage config-minimalist config-support-bin config-deluxe-x11 build-... stage-... ... and so forth. It should be very straightforward to add a new editor binary configuration and make this thing create a "custom" package. I will need help with the Mule versions, at some point. I'll holler when I'm ready. (The combinatorial explosion presented *really* makes me want DSO support to get completed!) From hniksic@arsdigita.com Mon May 14 04:59:42 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA23706; Mon, 14 May 2001 04:59:41 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zECZ-0004ZQ-00; Mon, 14 May 2001 10:59:39 +0200 Sender: hniksic@florida.arsdigita.de To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: XEmacs Patch Reviews , XEmacs Beta List Subject: Re: make-local-variable.*hook: Incorrect usage in packages and core? References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 14 May 2001 10:59:39 +0200 In-Reply-To: (Adrian.Aichner@t-online.de's message of "13 May 2001 23:36:50 +0200") Message-ID: Lines: 15 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian.Aichner@t-online.de (Adrian Aichner) writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> Adrian.Aichner@t-online.de (Adrian Aichner) writes: > >> does mouse-track-insert work for you between buffers? > > Hrvoje> It doesn't. > > Before I make any wrong assumptions: > > What is the (emacs-version) you verified this bug on? (emacs-version) "XEmacs 21.4 (patch 1) \"Copyleft\" [Lucid] (i686-pc-linux, Mule) of Sat Apr 28 2001 on florida.arsdigita.de" From didier@lrde.epita.fr Mon May 14 04:59:59 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA23731 for ; Mon, 14 May 2001 04:59:56 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id KAA24587 Mon, 14 May 2001 10:55:39 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 14zE88-0007Im-00; Mon, 14 May 2001 10:55:04 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 14zE7e-0004Md-00; Mon, 14 May 2001 10:54:34 +0200 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: XEmacs Beta List Subject: Re: Change of algorithm to write (custom-set-* ...) in 21.5-b1? References: <4ruqk8ae.fsf@rapier.ecf.teradyne.com> X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: <4ruqk8ae.fsf@rapier.ecf.teradyne.com> (Adrian.Aichner@t-online.de's message of "12 May 2001 15:26:33 +0200") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 14 May 2001 10:54:33 +0200 Message-ID: Lines: 20 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id EAA23731 Adrian.Aichner@t-online.de (Adrian Aichner) wrote: > I just noticed in 21.5-b1 that saving a changed variable from a > *Custom...* buffer via the Save button. performs major re-ordering of > the > (custom-set-* ...) > sections. You mean the order of each form within custom-set-variables/faces ? This only thing that changed recently is my improvements on the custom settings saving algorithm. But practically, this lead to calling custom-save-all only once for all instead of once for each customization item. So the ordering is not decided by me (or custom), it's the 'mapatoms call. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From hniksic@arsdigita.com Mon May 14 05:05:43 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA24269 for ; Mon, 14 May 2001 05:05:42 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zEHo-0004ap-00; Mon, 14 May 2001 11:05:04 +0200 Sender: hniksic@florida.arsdigita.de To: "Stephen J. Turnbull" Cc: XEmacs Beta List Subject: Re: Bignum support References: <87pudg1ddk.fsf@u.sanpo.t.u-tokyo.ac.jp> <87lmo4cad3.fsf@u.sanpo.t.u-tokyo.ac.jp> <15100.56861.834719.524626@turnbull.sk.tsukuba.ac.jp> <15103.31851.761695.361533@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 14 May 2001 11:05:04 +0200 In-Reply-To: <15103.31851.761695.361533@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Mon, 14 May 2001 15:34:19 +0900") Message-ID: Lines: 32 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> "Stephen J. Turnbull" writes: > > >> I don't think he'd necessarily want to _disallow_ [bignums]. > > Hrvoje> Internally, why not? The user will never see the > Hrvoje> difference, and it allows us to retain the simple XINT > Hrvoje> interface whenever we're dealing with fixnums. > > Because it might be more efficient to do an entire calculation in > bignum (see below), then canonicalize at the end, rather than do > canonicalizations at every point. Quite possible. The only important thing is for the "uncanonicalized" bignum not to escape into the Lisp world. > Hrvoje> I assume the status of "experimentalness" can be revised > Hrvoje> if the code proves to be stable and reliable? > > If you mean change the name to "optional feature" or something like > that, sure. If you mean change the default in configure after feature > freeze, no. Who mentioned "after feature freeze"? Are you proclaiming the feature freeze tomorrow or something? > We're seeing a lot of efficiency complaints about 21.4. Can you provide some pointers? From didier@lrde.epita.fr Mon May 14 05:14:26 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA24633 for ; Mon, 14 May 2001 05:14:25 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id LAA25394 Mon, 14 May 2001 11:04:10 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 14zEGN-0007NT-00; Mon, 14 May 2001 11:03:35 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 14zEFu-0004No-00; Mon, 14 May 2001 11:03:06 +0200 To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org, morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: <15102.36143.240455.718548@tyranny.hsys.msk.ru> (Alexey Mahotkin's message of "Sun, 13 May 2001 17:33:35 +0400 (MSD)") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 14 May 2001 11:03:06 +0200 Message-ID: Lines: 48 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA24633 Alexey Mahotkin wrote: > Suppose there is a > > (desktop-read) > > in init.el, and > > (custom-set-variables '(user-mail-address "morozov@novosoft.ru")), > > in custom.el. Now if desktop being read contains .html file then > html-mode asks again and again: "Your mail address: alex@localhost" or > something like that, because it is not yet customized. > > Surely one can move (setq user-mail-address "") to init.el, before > (desktop-read), but there must be a more generic way to address that > issue, what do you think? You can try to swap the order of custom / init files reading. That's what I do at the top of my init file: ,---- | (let ((real-custom-file custom-file)) | (setq custom-file "nonsense") | (load real-custom-file) | (add-hook 'after-init-hook | `(lambda () (setq custom-file ,real-custom-file))) | ) `----- Note that depending on the XEmacs version you use, the variable `custom-file' might not exist at the time of evaluating this form (this is a recent feature of 21.5). If you're not using a 21.5 version, you must replace `custom-file' by the explicit file name instead. Stephen might have applied the corresponding patch to the gamma series, but I don't know. > There probably exists a reason not to simply swap the order of execution of > init.el and custom.el... Probably... actually, I can't remember what it is and I had planned to search in the archives, but it's quite a long time ago. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From steve@turnbull.sk.tsukuba.ac.jp Mon May 14 06:09:11 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA26353; Mon, 14 May 2001 06:09:09 -0400 Received: by localhost id m14zF8R-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 14 May 2001 18:59:27 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15103.44146.78921.882126@turnbull.sk.tsukuba.ac.jp> Date: Mon, 14 May 2001 18:59:14 +0900 To: Didier Verna Cc: Alexey Mahotkin , xemacs-beta@xemacs.org, morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el In-Reply-To: References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "drv" == Didier Verna writes: drv> Note that depending on the XEmacs version you use, the drv> variable `custom-file' might not exist at the time of drv> evaluating this form (this is a recent feature of 21.5). If drv> you're not using a 21.5 version, you must replace drv> `custom-file' by the explicit file name instead. Stephen drv> might have applied the corresponding patch to the gamma drv> series, but I don't know. No, I'm waiting on further comment (none until today, no help yet) and screams of pain from 21.5 users (none so far, I'm leaning to applying since it gives a way to fix the no-way-to-set-mule-fonts-in-init.el bug). Also, I want a look at the thread about why not to switch the order of custom.el and init.el. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From nix@esperi.demon.co.uk Mon May 14 16:30:27 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA25902 for ; Mon, 14 May 2001 16:30:18 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id VAA28624; Mon, 14 May 2001 21:23:18 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id VAA17887; Mon, 14 May 2001 21:23:17 +0100 Sender: nix@esperi.demon.co.uk To: Hrvoje Niksic Cc: xemacs-beta@xemacs.org Subject: Re: Horrible term-mode problems on upgrade to 21.4 References: <87y9s38t3y.fsf@loki.wkstn.nix> <87ofsy5fy5.fsf@loki.wkstn.nix> <87y9s23xk8.fsf@loki.wkstn.nix> <87ofsy3un0.fsf@loki.wkstn.nix> X-Emacs: because Hell was full. From: Nix Date: 14 May 2001 21:23:16 +0100 In-Reply-To: Message-ID: <877kzj65or.fsf@loki.wkstn.nix> Lines: 172 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On 13 May 2001, Hrvoje Niksic stipulated: > Nix writes: >> That would be very nice; it would obsolete big chunks of mailcrypt, >> jka-compr, uncompress... even term-mode's `term-emulate-terminal', >> come to think of it. In fact, probably by the time you've got that >> generic, `input filter' and `output filter' are better terms for >> this stackable thing than `coding system'. > > Exactly. A form of "coding system" would probably remain, because > when you finally import the bytes into XEmacs, you have to convert > them to chars of a certain charset. At this point the coding systems > would still be useful. ... if just to tell Emacs what coding system you've finally *got*. Hmm. Suggestion; the input and output of the filters are typed (perhaps by being a cons cell whose car is a type and whose cdr is a `character'; obviously this is wildly inefficient and wouldn't work for stateful coding systems, but you get the idea) and you can only stack filters where the output type of one filter equals the input type of the one next in the sequence. The name of the output type of the last filter is what XEmacs currently calls the coding system's name. Or is a coding system more than `the output of a transformative program in some language, of a named type'? >> This is sort of a generalization both of coding systems and of the >> existing asynchronous subprocess filters; almost certainly both of >> these could be reimplemented in terms of the filter stack. > > I'm not sure I would generalize to that point, but perhaps it's > possible. I'm a generalist past sanity, I know. (But then, exactly that generalizing viewpoint gave us Lisp to start with, and Emacs; there is some merit in it. :) ) >> Hmm. One question, actually. The Golden Rules of Redisplay (no GC, >> no Lisp); are they there because having Lisp touch the *_set >> variables while redisplay is running could be nasty? > > I'm not sure about the "no GC" rule, but the no Lisp rule is there > because of efficiency and robustness. Efficiency means that Lisp code > might be too expensive to call within redisplay. That's a reason for discouraging large amounts of Lisp, not for banning it completely. (It's also a reason to speed up parts of the Lisp interpreter, like the funcall path; but I note that things have been happening on that front :) I'm aiming to attack the other nasty Emacs monster, the GC; I hate GCPRO with a passion and I hate the nonincremental GC almost as much, especially on small machines...) > Robustness means > that there is no good way to handle Lisp errors while you're in > redisplay "critical section". It's just too dangerous. Er, why not wrap any invoked Lisp in a condition-case? (Or do you mean flat-out syntactic errors?) > There have been discussions about how to circumvent the Golden Rules. I'd rather abolish them completely if possible. Redisplay is complex code, yes, but why should that grant it the right to ban Lisp? (Emacs's power is due to the pervasiveness of Lispability throughout its core, after all... IMHO, the ideal Emacs core would be a really, really fast Lisp engine, glue code to external libraries, and nothing else. Well, not quite. The *ideal* Emacs core would have pluggable languages, but that's a *total* pipe-dream :) maybe by 2010...) > One of them is to allow a safe subset of Lisp to be run, sort of like > CCL is currently allowed. That sounds like a good first step ;P > Remember that a) specifiers are cached, and b) specifiers are resolved > from within redisplay. The Golden Rules strike back. :-) The caching, of course, changes what it is sane to do. It seems sensible to make specifiers subject to the rule that the specifiers, and any functions invoked from them, must not modify global state (agh, but that wrecks `gensym'); and also that they should not rely upon global state without care (but of course they can sometimes for user customization; relying on oft-changing variables can be nasty though). This is a right tangle :( >> structures. Things like e.g. keymaps should appear to the Lisp layer >> as directly Lisp-manipulable objects, so that `read' and `print' can >> work on them. > > We can discuss that. I have personally made steps in that direction > by implemented ways to create arbitrary events and adding read/print > syntax to hash tables. Could you explain why you need a read/print > syntax for keymaps? I don't. I was just being purist, and I haven't found a nice syntax for keymaps yet; they were just an example. The only objects I got fully happy with were, uh, hash tables, which used a read syntax very similar to yours (and CLs). (I started working on char tables too, but rapidly found that they had a read syntax, just a totally undocumented one.) But the read syntaxes don't have to be *nice*; they just have to be consistent. I happen to think that `read' and `print' are very useful, and the presence of things like `desktop.el' writing out big chunks of Emacs state as Lisp and just `load'ing it back in again tends to support me there :) My keymap syntax was a rather horrible one; you could specify an entire keymap at once via a #k(keyword-args) syntax, where the keyword arguments could be :parents, :default-binding, :prompt, or :contents, where :contents took an alist mapping from a key to a def as in `define-key'. I defined printing a keymap to print out only this C-level keymap, with keymap names representing the keymaps used for key sequences (automatically generated and assigned to them if necessary; yes, this meant `print' could modify objects, and I hated it). I could alternatively have had it print out the entire stack of keymaps, but that would have meant that sub-keymaps would lose their identity. (Perhaps I should have made it configurable.) Now it's true that the input side of this could all have been done with a little `make-entire-keymap' wrapper, but I couldn't have got them printed that way; at least, not by `print'. And it would have been less regular, and regularity is the essence of Lisp. (And it was a fun hack.) > Speaking of keymaps, remember that they are not opaque objects because > of our perversion. When you change key definitions, the keymap code > actually recalculates internal caches that make operations like > `where-is' fast, which is extremely important for menus. Agreed; this is why I never did anything to let you read in *bits* of keymaps. I never expected calling `read' on a million keymaps to be fast --- or sane --- anyway. >> I've got half- completed patches that exploit common-lisp style #x() >> syntax to do this, so you can set and update many opaque objects >> from the lisp reader, with the letter indicating the type of formerly >> opaque object, as in Common Lisp... if you want, I can clean them up >> (and they'll require a good bit of cleanup; the patches were initially >> a proof-of-concept, and clean they are not) and submit them. > > I would like to know more about the changes you envisioned. For I'd like to *find* them again. I just spent three hours looking for them after you asked and they seem to have vanished. Oh well, all the more reason for me to rewrite them better. (I was mostly doing this as a way to get to know the Emacs C core in a fairly general way, so the code was, er, ugly in places. I can do better than that now.) > instance, could you post a Lisp code snippet of how updating an opaque > object from the reader would work with your patches applied. (setq message-mode-map #k(:contents ((M-m . mml-mode-map) (tab . message-tab) (copy . copy-primary-selection)))) ... only an awful lot longer in the general case (and if `print' emitted it, of course not laid out like that either). -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From baz@barriebremner.com Mon May 14 18:35:43 2001 Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA32462 for ; Mon, 14 May 2001 18:35:40 -0400 Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14zQwF-0003xA-00 for xemacs-beta@xemacs.org; Mon, 14 May 2001 23:35:39 +0100 Received: from modem-72.anduin.dialup.pol.co.uk ([62.136.108.200] helo=flux.localdomain) by mail17.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14zQwC-0002VE-00 for xemacs-beta@xemacs.org; Mon, 14 May 2001 23:35:36 +0100 Received: (qmail 20032 invoked by uid 500); 14 May 2001 22:28:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15104.23583.673504.851117@flux.localdomain> Date: Mon, 14 May 2001 23:28:47 +0100 From: Barrie Bremner To: xemacs-beta@xemacs.org Subject: Another crash with 21.5-b1 "anise" and VM/keystroke X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Uptime: 1 week 2 days 5 hours 58 minutes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id SAA32462 Hi all. Another crash just as I hit space for a new message in VM 6.92 [baz@flux baz]$ uname -a Linux flux.localdomain 2.4.4-ac5 #1 SMP Sat May 5 16:43:23 GMT 2001 i686 unknown Output from gdb follows. [baz@flux baz]$ gdb xemacs core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/bin/xemacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libXaw.so.7...done. Loaded symbols for /usr/X11R6/lib/libXaw.so.7 Reading symbols from /usr/lib/libtiff.so.3...done. Loaded symbols for /usr/lib/libtiff.so.3 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libdb-3.1.so...done. Loaded symbols for /lib/libdb-3.1.so Reading symbols from /usr/lib/libgpm.so.1...done. Loaded symbols for /usr/lib/libgpm.so.1 Reading symbols from /usr/lib/libncurses.so.5...done. Loaded symbols for /usr/lib/libncurses.so.5 Reading symbols from /usr/lib/libesd.so.0...done. Loaded symbols for /usr/lib/libesd.so.0 Reading symbols from /usr/lib/libaudiofile.so.0...done. Loaded symbols for /usr/lib/libaudiofile.so.0 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_nisplus.so.2...done. Loaded symbols for /lib/libnss_nisplus.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 #0 0x081774be in print_internal (obj=0, printcharfun=137160324, escapeflag=1) at print.c:1224 1224 if (CONSP (obj) || VECTORP (obj) || COMPILED_FUNCTIONP (obj)) (gdb) where #0 0x081774be in print_internal (obj=0, printcharfun=137160324, escapeflag=1) at print.c:1224 #1 0x08178d15 in Fprin1 (object=0, stream=137160324) at print.c:637 #2 0x080be5bf in Fbacktrace (stream=137160324, detailed=137013228) at eval.c:5217 #3 0x080b4526 in fatal_error_signal (sig=11) at emacs.c:518 #4 #5 0x080918db in execute_optimized_program (program=0x86c5b08 "ÃÄ\n\t\b$\207dp de\031", stack_depth=5, constants_data=0x83765d8) at bytecode.c:671 #6 0x0809166e in funcall_compiled_function (fun=137801188, nargs=3, args=0xbfffdcb8) at bytecode.c:518 #7 0x080bc496 in Ffuncall (nargs=4, args=0xbfffdcb4) at eval.c:3563 #8 0x08091a77 in execute_optimized_program (program=0x86c5ae8 "ÃÄ\n!\t\b#\207ptio!", stack_depth=4, constants_data=0x8366a28) at bytecode.c:746 #9 0x0809166e in funcall_compiled_function (fun=137756004, nargs=3, args=0xbfffde2c) at bytecode.c:518 #10 0x080bc496 in Ffuncall (nargs=4, args=0xbfffde28) at eval.c:3563 #11 0x08091a77 in execute_optimized_program (program=0x86c5a88 "Ã\n\t\b#Ä\n\t\b#\\\207!", stack_depth=5, constants_data=0x8366a78) at bytecode.c:746 #12 0x0809166e in funcall_compiled_function (fun=137756060, nargs=1, args=0xbfffdfa0) at bytecode.c:518 #13 0x080bc496 in Ffuncall (nargs=2, args=0xbfffdf9c) at eval.c:3563 #14 0x08091a77 in execute_optimized_program (program=0x86c59f0 "ÃÄ!«9Ä\t!Å\032\211\030\211\022\211@ÆÇ!¥ \210\nA\211\022\211@ÈÇ!¥ \210\nA\211\022\211@ÆÇ!¥ \210\nA\211\022\211@ÈÇ!¥ \210\b*\207É\t!\207tio!", stack_depth=5, constants_data=0x86ca170) at bytecode.c:746 #15 0x0809166e in funcall_compiled_function (fun=141178864, nargs=1, args=0xbfffe11c) at bytecode.c:518 #16 0x080bc496 in Ffuncall (nargs=2, args=0xbfffe118) at eval.c:3563 #17 0x0811c080 in mapcar1 (leni=2, vals=0xbfffe170, function=140635348, sequence=140765008) at fns.c:2961 #18 0x0811c40a in Fmapcar (function=140635348, sequence=140765008) at fns.c:3067 #19 0x080bc386 in Ffuncall (nargs=3, args=0xbfffe254) at eval.c:3528 #20 0x08091a77 in execute_optimized_program ( program=0x86c5890 "Æ\211\211\211\211\211\211\036\017\031\e\032\034\035\030ÇÈÉ \"\020\bA«{\b\025\rA«÷\rA\024Ê\r@!\022Ê\f@!\023\n@\013@U­\bË\n8Ë\0138U\021\nA@\013A@U­\bÌ\n8Ì\0138U\026\017\t¬\013\016\017¬\a\rA\211\025ªÃ\t«\b\r@@Í=¬\f\016\017«\026\r@@Î=«\017\r@\f@C¤\210\r\fA¡\210ª\237\r\t«\004ͪ\002Î\r@\f@E \210\r\fA¡\210ª\211\b@.\a\207alisA", stack_depth=8, constants_data=0x86c7628) at bytecode.c:746 #21 0x0809166e in funcall_compiled_function (fun=141178332, nargs=0, args=0xbfffe3d8) at bytecode.c:518 #22 0x080bc496 in Ffuncall (nargs=1, args=0xbfffe3d4) at eval.c:3563 #23 0x08091a77 in execute_optimized_program (program=0x86c57a8 "\n¬\tÆ\f!\022Ç\f!\021\r¬\rÈ \025Ç\r!\020Æ\r!\026\017É\e\f@§«>\r@§\205­", stack_depth=7, constants_data=0x86ca028) at bytecode.c:746 #24 0x0809166e in funcall_compiled_function (fun=141178528, nargs=3, args=0xbfffe548) at bytecode.c:518 #25 0x080bc496 in Ffuncall (nargs=4, args=0xbfffe544) at eval.c:3563 #26 0x08091a77 in execute_optimized_program (program=0x86c5640 "Æ\t!Ç\t!È\035\036\030\036\031\016\035\203£", stack_depth=9, constants_data=0x86c7e80) at bytecode.c:746 #27 0x0809166e in funcall_compiled_function (fun=141178360, nargs=2, args=0xbfffe6c8) at bytecode.c:518 #28 0x080bc496 in Ffuncall (nargs=3, args=0xbfffe6c4) at eval.c:3563 #29 0x08091a77 in execute_optimized_program ( program=0x86c55b0 "Æ Ç\211\211\211\211\034\035\030\e\036\025\036\026\016\023@\020\016\023A@\025\016\024«\006\n¬\003È\022\n«'Ç\031\nS\r8\211\024¬\006ÉÊ\n\"\210Ë\f@\016\024\"\021Ì\fA@\t\"\210ÍÎ\f8\t\")ª0Ï\b!\210Ð \237\023Ñ\216\r­\"Ò\013@!\210Ë\r@@!\210Ì\r@A@!\210ÍÎ\r@8!\210\rA\025\013A\023ªÝ).\006\207é", stack_depth=7, constants_data=0x86c7570) at bytecode.c:746 #30 0x0809166e in funcall_compiled_function (fun=141178248, nargs=2, args=0xbfffe838) at bytecode.c:518 #31 0x080bc496 in Ffuncall (nargs=3, args=0xbfffe834) at eval.c:3563 #32 0x08091a77 in execute_optimized_program ( program=0xbfffe8c0 "\016)¬\006ÆÇÈ\"\210ÉÊË È\211\211\211\211\211\e\036#\036\"\034\036$\036%\036*\032\031\016&«\023\013¬\020\016&@\016'\236\023\016&A\211\026&¬ï\013¬\006Ì\016'\236\023\013¬\006ÆÇÈ\"\210Í\013!\023ÎÏ!\026\"\bÐ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ªzp\026$\r\024ªs\bÒ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ª_p\026%\r\024ªX\bÓ=«\005p\024ªO\bÔ=«\005\r\024ªF\bÕ=«\005p\024ª=\bÖ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ª)\r\024p\026\"ª\"\016+×=«\027\r«\006Ñ\r!"..., stack_depth=10, constants_data=0x861f500) at bytecode.c:746 #33 0x0809458f in Fbyte_code (instructions=140151908, constants=140637424, stack_depth=21) at bytecode.c:2405 #34 0x080bbab9 in Feval (form=139230408) at eval.c:3331 #35 0x080b915d in internal_catch (tag=137585596, func=0x80bb274 , arg=139230408, threw=0x0) at eval.c:1317 #36 0x080925a0 in execute_rare_opcode (stack_ptr=0xbfffee08, program_ptr=0x866e173 "\2071", opcode=Bcatch) at bytecode.c:1252 #37 0x0809186f in execute_optimized_program (program=0x866e170 "ÀÁ\215\2071", stack_depth=2, constants_data=0x861f5d0) at bytecode.c:656 #38 0x0809166e in funcall_compiled_function (fun=140560992, nargs=2, args=0xbfffef64) at bytecode.c:518 #39 0x080bc496 in Ffuncall (nargs=3, args=0xbfffef60) at eval.c:3563 #40 0x080bcb4b in Fapply (nargs=2, args=0xbffff088) at eval.c:3804 #41 0x080bc451 in Ffuncall (nargs=3, args=0xbffff084) at eval.c:3549 #42 0x08091a77 in execute_optimized_program ( program=0x861f770 "\r;«\005Æ\r!\025p\036\027Ç\216\r­\004È\r!\211\034­\004É\f!\e\f«\f\n«\t\016\030¬\005Ê\013!\210\f«\016\n«\013Ë \013=¬\005Ì\013!\210\r«2\n«/\016\017«\024Í\r!¬\017\212\rq\210ÎÏ!\210)Ð\r!ªM\t\b>­\013ÑÒ\016\026\"­\004Í\r!?­;Ó\r!ª6\r«)\n¬&\016\024«\020Í\r!«\013\212\rq\210ÎÔ!)ª\035\t\b>­\006ÑÒ\016\026\"?­\020Õ\r!ª\013\t\b>­\006ÑÒ\016\026\",\207\001\b", stack_depth=4, constants_data=0x860efe8) at bytecode.c:746 #43 0x0809166e in funcall_compiled_function (fun=140560824, nargs=4, args=0xbffff1f8) at bytecode.c:518 #44 0x080bc496 in Ffuncall (nargs=5, args=0xbffff1f4) at eval.c:3563 #45 0x08091a77 in execute_optimized_program ( program=0x86bbe80 "Æ Ç\211\0366\0367\036>\0168«\021È\0168!¬\005ÉÊ!\210\0168q\210ª\013\016BË>¬\005ÉÌ!\210Í \210Î \210Ï \210\016C­\025\016D?­\020Ð\0169@!?­\b\016E­\004\013Ñ=\0267\016?«\005\016?q\210`Òp!\035\036F\r«\bÓÔ\r!!¬\036ÕpÖ×\016:ØD$\210Òp!\025Ù\r!dU«\006Ú\re\"\210Ö\0266*\016>¬\026\0166¬\022\0167¬\016\013Ñ=«TÛdÒp!\"«L\0166¬0Òp!Ç\034\035Ù\r!\024\212ÜÝ\r!!\210)ÞÝ\r!!\210ÕÇ\211ß\016:ØD$\210Òp!\211\025«\006"..., stack_depth=9, constants_data=0x866fc90) at bytecode.c:746 #46 0x0809166e in funcall_compiled_function (fun=141529712, nargs=1, args=0xbffff374) at bytecode.c:518 #47 0x080bc496 in Ffuncall (nargs=2, args=0xbffff370) at eval.c:3563 #48 0x080962e2 in Fcall_interactively (function=140639652, record_flag=137013204, keys=137013204) at callint.c:1008 #49 0x080baf01 in Fcommand_execute (cmd=140639652, record_flag=137013204, keys=137013204) at eval.c:2970 #50 0x080f5440 in execute_command_event (command_builder=0x850c210, event=142818396) at event-stream.c:3914 #51 0x080f6242 in Fdispatch_event (event=142818396) at event-stream.c:4246 #52 0x0809c72e in Fcommand_loop_1 () at cmdloop.c:583 #53 0x080b9351 in condition_case_1 (handlers=137013300, bfun=0x809c944 , barg=137013204, hfun=0x809c9e8 , harg=137013204) at eval.c:1651 #54 0x0809cbbc in command_loop_2 (dummy=137013204) at cmdloop.c:256 #55 0x080b915d in internal_catch (tag=137089324, func=0x809cb78 , arg=137013204, threw=0x0) at eval.c:1317 #56 0x0809bfa8 in initial_command_loop (load_me=137013204) at cmdloop.c:305 #57 0x080b54c7 in xemacs_21_5_b1_i686_pc_linux () at emacs.c:2346 #58 0x080b5c27 in main () at emacs.c:2775 #59 0x403b7177 in __libc_start_main (main=0x80b5b1c
, argc=1, ubp_av=0xbffff9c4, init=0x807e504 <_init>, fini=0x82063b0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff9bc) at ../sysdeps/generic/libc-start.c:129 (gdb) -- Barrie J. Bremner OpenPGP public key ID: 5164F553 baz [at] barriebremner.com http://barriebremner.com/ baz /baz/ n. 1. [common] The third metasyntactic variable. 2. interj. A term of mild annoyance. 3. Occasionally appended to foo to produce `foobaz' -- Jargon File v4.3.0, www.tuxedo.org/jargon 4. Me. From ysh@mindspring.com Mon May 14 20:45:28 2001 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA05787 for ; Mon, 14 May 2001 20:45:23 -0400 Received: from localhost.localdomain.mindspring.com (user-2inih8g.dialup.mindspring.com [165.121.69.16]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA27344 for ; Mon, 14 May 2001 20:45:13 -0400 (EDT) Message-Id: <200105150045.UAA27344@smtp10.atl.mindspring.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 14 May 2001 20:47:01 -0400 From: Isaac Hollander To: xemacs-beta@xemacs.org Subject: 21.4.2 mwheel.el woes X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid I decided to use mwheel.el to make my m$ intellimouse work with XEmacs 21.4.2 built on RedHat 7.1. In .xemacs/.init.el: (autoload 'mwheel-install "mwheel" "Enable mouse wheel support.") (mwheel-install) and in .xemacs/custom.el (custom-set-variables '(mwheel-follow-mouse t)) When I abuse the mouse wheel, going quickly up-and-down to the beginning and end of my VM INBOX Summary buffer, XEmacs dies with the following lisp backtrace (unfortunately no coredump): Fatal error (10). [ ... ] Lisp backtrace follows: ding(nil buffer-bound) # bind (etype debug-on-error inhibit-quit old-debug-on-error error-object) command-error((end-of-buffer)) # (catch exit ...) # bind (standard-input standard-output) # (unwind-protect ...) recursive-edit() # bind (inhibit-trace standard-output buffer-read-only) byte-code("..." [print-escape-newlines print-length debugger-buffer debugger-value standard-output debugger-args pop-to-buffer erase-buffer t 50 backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?* 0 exit "Return value: " prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" recursive-edit buffer-read-only inhibit-trace] 3) # (unwind-protect ...) # (unwind-protect ...) # bind (last-command this-command unread-command-event last-input-event last-input-char last-input-time last-command-event last-command-char overriding-local-map load-read-function standard-input standard-output cursor-in-echo-area) # (unwind-protect ...) # bind (debugger-value debug-on-error debug-on-quit debug-on-signal debugger-buffer debugger-old-buffer debugger-step-after-exit executing-macro debugger-outer-match-data debugger-outer-load-read-function debugger-outer-overriding-local-map debugger-outer-last-command debugger-outer-this-command debugger-outer-unread-command-event debugger-outer-unread-command-events debugger-outer-last-input-event debugger-outer-last-input-char debugger-outer-last-input-time debugger-outer-last-command-event debugger-outer-last-command-char debugger-outer-standard-input debugger-outer-standard-output debugger-outer-cursor-in-echo-area debugger-args) debug(error (undefined-keystroke-sequence [#])) # (catch debugger ...) # (unwind-protect ...) # bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) # (condition-case ... . error) # (catch top-level ...) uname -a: Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown ./configure '--with-xface' '--extra-verbose' '--with-widgets=athena' '--with-athena=3d' '--with-dialogs=athena' '--with-scrollbars=lucid' '--with-menubars=lucid' '--cache-file=/dev/null' '--external-widget' XEmacs 21.4.2 "Developer-Friendly Unix APIs" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/local/src/xemacs-21.4.2 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw3d - Athena library to link: Xaw3d Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. From wmperry@xemacs.org Mon May 14 21:05:49 2001 Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA07088 for ; Mon, 14 May 2001 21:05:36 -0400 Received: from hel.bp.aventail.com ([24.12.70.142]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010515010529.HIYQ20888.femail18.sdc1.sfba.home.com@hel.bp.aventail.com>; Mon, 14 May 2001 18:05:29 -0700 Received: from hel.bp.aventail.com (wmperry@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4F15GiL000584; Mon, 14 May 2001 20:05:16 -0500 Received: (from wmperry@localhost) by hel.bp.aventail.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4F15GgW000580; Mon, 14 May 2001 20:05:16 -0500 X-Authentication-Warning: hel.bp.aventail.com: wmperry set sender to wmperry@xemacs.org using -f Sender: wmperry@aventail.com To: Isaac Hollander Cc: xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes X-Now-Listening-To: Metallica - Blitzkrieg References: <200105150045.UAA27344@smtp10.atl.mindspring.net> X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 (Isaac Hollander's message of "Mon, 14 May 2001 20:47:01 -0400") Message-ID: <867kzj4e2b.fsf@hel.bp.aventail.com> Lines: 32 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Urania) MIME-Version: 1.0 Isaac Hollander writes: > I decided to use mwheel.el to make my m$ intellimouse work with XEmacs > 21.4.2 built on RedHat 7.1. > > In .xemacs/.init.el: > > (autoload 'mwheel-install "mwheel" "Enable mouse wheel support.") > (mwheel-install) > > and in .xemacs/custom.el > > (custom-set-variables > '(mwheel-follow-mouse t)) > > When I abuse the mouse wheel, going quickly up-and-down to the beginning > and end of my VM INBOX Summary buffer, XEmacs dies with the following > lisp backtrace (unfortunately no coredump): Wow, that is pretty impressive. :) The really interesting thing is that the mouse-wheel support has absolutely no C level support - it is all in lisp and just sets up some keybindings to the extra mouse buttons that XFree defines for the wheel mouse. Any idea where: debug(error (undefined-keystroke-sequence [#])) # (catch debugger ...) Came from? Did you hit that keystroke while you were recklessly flinging your poor mouse wheel around? -Bill P. From ysh@mindspring.com Mon May 14 21:10:06 2001 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA07411; Mon, 14 May 2001 21:10:03 -0400 Received: from localhost.localdomain.mindspring.com (user-2inih8g.dialup.mindspring.com [165.121.69.16]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA25324; Mon, 14 May 2001 21:09:59 -0400 (EDT) Message-Id: <200105150109.VAA25324@smtp10.atl.mindspring.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 14 May 2001 21:11:49 -0400 From: Isaac Hollander To: wmperry@xemacs.org (William M. Perry) Cc: Isaac Hollander , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes In-Reply-To: <867kzj4e2b.fsf@hel.bp.aventail.com> References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid William> Wow, that is pretty impressive. :) The really interesting thing is that William> the mouse-wheel support has absolutely no C level support - it is all in William> lisp and just sets up some keybindings to the extra mouse buttons that William> XFree defines for the wheel mouse. William> Any idea where: William> debug(error (undefined-keystroke-sequence [#])) # (catch debugger ...) William> Came from? Did you hit that keystroke while you were recklessly flinging William> your poor mouse wheel around? Nope. Just the mouse wheel. Bizarre indeed. Another backtrace is attached. I'm going to try turning off debug-on-error to see if that helps... ding(nil buffer-bound) # bind (etype debug-on-error inhibit-quit old-debug-on-error error-object) command-error((beginning-of-buffer)) # (catch exit ...) # bind (standard-input standard-output) # (unwind-protect ...) recursive-edit() # bind (inhibit-trace standard-output buffer-read-only) byte-code("..." [print-escape-newlines print-length debugger-buffer debugger-value standard-output debugger-args pop-to-buffer erase-buffer t 50 backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?* 0 exit "Return value: " prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" recursive-edit buffer-read-only inhibit-trace] 3) # (unwind-protect ...) # (unwind-protect ...) # bind (last-command this-command unread-command-event last-input-event last-input-char last-input-time last-command-event last-command-char overriding-local-map load-read-function standard-input standard-output cursor-in-echo-area) # (unwind-protect ...) # bind (debugger-value debug-on-error debug-on-quit debug-on-signal debugger-buffer debugger-old-buffer debugger-step-after-exit executing-macro debugger-outer-match-data debugger-outer-load-read-function debugger-outer-overriding-local-map debugger-outer-last-command debugger-outer-this-command debugger-outer-unread-command-event debugger-outer-unread-command-events debugger-outer-last-input-event debugger-outer-last-input-char debugger-outer-last-input-time debugger-outer-last-command-event debugger-outer-last-command-char debugger-outer-standard-input debugger-outer-standard-output debugger-outer-cursor-in-echo-area debugger-args) debug(error (end-of-buffer)) # (catch debugger ...) # (unwind-protect ...) # bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) signal(end-of-buffer nil) # (unwind-protect ...) # bind (inhibit-point-motion-hooks opoint new count) line-move(1) # bind (count) next-line(1) # bind (arg) abbrev-hacking-next-line(1) # bind (command-debug-status) call-interactively(abbrev-hacking-next-line) # (condition-case ... . error) # (catch top-level ...) From jmincy@muniversal.com Mon May 14 23:15:41 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA13389 for ; Mon, 14 May 2001 23:15:40 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14zVJE-0003gA-00 for xemacs-beta@xemacs.org; Mon, 14 May 2001 23:15:40 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15104.40922.720000.694176@antarres.muniversal.com> Date: Mon, 14 May 2001 23:17:46 -0400 To: xemacs-beta@xemacs.org Subject: after-save-hook X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid I'm somewhat confused by why the following piece of code does not work the way that I expect. I have find-unbalanced-parentheses, which errors when there is unbalanced parens. I tried adding a save hook, that is local to only emacs-lisp mode files that calls find-unbalanced-parentheses. However, after this code runs, the after-save-hook is run in all buffers, and not just emacs-lisp-mode buffers. (defun check-for-unbalanced-parens-on-save () (interactive) (make-local-hook 'after-save-hook) (add-hook 'after-save-hook 'find-unbalanced-parentheses)) (add-hook 'emacs-lisp-mode-hook 'check-for-unbalanced-parens-on-save) -jeff ------ ;; This originally came from zmacs-stuff.el in tmc-hacks (defun find-unbalanced-parentheses () "Check the buffer for unbalanced parentheses. Stops at any that are unbalanced." (interactive) (let ((start-point (point))) (goto-char (point-min)) (condition-case e (while (/= (point) (point-max)) (forward-sexp)) (error ;; If this is an extra left paren error, we have to scan backwards to ;; find the exact left paren in error (cond ((and (eq (car e) 'error) (string-equal (cadr e) "Unbalanced parentheses")) ;; left paren error (goto-char (point-max)) (while (/= (point) (point-min)) (condition-case e (backward-sexp) (error (error "Probably an extra left parenthesis here."))))) (t (error "Probably an extra right parenthesis here."))))) (goto-char start-point) (message "All parentheses appear balanced."))) From jmincy@muniversal.com Mon May 14 23:34:44 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA14774 for ; Mon, 14 May 2001 23:34:30 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14zVbO-0005j2-00 for xemacs-beta@xemacs.org; Mon, 14 May 2001 23:34:26 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15104.42056.270000.286746@antarres.muniversal.com> Date: Mon, 14 May 2001 23:36:40 -0400 To: xemacs-beta@xemacs.org Subject: after-save-hook In-Reply-To: <15104.40922.720000.694176@antarres.muniversal.com> References: <15104.40922.720000.694176@antarres.muniversal.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Jeff Mincy writes: I'm somewhat confused by why the following piece of code does not work the way that I expect. I have find-unbalanced-parentheses, which errors when there is unbalanced parens. I tried adding a save hook, that is local to only emacs-lisp mode files that calls find-unbalanced-parentheses. However, after this code runs, the after-save-hook is run in all buffers, and not just emacs-lisp-mode buffers. (defun check-for-unbalanced-parens-on-save () (interactive) (make-local-hook 'after-save-hook) (add-hook 'after-save-hook 'find-unbalanced-parentheses)) (add-hook 'emacs-lisp-mode-hook 'check-for-unbalanced-parens-on-save) Nevermind. add-hook expects a local argument. (defun check-for-unbalanced-parens-on-save () (interactive) (make-local-hook 'after-save-hook) (add-hook 'after-save-hook 'find-unbalanced-parentheses nil >>t<<)) Geez, I can stare at the problem for an hour, and I figure it out five minutes after I send a mail message. -jeff From ben@666.com Mon May 14 23:56:43 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id XAA15668 for ; Mon, 14 May 2001 23:56:40 -0400 Received: (qmail 104 invoked by alias); 15 May 2001 03:56:36 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 99963 invoked by uid 0); 15 May 2001 03:56:35 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 15 May 2001 03:56:35 -0000 Message-ID: <3B00A94B.BC0695FE@666.com> Date: Mon, 14 May 2001 20:58:03 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Isaac Hollander CC: "William M. Perry" , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit can you get a c backtrace? the fact that the first line is > ding(nil buffer-bound) suggests a problem with the audio support, not the mousewheel. Isaac Hollander wrote: > > William> Wow, that is pretty impressive. :) The really interesting thing is that > William> the mouse-wheel support has absolutely no C level support - it is all in > William> lisp and just sets up some keybindings to the extra mouse buttons that > William> XFree defines for the wheel mouse. > > William> Any idea where: > > William> debug(error (undefined-keystroke-sequence [#])) # (catch debugger ...) > > William> Came from? Did you hit that keystroke while you were recklessly flinging > William> your poor mouse wheel around? > > Nope. Just the mouse wheel. Bizarre indeed. Another backtrace is > attached. > > I'm going to try turning off debug-on-error to see if that helps... > > ding(nil buffer-bound) > # bind (etype debug-on-error inhibit-quit old-debug-on-error error-object) > command-error((beginning-of-buffer)) > # (catch exit ...) > # bind (standard-input standard-output) > # (unwind-protect ...) > recursive-edit() > # bind (inhibit-trace standard-output buffer-read-only) > byte-code("..." [print-escape-newlines print-length debugger-buffer debugger-value standard-output debugger-args pop-to-buffer erase-buffer t 50 backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?* 0 exit "Return value: " prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" recursive-edit buffer-read-only inhibit-trace] 3) > # (unwind-protect ...) > # (unwind-protect ...) > # bind (last-command this-command unread-command-event last-input-event last-input-char last-input-time last-command-event last-command-char overriding-local-map load-read-function standard-input standard-output cursor-in-echo-area) > # (unwind-protect ...) > # bind (debugger-value debug-on-error debug-on-quit debug-on-signal debugger-buffer debugger-old-buffer debugger-step-after-exit executing-macro debugger-outer-match-data debugger-outer-load-read-function debugger-outer-overriding-local-map debugger-outer-last-command debugger-outer-this-command debugger-outer-unread-command-event debugger-outer-unread-command-events debugger-outer-last-input-event debugger-outer-last-input-char debugger-outer-last-input-time debugger-outer-last-command-event debugger-outer-last-command-char debugger-outer-standard-input debugger-outer-standard-output debugger-outer-cursor-in-echo-area debugger-args) > debug(error (end-of-buffer)) > # (catch debugger ...) > # (unwind-protect ...) > # bind (stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) > signal(end-of-buffer nil) > # (unwind-protect ...) > # bind (inhibit-point-motion-hooks opoint new count) > line-move(1) > # bind (count) > next-line(1) > # bind (arg) > abbrev-hacking-next-line(1) > # bind (command-debug-status) > call-interactively(abbrev-hacking-next-line) > # (condition-case ... . error) > # (catch top-level ...) -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Tue May 15 00:05:21 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id AAA16198 for ; Tue, 15 May 2001 00:05:20 -0400 Received: (qmail 19916 invoked by alias); 15 May 2001 04:05:03 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 19158 invoked by uid 0); 15 May 2001 04:04:44 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 15 May 2001 04:04:44 -0000 Message-ID: <3B00AB35.BB1655D9@666.com> Date: Mon, 14 May 2001 21:06:13 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Barrie Bremner CC: xemacs-beta@xemacs.org, Martin Buchholz Subject: Re: Back trace of 21.5-b1 "anise" crash References: <15102.59202.104536.906705@flux.localdomain> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Barrie Bremner wrote: > > Hi all, > > This crash occured whilst using VM 6.92 under anise - hit space bar > for next message, and XEmacs died. > > Here's what the coredump gives, again excuse me if this isn't quite > right. Newbie alert! > > [baz@flux baz]$ gdb /usr/local/bin/xemacs core-anise-with-vm > GNU gdb 5.0rh-5 Red Hat Linux 7.1 > Copyright 2001 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux"... > Core was generated by `/usr/local/bin/xemacs'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/X11R6/lib/libXaw.so.7...done. > Loaded symbols for /usr/X11R6/lib/libXaw.so.7 > Reading symbols from /usr/lib/libtiff.so.3...done. > Loaded symbols for /usr/lib/libtiff.so.3 > Reading symbols from /usr/lib/libpng.so.2...done. > Loaded symbols for /usr/lib/libpng.so.2 > Reading symbols from /usr/lib/libjpeg.so.62...done. > Loaded symbols for /usr/lib/libjpeg.so.62 > Reading symbols from /usr/lib/libz.so.1...done. > Loaded symbols for /usr/lib/libz.so.1 > Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. > Loaded symbols for /usr/X11R6/lib/libXpm.so.4 > Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. > Loaded symbols for /usr/X11R6/lib/libXmu.so.6 > Reading symbols from /usr/X11R6/lib/libXt.so.6...done. > Loaded symbols for /usr/X11R6/lib/libXt.so.6 > Reading symbols from /usr/X11R6/lib/libXext.so.6...done. > Loaded symbols for /usr/X11R6/lib/libXext.so.6 > Reading symbols from /usr/X11R6/lib/libX11.so.6...done. > Loaded symbols for /usr/X11R6/lib/libX11.so.6 > Reading symbols from /usr/X11R6/lib/libSM.so.6...done. > Loaded symbols for /usr/X11R6/lib/libSM.so.6 > Reading symbols from /usr/X11R6/lib/libICE.so.6...done. > Loaded symbols for /usr/X11R6/lib/libICE.so.6 > Reading symbols from /lib/libdl.so.2...done. > Loaded symbols for /lib/libdl.so.2 > Reading symbols from /lib/libdb-3.1.so...done. > Loaded symbols for /lib/libdb-3.1.so > Reading symbols from /usr/lib/libgpm.so.1...done. > Loaded symbols for /usr/lib/libgpm.so.1 > Reading symbols from /usr/lib/libncurses.so.5...done. > Loaded symbols for /usr/lib/libncurses.so.5 > Reading symbols from /usr/lib/libesd.so.0...done. > Loaded symbols for /usr/lib/libesd.so.0 > Reading symbols from /usr/lib/libaudiofile.so.0...done. > Loaded symbols for /usr/lib/libaudiofile.so.0 > Reading symbols from /lib/i686/libm.so.6...done. > Loaded symbols for /lib/i686/libm.so.6 > Reading symbols from /lib/libutil.so.1...done. > Loaded symbols for /lib/libutil.so.1 > Reading symbols from /lib/i686/libc.so.6...done. > Loaded symbols for /lib/i686/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > Reading symbols from /lib/libnss_files.so.2...done. > Loaded symbols for /lib/libnss_files.so.2 > Reading symbols from /lib/libnss_nisplus.so.2...done. > Loaded symbols for /lib/libnss_nisplus.so.2 > Reading symbols from /lib/libnsl.so.1...done. > Loaded symbols for /lib/libnsl.so.1 > Reading symbols from /lib/libnss_dns.so.2...done. > Loaded symbols for /lib/libnss_dns.so.2 > Reading symbols from /lib/libresolv.so.2...done. > Loaded symbols for /lib/libresolv.so.2 > #0 0x403c8801 in __kill () from /lib/i686/libc.so.6 > > (gdb) where > #0 0x403c8801 in __kill () from /lib/i686/libc.so.6 > #1 0x080b453b in fatal_error_signal (sig=11) at emacs.c:535 > #2 > #3 0x080911b3 in bytecode_arithop (obj1=25, obj2=0, opcode=Bplus) at bytecode.c:387 very strange. `25' and `0' look like numbers that somehow failed to get make_int[]ized. martin, this is your area of expertise. thoughts? > #4 0x080921e8 in execute_optimized_program (program=0x86c36c0 "Ã\n\t\b#Ä\n\t\b#\\\207!", stack_depth=5, constants_data=0x8366a78) at bytecode.c:1057 > #5 0x0809166e in funcall_compiled_function (fun=137756060, nargs=1, args=0xbfffdfa0) at bytecode.c:518 > #6 0x080bc496 in Ffuncall (nargs=2, args=0xbfffdf9c) at eval.c:3563 > #7 0x08091a77 in execute_optimized_program (program=0x86c3628 "ÃÄ!«9Ä\t!Å\032\211\030\211\022\211@ÆÇ!¥ \210\nA\211\022\211@ÈÇ!¥ \210\nA\211\022\211@ÆÇ!¥ \210\nA\211\022\211@ÈÇ!¥ \210\b*\207É\t!\207tio!", stack_depth=5, constants_data=0x86c7db0) > at bytecode.c:746 > #8 0x0809166e in funcall_compiled_function (fun=141317476, nargs=1, args=0xbfffe11c) at bytecode.c:518 > #9 0x080bc496 in Ffuncall (nargs=2, args=0xbfffe118) at eval.c:3563 > #10 0x0811c080 in mapcar1 (leni=2, vals=0xbfffe170, function=140624652, sequence=144796916) at fns.c:2961 > #11 0x0811c40a in Fmapcar (function=140624652, sequence=144796916) at fns.c:3067 > #12 0x080bc386 in Ffuncall (nargs=3, args=0xbfffe254) at eval.c:3528 > #13 0x08091a77 in execute_optimized_program ( > program=0x86c34c8 "Æ\211\211\211\211\211\211\036\017\031\e\032\034\035\030ÇÈÉ \"\020\bA«{\b\025\rA«÷\rA\024Ê\r@!\022Ê\f@!\023\n@\013@U­\bË\n8Ë\0138U\021\nA@\013A@U­\bÌ\n8Ì\0138U\026\017\t¬\013\016\017¬\a\rA\211\025ªÃ\t«\b\r@@Í=¬\f\016\017«\026\r@@Î=«\017\r@\f@C¤\210\r\fA¡\210ª\237\r\t«\004ͪ\002Î\r@\f@E \210\r\fA¡\210ª\211\b@.\a\207alisA", stack_depth=8, constants_data=0x86c5260) at bytecode.c:746 > #14 0x0809166e in funcall_compiled_function (fun=141204268, nargs=0, args=0xbfffe3d8) at bytecode.c:518 > #15 0x080bc496 in Ffuncall (nargs=1, args=0xbfffe3d4) at eval.c:3563 > #16 0x08091a77 in execute_optimized_program (program=0x86c33e0 "\n¬\tÆ\f!\022Ç\f!\021\r¬\rÈ \025Ç\r!\020Æ\r!\026\017É\e\f@§«>\r@§\205­", stack_depth=7, constants_data=0x86c7c68) at bytecode.c:746 > #17 0x0809166e in funcall_compiled_function (fun=141317140, nargs=3, args=0xbfffe548) at bytecode.c:518 > #18 0x080bc496 in Ffuncall (nargs=4, args=0xbfffe544) at eval.c:3563 > #19 0x08091a77 in execute_optimized_program (program=0x86c3278 "Æ\t!Ç\t!È\035\036\030\036\031\016\035\203£", stack_depth=9, constants_data=0x86c52b8) at bytecode.c:746 > #20 0x0809166e in funcall_compiled_function (fun=141204296, nargs=2, args=0xbfffe6c8) at bytecode.c:518 > #21 0x080bc496 in Ffuncall (nargs=3, args=0xbfffe6c4) at eval.c:3563 > #22 0x08091a77 in execute_optimized_program ( > program=0x86c31e8 "Æ Ç\211\211\211\211\034\035\030\e\036\025\036\026\016\023@\020\016\023A@\025\016\024«\006\n¬\003È\022\n«'Ç\031\nS\r8\211\024¬\006ÉÊ\n\"\210Ë\f@\016\024\"\021Ì\fA@\t\"\210ÍÎ\f8\t\")ª0Ï\b!\210Ð \237\023Ñ\216\r­\"Ò\013@!\210Ë\r@@!\210Ì\r@A@!\210ÍÎ\r@8!\210\rA\025\013A\023ªÝ).\006\207é", stack_depth=7, constants_data=0x86c51a8) at bytecode.c:746 > #23 0x0809166e in funcall_compiled_function (fun=141204184, nargs=2, args=0xbfffe838) at bytecode.c:518 > #24 0x080bc496 in Ffuncall (nargs=3, args=0xbfffe834) at eval.c:3563 > #25 0x08091a77 in execute_optimized_program ( > program=0xbfffe8c0 "\016)¬\006ÆÇÈ\"\210ÉÊË È\211\211\211\211\211\e\036#\036\"\034\036$\036%\036*\032\031\016&«\023\013¬\020\016&@\016'\236\023\016&A\211\026&¬ï\013¬\006Ì\016'\236\023\013¬\006ÆÇÈ\"\210Í\013!\023ÎÏ!\026\"\bÐ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ªzp\026$\r\024ªs\bÒ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ª_p\026%\r\024ªX\bÓ=«\005p\024ªO\bÔ=«\005\r\024ªF\bÕ=«\005p\024ª=\bÖ=«\027\r«\006Ñ\r!¬\bÆÇÈ\"\210ª)\r\024p\026\"ª\"\016+×=«\027\r«\006Ñ\r!"..., stack_depth=10, constants_data=0x8534c00) at bytecode.c:746 > #26 0x0809458f in Fbyte_code (instructions=140151684, constants=139676656, stack_depth=21) at bytecode.c:2405 > #27 0x080bbab9 in Feval (form=139106244) at eval.c:3331 > #28 0x080b915d in internal_catch (tag=137585596, func=0x80bb274 , arg=139106244, threw=0x0) at eval.c:1317 > #29 0x080925a0 in execute_rare_opcode (stack_ptr=0xbfffee08, program_ptr=0x866f49b "\207\021", opcode=Bcatch) at bytecode.c:1252 > #30 0x0809186f in execute_optimized_program (program=0x866f498 "ÀÁ\215\207\021", stack_depth=2, constants_data=0x8551768) at bytecode.c:656 > #31 0x0809166e in funcall_compiled_function (fun=140561112, nargs=2, args=0xbfffef64) at bytecode.c:518 > #32 0x080bc496 in Ffuncall (nargs=3, args=0xbfffef60) at eval.c:3563 > #33 0x080bcb4b in Fapply (nargs=2, args=0xbffff088) at eval.c:3804 > #34 0x080bc451 in Ffuncall (nargs=3, args=0xbffff084) at eval.c:3549 > #35 0x08091a77 in execute_optimized_program ( > program=0x862bcf8 "\r;«\005Æ\r!\025p\036\027Ç\216\r­\004È\r!\211\034­\004É\f!\e\f«\f\n«\t\016\030¬\005Ê\013!\210\f«\016\n«\013Ë \013=¬\005Ì\013!\210\r«2\n«/\016\017«\024Í\r!¬\017\212\rq\210ÎÏ!\210)Ð\r!ªM\t\b>­\013ÑÒ\016\026\"­\004Í\r!?­;Ó\r!ª6\r«)\n¬&\016\024«\020Í\r!«\013\212\rq\210ÎÔ!)ª\035\t\b>­\006ÑÒ\016\026\"?­\020Õ\r!ª\013\t\b>­\006ÑÒ\016\026\",\2079", stack_depth=4, constants_data=0x860f060) at bytecode.c:746 > #36 0x0809166e in funcall_compiled_function (fun=140560944, nargs=4, args=0xbffff1f8) at bytecode.c:518 > #37 0x080bc496 in Ffuncall (nargs=5, args=0xbffff1f4) at eval.c:3563 > #38 0x08091a77 in execute_optimized_program ( > program=0x87df9b8 "Æ Ç\211\0366\0367\036>\0168«\021È\0168!¬\005ÉÊ!\210\0168q\210ª\013\016BË>¬\005ÉÌ!\210Í \210Î \210Ï \210\016C­\025\016D?­\020Ð\0169@!?­\b\016E­\004\013Ñ=\0267\016?«\005\016?q\210`Òp!\035\036F\r«\bÓÔ\r!!¬\036ÕpÖ×\016:ØD$\210Òp!\025Ù\r!dU«\006Ú\re\"\210Ö\0266*\016>¬\026\0166¬\022\0167¬\016\013Ñ=«TÛdÒp!\"«L\0166¬0Òp!Ç\034\035Ù\r!\024\212ÜÝ\r!!\210)ÞÝ\r!!\210ÕÇ\211ß\016:ØD$\210Òp!\211\025«\006"..., stack_depth=9, constants_data=0x8768eb8) at bytecode.c:746 > #39 0x0809166e in funcall_compiled_function (fun=141815604, nargs=1, args=0xbffff374) at bytecode.c:518 > #40 0x080bc496 in Ffuncall (nargs=2, args=0xbffff370) at eval.c:3563 > #41 0x080962e2 in Fcall_interactively (function=140641820, record_flag=137013204, keys=137013204) at callint.c:1008 > #42 0x080baf01 in Fcommand_execute (cmd=140641820, record_flag=137013204, keys=137013204) at eval.c:2970 > #43 0x080f5440 in execute_command_event (command_builder=0x850c210, event=140339984) at event-stream.c:3914 > #44 0x080f6242 in Fdispatch_event (event=140339984) at event-stream.c:4246 > #45 0x0809c72e in Fcommand_loop_1 () at cmdloop.c:583 > #46 0x080b9351 in condition_case_1 (handlers=137013300, bfun=0x809c944 , barg=137013204, hfun=0x809c9e8 , harg=137013204) at eval.c:1651 > #47 0x0809cbbc in command_loop_2 (dummy=137013204) at cmdloop.c:256 > #48 0x080b915d in internal_catch (tag=137089324, func=0x809cb78 , arg=137013204, threw=0x0) at eval.c:1317 > #49 0x0809bfa8 in initial_command_loop (load_me=137013204) at cmdloop.c:305 > #50 0x080b54c7 in xemacs_21_5_b1_i686_pc_linux () at emacs.c:2346 > #51 0x080b5c27 in main () at emacs.c:2775 > #52 0x403b7177 in __libc_start_main (main=0x80b5b1c
, argc=1, ubp_av=0xbffff9c4, init=0x807e504 <_init>, fini=0x82063b0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff9bc) at ../sysdeps/generic/libc-start.c:129 > (gdb) quit > [baz@flux baz]$ > > -- > Barrie J. Bremner OpenPGP public key ID: 5164F553 > baz [at] barriebremner.com http://barriebremner.com/ -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Tue May 15 00:10:25 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id AAA16415 for ; Tue, 15 May 2001 00:10:23 -0400 Received: (qmail 31301 invoked by alias); 15 May 2001 04:10:13 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 30864 invoked by uid 0); 15 May 2001 04:10:04 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 15 May 2001 04:10:04 -0000 Message-ID: <3B00AC75.4A38896D@666.com> Date: Mon, 14 May 2001 21:11:33 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Didier Verna CC: Alexey Mahotkin , xemacs-beta@xemacs.org, morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Didier Verna wrote: > > Alexey Mahotkin wrote: > > > Suppose there is a > > > > (desktop-read) > > > > in init.el, and > > > > (custom-set-variables '(user-mail-address "morozov@novosoft.ru")), > > > > in custom.el. Now if desktop being read contains .html file then > > html-mode asks again and again: "Your mail address: alex@localhost" or > > something like that, because it is not yet customized. > > > > Surely one can move (setq user-mail-address "") to init.el, before > > (desktop-read), but there must be a more generic way to address that > > issue, what do you think? > > You can try to swap the order of custom / init files reading. That's > what I do at the top of my init file: > > ,---- > | (let ((real-custom-file custom-file)) > | (setq custom-file "nonsense") > | (load real-custom-file) > | (add-hook 'after-init-hook > | `(lambda () (setq custom-file ,real-custom-file))) > | ) > `----- > > Note that depending on the XEmacs version you use, the variable > `custom-file' might not exist at the time of evaluating this form (this is a > recent feature of 21.5). If you're not using a 21.5 version, you must replace > `custom-file' by the explicit file name instead. Stephen might have applied > the corresponding patch to the gamma series, but I don't know. > > > There probably exists a reason not to simply swap the order of execution of > > init.el and custom.el... > > Probably... actually, I can't remember what it is and I had planned to > search in the archives, but it's quite a long time ago. the reason is called "hystery". btw in Arch XEmacs, written years ago [!], it says in http://www.xemacs.org/Architecting-XEmacs/init-files.html: The custom init file is where the custom package writes its options. This obviously needs to be a separate file from the standard init file. It should also be loaded before the init file rather than after, as is usually done currently, so that the init file can override these options if it wants to. imo we should just change the order and see what happens. > > -- > Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier > > EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 > 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From jstuart-devel@neo.rr.com Tue May 15 00:54:42 2001 Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA18573; Tue, 15 May 2001 00:54:37 -0400 Received: from bones (c4-1c006.neo.rr.com [24.93.242.6]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with SMTP id f4F4pUk12407; Tue, 15 May 2001 00:51:31 -0400 (EDT) Reply-To: From: "Jeffrey A. Stuart" To: "XEmacs Beta" Cc: Subject: RE: Updated Packages in Pre-Releases - May 12 Date: Tue, 15 May 2001 00:54:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 FYI... with Ben's fixes to EFS, I am FINALLY able to download and install packages using Xemacs... YAHH!!! THANK YOU BEN! -- Jeff (FurBall) WebOverdrive Newbie Tech Board http://www.topniche.com/tech/ furball@weboverdrive.com -----Original Message----- From: xemacs-beta-admin@xemacs.org [mailto:xemacs-beta-admin@xemacs.org]On Behalf Of Steve Youngs Sent: Friday, May 11, 2001 10:13 AM To: XEmacs Beta Subject: Updated Packages in Pre-Releases - May 12 The following packages have been updated and put into the "Pre-Releases" directory: cc-mode-1.25-pkg.tar.gz ======================= 2001-05-11 Martin Stjernholm * cc-langs.el (c-switch-label-key): Regexp fix. efs-1.23-pkg.tar.gz =================== 2001-05-10 Ben Wing * LISTS: * README (http): * efs-report.el (efs-bug-address): * efs-report.el (efs-report-bug): Note that this version is modified from the original, and that bugs related to this are not the maintainer's responsibility. * efs.el: * efs.el (efs-version): * efs.el (efs-null-device): New. * efs.el (efs-tmp-name-template): Fix up problems with Cygwin FTP client and Windows native XEmacs. * efs.el (efs-expand-tilde): Use efs-null-device. * efs.el (efs-guess-host-type): ditto. mule-base-1.38-pkg.tar.gz ========================= 2001-05-11 Alexey Mahotkin * mule-diag.el: Fix list-coding-systems. xemacs-devel-1.34-pkg.tar.gz ============================ 2001-05-11 Steve Youngs * ibuffer.el: New. Previously announced packages currently in Pre-Releases ======================================================= egg-its-1.26-pkg.tar.gz pc-1.20-pkg.tar.gz prog-modes-1.38-pkg.tar.gz Installation Instructions: ========================== Manually: --------- Simply download the files from: ftp.xemacs.org/pub/xemacs/beta/experimental/packages/ And unpack them into: [1] /usr/local/lib/xemacs/xemacs-packages/ Using XEmacs package tools: (XEmacs 21.1.14) --------------------------- 1) Options -> Manage Packages -> Add Download Site -> Pre-Releases 2) Options -> Manage Packages -> List and Install 3) Choose the packages you wish to install (there are brief instructions at the bottom of the '*Packages*' buffer). 4) Packages -> Install/Remove Selected 5) Re-start XEmacs. Using XEmacs package tools: (XEmacs 21.2 and above) --------------------------- 1) Tools -> Packages -> Add Download Site -> Pre-Releases 2) Tools -> Packages -> List and Install 3 - 5) As per 21.1.14 instructions. As always, please let me know how it goes. Enjoy. Footnotes: [1] Note that 'mule-base-1.38-pkg.tar.gz' is a Mule package and therefore should be unpacked into: '/usr/local/lib/xemacs/mule-packages/' -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From ben@666.com Tue May 15 01:26:08 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id BAA20734 for ; Tue, 15 May 2001 01:26:08 -0400 Received: (qmail 79218 invoked by alias); 15 May 2001 05:13:07 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 45370 invoked by uid 0); 15 May 2001 05:02:36 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 15 May 2001 05:02:36 -0000 Message-ID: <3B00B8C5.94B890AA@666.com> Date: Mon, 14 May 2001 22:04:05 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Mincy CC: xemacs-beta@xemacs.org Subject: Re: after-save-hook References: <15104.40922.720000.694176@antarres.muniversal.com> <15104.42056.270000.286746@antarres.muniversal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 21.4 contains `add-local-hook'. Jeff Mincy wrote: > > Jeff Mincy writes: > > > I'm somewhat confused by why the following piece of code > does not work the way that I expect. I have > find-unbalanced-parentheses, which errors when there is > unbalanced parens. I tried adding a save hook, that is local > to only emacs-lisp mode files that calls find-unbalanced-parentheses. > However, after this code runs, the after-save-hook is run in all > buffers, and not just emacs-lisp-mode buffers. > > > (defun check-for-unbalanced-parens-on-save () > (interactive) > (make-local-hook 'after-save-hook) > (add-hook 'after-save-hook 'find-unbalanced-parentheses)) > > (add-hook 'emacs-lisp-mode-hook 'check-for-unbalanced-parens-on-save) > > Nevermind. add-hook expects a local argument. > > (defun check-for-unbalanced-parens-on-save () > (interactive) > (make-local-hook 'after-save-hook) > (add-hook 'after-save-hook 'find-unbalanced-parentheses nil >>t<<)) > > Geez, I can stare at the problem for an hour, and I figure it out > five minutes after I send a mail message. > > -jeff -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From sperber@informatik.uni-tuebingen.de Tue May 15 02:22:57 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA23161; Tue, 15 May 2001 02:22:56 -0400 Received: from spectravideo-328.informatik.uni-tuebingen.de (spectravideo-328 [134.2.13.188]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 841D943A; Tue, 15 May 2001 08:22:51 +0200 (MST) Received: (from sperber@localhost) by spectravideo-328.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4F6Mkx32071; Tue, 15 May 2001 08:22:46 +0200 (CEST) (envelope-from sperber) Sender: sperber@informatik.uni-tuebingen.de To: Ben Wing Cc: Didier Verna , Alexey Mahotkin , xemacs-beta@xemacs.org, morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 15 May 2001 08:22:46 +0200 In-Reply-To: <3B00AC75.4A38896D@666.com> (Ben Wing's message of "Mon, 14 May 2001 21:11:33 -0700") Message-ID: Lines: 18 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Ben" == Ben Wing writes: Ben> btw in Arch XEmacs, written years ago [!], it says in Ben> http://www.xemacs.org/Architecting-XEmacs/init-files.html: Ben> The custom init file is where the custom package writes its options. This Ben> obviously needs to be a separate file from the standard init file. It should Ben> also be loaded before the init file rather than after, as is usually done Ben> currently, so that the init file can override these options if it wants to. Ben> imo we should just change the order and see what happens. I have no objections, given Didier's testing. When I split the files, I was merely trying to preserve the historical order. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From martin@m17n.org Tue May 15 03:22:02 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA26065 for ; Tue, 15 May 2001 03:22:01 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id QAA17247; Tue, 15 May 2001 16:21:56 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA25882; Tue, 15 May 2001 16:21:54 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4F7Lsc18832; Tue, 15 May 2001 16:21:54 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15104.55570.5198.530742@gargle.gargle.HOWL> Date: Tue, 15 May 2001 16:21:54 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Ben Wing Cc: Barrie Bremner , xemacs-beta@xemacs.org Subject: Re: Back trace of 21.5-b1 "anise" crash In-Reply-To: <3B00AB35.BB1655D9@666.com> References: <15102.59202.104536.906705@flux.localdomain> <3B00AB35.BB1655D9@666.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Ben" == Ben Wing writes: >> (gdb) where >> #0 0x403c8801 in __kill () from /lib/i686/libc.so.6 >> #1 0x080b453b in fatal_error_signal (sig=11) at emacs.c:535 >> #2 >> #3 0x080911b3 in bytecode_arithop (obj1=25, obj2=0, opcode=Bplus) at bytecode.c:387 Ben> very strange. `25' and `0' look like numbers that somehow failed to get Ben> make_int[]ized. Ben> martin, this is your area of expertise. Ben> thoughts? It looks to me like we have a Lisp_Object that is all zeros. That should never happen. The most likely reason is that there is a bug (elsewhere!) that is causing memory corruption of the stack. Most likely a bug in a C function called from the currently active lisp function. There is a chance you can get a lisp backtrace from a C debugger - see src/.gdbinit. From hniksic@arsdigita.com Tue May 15 05:31:29 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA00635 for ; Tue, 15 May 2001 05:31:29 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zbAn-0000wv-00; Tue, 15 May 2001 11:31:21 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List , Ben Wing Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 11:31:21 +0200 In-Reply-To: <3B00AC75.4A38896D@666.com> (Ben Wing's message of "Mon, 14 May 2001 21:11:33 -0700") Message-ID: Lines: 12 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > The custom init file is where the custom package writes its options. This > obviously needs to be a separate file from the standard init file. It should > also be loaded before the init file rather than after, as is usually done > currently, so that the init file can override these options if it > wants to. Please don't change the order. Init file can override Custom options although custom is loaded later. Custom is much smarter than it looks. I can elaborate if you want. From npak@ispras.ru Tue May 15 05:43:16 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id FAA01244 for ; Tue, 15 May 2001 05:43:13 -0400 Received: (qmail 4366 invoked from network); 15 May 2001 09:42:26 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 15 May 2001 09:42:26 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f4F9h9U14553; Tue, 15 May 2001 13:43:09 +0400 (MSK) Received: tid NAA10264; Wed, 15 May 1996 13:43:35 +0300 Received: from dallas.kazbek.ispras.ru (dallas.kazbek.ispras.ru [194.186.94.155]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f4F9hqg86660; Tue, 15 May 2001 13:43:52 +0400 (MSD) (envelope-from npak@ispras.ru) Received: (from npak@localhost) by dallas.kazbek.ispras.ru (8.9.3/8.9.3) id NAA04232; Tue, 15 May 2001 13:43:58 +0400 X-Authentication-Warning: dallas.kazbek.ispras.ru: npak set sender to npak@ispras.ru using -f Sender: npak@kazbek.ispras.ru To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: Ben Wing , Didier Verna , Alexey Mahotkin , xemacs-beta@xemacs.org, morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> From: npak@ispras.ru (Nick V. Pakoulin) Date: 15 May 2001 13:43:57 +0400 In-Reply-To: sperber@informatik.uni-tuebingen.de's message of "15 May 2001 08:22:46 +0200" Message-ID: Lines: 23 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Urania) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA01244 intro: "MS" == Michael Sperber writes: >>>>>> "Ben" == Ben Wing writes: Ben> btw in Arch XEmacs, written years ago [!], it says in Ben> http://www.xemacs.org/Architecting-XEmacs/init-files.html: Ben> The custom init file is where the custom package writes its Ben> options. This obviously needs to be a separate file from the standard Ben> init file. It should also be loaded before the init file rather than Ben> after, as is usually done currently, so that the init file can override Ben> these options if it wants to. Ben> imo we should just change the order and see what happens. MS> I have no objections, given Didier's testing. When I split the files, I MS> was merely trying to preserve the historical order. I load custom-file manually as the very first thing in my init file. And everything works fine. Nick. MS> -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From didier@lrde.epita.fr Tue May 15 05:47:14 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA01457 for ; Tue, 15 May 2001 05:47:12 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id LAA18130 Tue, 15 May 2001 11:44:51 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 14zbNV-0006Uf-00; Tue, 15 May 2001 11:44:29 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 14zbMa-0006g7-00; Tue, 15 May 2001 11:43:32 +0200 To: Hrvoje Niksic Cc: XEmacs Beta List , Ben Wing Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (Hrvoje Niksic's message of "15 May 2001 11:31:21 +0200") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 15 May 2001 11:43:32 +0200 Message-ID: Lines: 23 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id FAA01457 Hrvoje Niksic wrote: > Ben Wing writes: > > > The custom init file is where the custom package writes its options. This > > obviously needs to be a separate file from the standard init file. It > > should also be loaded before the init file rather than after, as is > > usually done currently, so that the init file can override these options > > if it wants to. > > Please don't change the order. > > Init file can override Custom options although custom is loaded later. True, but that doesn't make it a good argument *not* to change the order. There are more important problems, like starting packages from the init files, resulting in customizations not being set up when the package is run. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From hniksic@arsdigita.com Tue May 15 05:51:50 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA01690 for ; Tue, 15 May 2001 05:51:50 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zbUb-00011d-00; Tue, 15 May 2001 11:51:49 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Cc: Ben Wing Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 11:51:49 +0200 In-Reply-To: (Didier Verna's message of "15 May 2001 11:43:32 +0200") Message-ID: Lines: 14 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Didier Verna writes: > True, but that doesn't make it a good argument *not* to change the > order. Of course. I just wanted to prevent changing something that works for frivolous reasons. However: > There are more important problems, like starting packages from the > init files, resulting in customizations not being set up when the > package is run. I agree that it is a good reason. Maybe we should, for additional safety, ask Per Abrahamsen what he thinks about the ordering change? From sperber@informatik.uni-tuebingen.de Tue May 15 05:58:52 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA02018 for ; Tue, 15 May 2001 05:58:51 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 70FF3439 for ; Tue, 15 May 2001 11:58:40 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4F9wdZ00584; Tue, 15 May 2001 11:58:39 +0200 (CEST) (envelope-from sperber) To: xemacs-beta@xemacs.org Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 15 May 2001 11:58:39 +0200 In-Reply-To: (Hrvoje Niksic's message of "15 May 2001 11:31:21 +0200") Message-ID: Lines: 20 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Ben Wing writes: >> The custom init file is where the custom package writes its options. This >> obviously needs to be a separate file from the standard init file. It should >> also be loaded before the init file rather than after, as is usually done >> currently, so that the init file can override these options if it >> wants to. Hrvoje> Please don't change the order. Hrvoje> Init file can override Custom options although custom is loaded later. Hrvoje> Custom is much smarter than it looks. I can elaborate if you want. I'd appreciate it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From hniksic@arsdigita.com Tue May 15 06:12:08 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA02644 for ; Tue, 15 May 2001 06:12:07 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zboF-00016G-00 for ; Tue, 15 May 2001 12:12:07 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 12:12:07 +0200 In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "15 May 2001 11:58:39 +0200") Message-ID: Lines: 39 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> Init file can override Custom options although custom is loaded later. > Hrvoje> Custom is much smarter than it looks. I can elaborate if you want. > > I'd appreciate it. The following explanation only elaborates on why it is OK for custom-set-variables to be executed after .emacs. It does not argue that it shouldn't be executed before. custom-set-variables differs from an ordinary `setq' in your .emacs in that it doesn't set the value of any of the variables. They merely store the Lisp expression that is to calculate the value into a property of the symbol. Only when the `defcustom' form is evaluated, this property gets evaluated too, and stored to the symbol's value slot. This is important because it allows "dependent" things to work. For instance, if you have: (defcustom foo 3 ...) (defcustom bar (* foo 5) ; default ...) Then, if you customize `foo' to 4 and don't touch bar, `bar' will be correctly set to 20. Regardless of all this, `defcustom' retains the important property of `defvar' which is that it doesn't touch the value of variables which are bound (already have a value). So if you say: (setq foo 132) then the custom-set-variables will still set the property, but defcustom will *not* change the value. That's how the Customize buffer knows that a value has been "modified outside customize". From didier@lrde.epita.fr Tue May 15 06:14:15 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA02726 for ; Tue, 15 May 2001 06:14:13 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id MAA20696 Tue, 15 May 2001 12:12:03 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 14zbnq-0006eH-00; Tue, 15 May 2001 12:11:42 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 14zbn0-0006jr-00; Tue, 15 May 2001 12:10:50 +0200 To: Hrvoje Niksic Cc: XEmacs Beta List , Ben Wing Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (Hrvoje Niksic's message of "15 May 2001 11:51:49 +0200") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 15 May 2001 12:10:50 +0200 Message-ID: Lines: 32 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id GAA02726 Hrvoje Niksic wrote: > Didier Verna writes: > > > True, but that doesn't make it a good argument *not* to change the > > order. > > Of course. I just wanted to prevent changing something that works for > frivolous reasons. However: > > > There are more important problems, like starting packages from the > > init files, resulting in customizations not being set up when the > > package is run. > > I agree that it is a good reason. Maybe we should, for additional > safety, ask Per Abrahamsen what he thinks about the ordering change? Yup. I still can see an argument one could raise against changing the order: - with the current order, you can 1/ change the custom file name and 2/ load it before (the rest of) the init file (in order words, swap the order). - with the opposite order, you can do neither of these. Actually, you probably could, if we provided command line options for doing that. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From hniksic@arsdigita.com Tue May 15 06:18:45 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA02928 for ; Tue, 15 May 2001 06:18:45 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zbue-00017w-00; Tue, 15 May 2001 12:18:44 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Cc: Ben Wing Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 12:18:44 +0200 In-Reply-To: (Didier Verna's message of "15 May 2001 12:10:50 +0200") Message-ID: Lines: 8 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Didier Verna writes: > - with the current order, you can 1/ change the custom file name and 2/ load > it before (the rest of) the init file (in order words, swap the > order). 3/ choose to not load it at all, dependent on the phase of the moon (and without having to use a command-line option.) From ben@666.com Tue May 15 07:10:32 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id HAA05412 for ; Tue, 15 May 2001 07:10:31 -0400 Received: (qmail 80923 invoked by alias); 15 May 2001 11:10:29 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 80862 invoked by uid 0); 15 May 2001 11:10:28 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 15 May 2001 11:10:28 -0000 Message-ID: <3B010EFE.FB0B99E@666.com> Date: Tue, 15 May 2001 04:11:58 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Didier Verna CC: Hrvoje Niksic , XEmacs Beta List Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit you guys should read my http://www.xemacs.org/Architecting-XEmacs/init-files.html. i talk about rearranging things to fix a whole lot of problems [e.g. loading the init file *before* mapping the first frame], and allow for many things that are currently impossible. but as for your arguments below, the fact that you *can* rearrange to fix problems doesn't change the fact that the default is wrong for 99% of the users. the rest can use a command-line argument [or my pre-init mechanism, mentioned in that file above -- if and when it ever gets implemented]. furthermore, your args aren't even correct. you can always put your own elisp in custom.el -- custom will preserve it no problem when saving out its values. so with the switched order, you can 1/ force the init file to be loaded first, 2/ change its name, or 3/ not load it at all -- something you can't currently do except with command-line args. [sorry, i had to do it :-] Didier Verna wrote: > > Hrvoje Niksic wrote: > > > Didier Verna writes: > > > > > True, but that doesn't make it a good argument *not* to change the > > > order. > > > > Of course. I just wanted to prevent changing something that works for > > frivolous reasons. However: > > > > > There are more important problems, like starting packages from the > > > init files, resulting in customizations not being set up when the > > > package is run. > > > > I agree that it is a good reason. Maybe we should, for additional > > safety, ask Per Abrahamsen what he thinks about the ordering change? > > Yup. I still can see an argument one could raise against changing the > order: > > - with the current order, you can 1/ change the custom file name and 2/ load > it before (the rest of) the init file (in order words, swap the order). > > - with the opposite order, you can do neither of these. > Actually, you probably could, if we provided command line options for doing > that. > > -- > Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier > > EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 > 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From steve@turnbull.sk.tsukuba.ac.jp Tue May 15 07:38:59 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA06805 for ; Tue, 15 May 2001 07:38:57 -0400 Received: by localhost id m14zdAC-00014iC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 15 May 2001 20:38:52 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15105.5433.280355.151052@turnbull.sk.tsukuba.ac.jp> Date: Tue, 15 May 2001 20:38:33 +0900 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el In-Reply-To: References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> The following explanation only elaborates on why it is OK Hrvoje> for custom-set-variables to be executed after .emacs. It Hrvoje> does not argue that it shouldn't be executed before. Unfortunately, custom-set-faces is not so polite. I've never understood why custom-set-faces considers it OK to automatically and silently reset, that is, clear, specifiers, especially for the default face. In 21.4.2 it _still_ trashes any setting the user makes for Asian fonts in the init file unless the incantation is exactly right (and this is nowhere documented as of three months ago, and changes occasionally). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From hniksic@arsdigita.com Tue May 15 07:59:51 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA07978 for ; Tue, 15 May 2001 07:59:50 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zdTo-0001SA-00; Tue, 15 May 2001 13:59:08 +0200 Sender: hniksic@florida.arsdigita.de To: "Stephen J. Turnbull" Cc: XEmacs Beta List Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> <15105.5433.280355.151052@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 13:59:08 +0200 In-Reply-To: <15105.5433.280355.151052@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Tue, 15 May 2001 20:38:33 +0900") Message-ID: Lines: 12 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: > Unfortunately, custom-set-faces is not so polite. I know. :-( > I've never understood why custom-set-faces considers it OK to > automatically and silently reset, that is, clear, specifiers, > especially for the default face. Because it's buggy. Even worse, it resets the properties that it doesn't even know about. From nbecker@hns.com Tue May 15 09:02:01 2001 Received: from adglinux1.hns.com (adglinux1.hns.com [139.85.108.152]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA11454 for ; Tue, 15 May 2001 09:02:01 -0400 Received: from nbecker by adglinux1.hns.com with local (Exim 3.22 #1) id 14zdVs-0005sV-00 for xemacs-beta@xemacs.org; Tue, 15 May 2001 08:01:16 -0400 To: xemacs-beta@xemacs.org Subject: Can't update packages From: nbecker@fred.net Date: 15 May 2001 08:01:16 -0400 Message-ID: Lines: 5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: I can't update packages for last 2 days. I get this: Package xemacs-base-1.53-pkg.tar.gz does not match md5 checksum This is released packages, not pre-release. From monnier+lists.xemacs.beta/news/@RUM.cs.yale.edu Tue May 15 10:29:20 2001 Received: from tequila.cs.yale.edu (tequila.cs.yale.edu [128.36.229.152]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA17078 for ; Tue, 15 May 2001 10:29:16 -0400 Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.11.0/8.9.3) with SMTP id f4FETC219508 for ; Tue, 15 May 2001 10:29:12 -0400 To: xemacs-beta@xemacs.org Sender: monnier@RUM.cs.yale.edu From: "Stefan Monnier" Newsgroups: lists.xemacs.beta Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> Date: 15 May 2001 10:29:07 -0400 Message-ID: <5lsni6ptxo.fsf@rum.cs.yale.edu> Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Path: rum.cs.yale.edu NNTP-Posting-Host: rum.cs.yale.edu X-Trace: 15 May 2001 10:29:07 -0400, rum.cs.yale.edu >>>>> "Hrvoje" == Hrvoje Niksic writes: > Only when the `defcustom' form is evaluated, this property gets evaluated > too, and stored to the symbol's value slot. This is important because it > allows "dependent" things to work. For instance, if you have: > (defcustom foo 3 > ...) > (defcustom bar (* foo 5) ; default > ...) > Then, if you customize `foo' to 4 and don't touch bar, `bar' will be > correctly set to 20. I must be dense, because it seems to me that it would work just as well with `setq'. I.e. if I do (setq foo 4), the above piece of code will first not-do-anything with foo and then set bar to 20. So in what situation does the order really matter ? Of course, it matters if you do (custom-set-variables '((bar (* foo 6)))), but I don't think I've ever seen anyone do that, and I'm not even sure if custom could generate such a statement (as opposed to someone writing it manually). Stefan From hniksic@arsdigita.com Tue May 15 10:37:54 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA17549 for ; Tue, 15 May 2001 10:37:54 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zfxR-0001xc-00 for ; Tue, 15 May 2001 16:37:53 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> <5lsni6ptxo.fsf@rum.cs.yale.edu> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 16:37:53 +0200 In-Reply-To: <5lsni6ptxo.fsf@rum.cs.yale.edu> ("Stefan Monnier"'s message of "15 May 2001 10:29:07 -0400") Message-ID: Lines: 8 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stefan Monnier" writes: > So in what situation does the order really matter ? > Of course, it matters if you do (custom-set-variables '((bar (* foo 6)))), > but I don't think I've ever seen anyone do that, and I'm not even sure > if custom could generate such a statement State->Edit as Lisp Expression From xemacs-announce-admin@xemacs.org Tue May 15 11:43:16 2001 Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA22043; Tue, 15 May 2001 11:43:14 -0400 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14zgtf-0000NY-00; Tue, 15 May 2001 08:38:03 -0700 Received: from gwyn.tux.org ([207.96.122.8]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14zgtO-0000Jf-00 for ; Tue, 15 May 2001 08:37:47 -0700 Received: (from jason@localhost) by gwyn.tux.org (8.9.3/8.9.1) id LAA21601; Tue, 15 May 2001 11:37:34 -0400 Date: Wed, 16 May 2001 04:37:34 +1300 (PHOT) From: XEmacs Webmaster To: xemacs-announce@xemacs.org Subject: New Website Mirror in Finland Message-ID: <20010516043734.A21418@xemacs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: xemacs-announce-admin@xemacs.org Errors-To: xemacs-announce-admin@xemacs.org X-BeenThere: xemacs-announce@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Announcements List-Unsubscribe: , We have added a mirror of the XEmacs website in Finland thanks to Pietu Pohjalainen: Enjoy. From baz@barriebremner.com Tue May 15 13:17:09 2001 Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA27120 for ; Tue, 15 May 2001 13:17:09 -0400 Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14ziRT-0003EI-00 for xemacs-beta@xemacs.org; Tue, 15 May 2001 18:17:03 +0100 Received: from modem-104.ciryon.dialup.pol.co.uk ([62.136.148.104] helo=flux.localdomain) by mail17.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14ziRS-0007vr-00 for xemacs-beta@xemacs.org; Tue, 15 May 2001 18:17:02 +0100 Received: (qmail 20792 invoked by uid 500); 15 May 2001 17:16:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15105.25735.312201.601799@flux.localdomain> Date: Tue, 15 May 2001 18:16:55 +0100 From: Barrie Bremner To: xemacs-beta@xemacs.org Subject: Re: Back trace of 21.5-b1 "anise" crash In-Reply-To: <15104.55570.5198.530742@gargle.gargle.HOWL> References: <15102.59202.104536.906705@flux.localdomain> <3B00AB35.BB1655D9@666.com> <15104.55570.5198.530742@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Uptime: 1 week 3 days 46 minutes >>>>> "Martin" == Martin Buchholz writes: >>>>> "Ben" == Ben Wing writes: >>> (gdb) where #0 0x403c8801 in __kill () from >>> /lib/i686/libc.so.6 #1 0x080b453b in fatal_error_signal >>> (sig=11) at emacs.c:535 #2 #3 >>> 0x080911b3 in bytecode_arithop (obj1=25, obj2=0, opcode=Bplus) >>> at bytecode.c:387 Ben> very strange. `25' and `0' look like numbers that somehow Ben> failed to get make_int[]ized. Ben> martin, this is your area of expertise. Ben> thoughts? Martin> It looks to me like we have a Lisp_Object that is all Martin> zeros. That should never happen. The most likely reason Martin> is that there is a bug (elsewhere!) that is causing memory Martin> corruption of the stack. Most likely a bug in a C Martin> function called from the currently active lisp function. Martin> There is a chance you can get a lisp backtrace from a C Martin> debugger - see src/.gdbinit. Anything I can try/do/remember now, or if this happens again? Step by step idiots guide only please - suggesting I run the slapcrackboozleomatic test (or whatever) will make me cry :-) Cheers. Baz. -- Barrie J. Bremner OpenPGP public key ID: 5164F553 baz [at] barriebremner.com http://barriebremner.com/ From andyp@bea.com Tue May 15 14:27:59 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA31184 for ; Tue, 15 May 2001 14:27:54 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA17345 for ; Tue, 15 May 2001 11:27:59 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id KAA20266 for ; Tue, 15 May 2001 10:56:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 May 2001 10:57:30 -0700 To: xemacs-beta@xemacs.org From: Andy Piper Subject: Why does isearch do this [Hrvoje :)]? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This has bugged me forever about 21.2/4. Do C-i Type something to search. When you find it hit C-a Then do: C-i C-i isearch then searches for the thing you looked for *before* the thing you just found instead of searching for the same string again. Its *really* annoying. andy From colin@xemacs.org Tue May 15 15:32:39 2001 Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA02632 for ; Tue, 15 May 2001 15:32:39 -0400 Received: from pivsbh2-idmz.ms.com (localhost [127.0.0.1]) by pivsbh2.ms.com (Postfix) with SMTP id 71BD1FD0 for ; Tue, 15 May 2001 15:32:35 -0400 (EDT) Received: from hqfid1.morgan.com (unknown [144.14.36.134]) by pivsbh2-idmz.ms.com (Postfix) with ESMTP id 5554EFCB for ; Tue, 15 May 2001 15:32:35 -0400 (EDT) Received: from hqgcs1.morgan.com (hqgcs1.morgan.com [144.14.232.79]) by hqfid1.morgan.com (8.8.5/hub+ldap v2.4) with ESMTP id PAA04914 for ; Tue, 15 May 2001 15:32:35 -0400 (EDT) Received: (craffert@localhost) by hqgcs1.morgan.com (SGI-8.9.3/sendmail.cf.client v1.05) id TAA14521; Tue, 15 May 2001 19:32:34 GMT X-Authentication-Warning: hqgcs1.morgan.com: craffert set sender to colin@xemacs.org using -f To: XEmacs Beta List Subject: Re: Why does isearch do this [Hrvoje :)]? Keywords: c-i References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> From: Colin Rafferty Mail-Copies-To: never X-Face: y,o:AU/bfCrS+zS/W"^puB!rT!G7?U1Mvp1Hd{6h^>X4@Xp5,|g+rG>4gv/iy^&x9`k#s!]X~{]Js>@A4c}4Z"Ct7=#1nPS:?mrWH8c#>$)>/Wc5yuX_OFO1(4cZM{LvsKWVQSl~/i>!n[-B*i-alq[/m\bsdy;W4p(_ic;$BE.oG@eJf@sr#x#}FT<=H8Ozu%g;JpVz:v_~vt[>ef/MeNeo3~D^R]]*bB7{HB|E1$wfMzw X-Y-Zippy: Fold, fold, FOLD!! FOLDING many items!! Date: 15 May 2001 15:32:34 -0400 In-Reply-To: Andy Piper's message of "Tue, 15 May 2001 10:57:30 -0700" Message-ID: Lines: 27 User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Andy Piper writes: > Do > C-i > Type something to search. When you find it hit > C-a > Then do: > C-i C-i > isearch then searches for the thing you looked for *before* the thing > you just found instead of searching for the same string again. By default C-i `indent-for-tab-command', so maybe it is your strange key bindings. When I use C-s instead of C-i, I don't have your problems. (emacs-version) "XEmacs 21.5 (beta0) \"alfalfa\" [Lucid] (mips-sgi-irix6.5) of Tue May 1 2001 on hqgcs1" -- Colin From hniksic@arsdigita.com Tue May 15 15:37:17 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA02829 for ; Tue, 15 May 2001 15:37:13 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zkd5-0002yo-00 for ; Tue, 15 May 2001 21:37:11 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Why does isearch do this [Hrvoje :)]? References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 15 May 2001 21:37:11 +0200 In-Reply-To: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> (Andy Piper's message of "Tue, 15 May 2001 10:57:30 -0700") Message-ID: Lines: 24 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Andy Piper writes: > This has bugged me forever about 21.2/4. > > Do > > C-i > > Type something to search. When you find it hit > > C-a > > Then do: > > C-i C-i > > isearch then searches for the thing you looked for *before* the thing > you just found instead of searching for the same string again. Its > *really* annoying. I'm totally confused. Did you bind C-i to isearch or something? Even if I replace C-i with C-s, I simply don't see what you see... For me it works the way it should. From andyp@bea.com Tue May 15 16:12:23 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA05138; Tue, 15 May 2001 16:12:22 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA09160; Tue, 15 May 2001 13:12:28 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id NAA21130; Tue, 15 May 2001 13:12:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20010515131250.00d2b980@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 May 2001 13:13:04 -0700 To: Colin Rafferty From: Andy Piper Subject: Re: Why does isearch do this [Hrvoje :)]? Cc: xemacs-beta@xemacs.org In-Reply-To: References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sorry C-s I mean andy At 03:32 PM 5/15/01 -0400, you wrote: >Andy Piper writes: > > > Do > > > C-i > > > Type something to search. When you find it hit > > > C-a > > > Then do: > > > C-i C-i > > > isearch then searches for the thing you looked for *before* the thing > > you just found instead of searching for the same string again. > >By default C-i `indent-for-tab-command', so maybe it is your strange >key bindings. > >When I use C-s instead of C-i, I don't have your problems. > >(emacs-version) >"XEmacs 21.5 (beta0) \"alfalfa\" [Lucid] (mips-sgi-irix6.5) of Tue May 1 >2001 on hqgcs1" > >-- >Colin From andyp@bea.com Tue May 15 16:15:01 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA05235 for ; Tue, 15 May 2001 16:15:01 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA09721; Tue, 15 May 2001 13:15:07 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id NAA21843; Tue, 15 May 2001 13:15:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 May 2001 13:15:43 -0700 To: Hrvoje Niksic , XEmacs Beta List From: Andy Piper Subject: Re: Why does isearch do this [Hrvoje :)]? In-Reply-To: References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed C-s I mean. What happens if you try it under windows? andy At 09:37 PM 5/15/01 +0200, Hrvoje Niksic wrote: >Andy Piper writes: > > > This has bugged me forever about 21.2/4. > > > > Do > > > > C-i > > > > Type something to search. When you find it hit > > > > C-a > > > > Then do: > > > > C-i C-i > > > > isearch then searches for the thing you looked for *before* the thing > > you just found instead of searching for the same string again. Its > > *really* annoying. > >I'm totally confused. Did you bind C-i to isearch or something? > >Even if I replace C-i with C-s, I simply don't see what you see... >For me it works the way it should. From Adrian.Aichner@t-online.de Tue May 15 17:16:35 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA08770 for ; Tue, 15 May 2001 17:16:32 -0400 Received: from fwd05.sul.t-online.de by mailout06.sul.t-online.com with smtp id 14zmBG-0000TL-08; Tue, 15 May 2001 23:16:34 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.89]) by fwd05.sul.t-online.com with esmtp id 14zmBU-14jNrMC; Tue, 15 May 2001 23:16:48 +0200 To: nbecker@fred.net Cc: xemacs-beta@xemacs.org Subject: Re: Can't update packages References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "nbecker" == nbecker writes: nbecker> I can't update packages for last 2 days. I get this: nbecker> Package xemacs-base-1.53-pkg.tar.gz does not match md5 checksum Do you have an old package in package-get-dir Try (re)moving them before you try a new install. Try setting package-get-remove-copy to t. Remove the old package first, then install the new one. Adrian nbecker> This is released packages, not pre-release. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From nbecker@hns.com Tue May 15 18:01:59 2001 Received: from adglinux1.hns.com (adglinux1.hns.com [139.85.108.152]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA11226 for ; Tue, 15 May 2001 18:01:59 -0400 Received: from nbecker by adglinux1.hns.com with local (Exim 3.22 #1) id 14zl8n-0006kP-00 for xemacs-beta@xemacs.org; Tue, 15 May 2001 16:09:57 -0400 To: xemacs-beta@xemacs.org Subject: unrecognized selection-conversion type From: nbecker@fred.net Date: 15 May 2001 16:09:57 -0400 Message-ID: Lines: 47 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: unrecognized selection-conversion type: nil, # unrecognized selection-conversion type: nil, # uname -a: Linux porky.devel.redhat.com 2.2.17-8smp #1 SMP Fri Nov 17 16:12:17 EST 2000 i686 unknown ./configure 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--datadir=/usr/share' '--libdir=/usr/lib' '--mandir=/usr/share/man/man1' '--infodir=/usr/share/info' '--with-gpm=no' '--with-sound=native' '--with-pop' '--mail-locking=lockf' '--with-clash-detection' '--debug=no' '--error-checking=none' '--lockdir=/var/lock/xemacs' '--with-mule=yes' '--with-database=no' '--with-ldap=yes' '--with-hesiod=no' '--with-menubars=lucid' '--with-scrollbars=lucid' '--with-dialogs=athena3d' '--with-xim=xlib' '--with-canna=yes' '--with-wnn=yes' '--with-wnn6=yes' '--with-msw=no' '--with-xfs=yes' XEmacs 21.1.14 "Cuyahoga Valley" configured for `i386-redhat-linux-gnu'. Where should the build process find the source code? /usr/src/bs/BUILD/xemacs-21.1.14 What installation prefix should install use? /usr What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -O2 -march=i386 -mcpu=i686 Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in native sound support. Compiling in support for LDAP. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Using WNN version 6. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. Clash detection will use "/var/lock/xemacs" for locking files. movemail will use "lockf" for locking mail spool files. Using POP for mail access Using Lisp_Objects with minimal tagbits. From ysh@mindspring.com Tue May 15 18:21:36 2001 Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA12544; Tue, 15 May 2001 18:21:35 -0400 Received: from localhost.localdomain.mindspring.com (user-2iniiie.dialup.mindspring.com [165.121.74.78]) by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA08921; Tue, 15 May 2001 18:21:29 -0400 (EDT) Message-Id: <200105152221.SAA08921@barry.mail.mindspring.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 May 2001 18:23:20 -0400 From: Isaac Hollander To: Ben Wing Cc: Isaac Hollander , "William M. Perry" , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes In-Reply-To: <3B00A94B.BC0695FE@666.com> References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Ben> can you get a c backtrace? Ben> the fact that the first line is >> ding(nil buffer-bound) Ben> suggests a problem with the audio support, not the mousewheel. Indeed. I built --with-sound=native,noesd and no matter how hard I tried, moving the mouse to the top or bottom of the buffer and causing lots of sound events doesn't make XEmacs crash. How stable is esd sound support? Should it be autodetected to true by default? If I try hard enough (generating enough random mouse button events), I can get XEmacs into a state where any mouse button click results in "button[12345] not recognized" messages, as appropriate. C-g resets things so that mouse button works again. Unfortunately, I don't understand X enough to debug this further. Isaac From CraigL@Knology.net Tue May 15 20:48:18 2001 Received: from smtp3.knology.net (user-24-214-63-13.knology.net [24.214.63.13]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id UAA19604 for ; Tue, 15 May 2001 20:48:14 -0400 Message-Id: <200105160048.UAA19604@gwyn.tux.org> Received: (qmail 7006 invoked from network); 16 May 2001 00:45:10 -0000 Received: from user-24-214-22-213.knology.net (24.214.22.213) by user-24-214-63-13.knology.net with SMTP; 16 May 2001 00:45:10 -0000 Date: Tue, 15 May 2001 20:44:55 -0400 (Eastern Daylight Time) From: Craig Lanning Subject: Re[2]: Why does isearch do this [Hrvoje :)]? To: Andy Piper , hniksic@arsdigita.com, xemacs-beta@xemacs.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE In-Reply-To: <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com>, <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> X-Mailer: Mahogany, 0.62 'Mars', running under Windows 98 It works fine for me XEmacs 21.4 (patch 2) "Developer-Friendly Unix APIs" [Lucid] (i586-pc-mingw32) of Sat May 12 2001 on CRAIGL XEmacs 21.5 (beta1) "anise" [Lucid] (i586-pc-mingw32) of Sat May 12 2001 on CRAIGL Craig On Tue, 15 May 2001 13:15:43 -0700 Andy Piper wrote: > C-s I mean. What happens if you try it under windows? > > andy > > At 09:37 PM 5/15/01 +0200, Hrvoje Niksic wrote: > >Andy Piper writes: > > > > > This has bugged me forever about 21.2/4. > > > > > > Do > > > > > > C-i > > > > > > Type something to search. When you find it hit > > > > > > C-a > > > > > > Then do: > > > > > > C-i C-i > > > > > > isearch then searches for the thing you looked for *before* the thing > > > you just found instead of searching for the same string again. Its > > > *really* annoying. > > > >I'm totally confused. Did you bind C-i to isearch or something? > > > >Even if I replace C-i with C-s, I simply don't see what you see... > >For me it works the way it should. > > > From yamaoka@jpl.org Wed May 16 01:15:51 2001 Received: from jpl.org (clients.web-hosting.com [207.228.244.9] (may be forged)) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA32169 for ; Wed, 16 May 2001 01:15:42 -0400 Received: from yamaoka@jpl.org by jpl.org (jpl.org [207.228.245.242]) (8.11.1/8.11.1) id f4G5FZN24871 Wed, 16 May 2001 14:15:35 +0900 (JST) Date: 16 May 2001 14:15:23 +0900 Message-ID: From: Katsumi Yamaoka To: xemacs-beta@xemacs.org Subject: Can't display GIF Anime Organization: Emacsen advocacy group MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) (revision 01) XEmacs/21.5 (beta1) (anise) (sparc-sun-solaris2.6) WEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNmJDKxsoQg==?=) CLIME/1.14.0 (=?ISO-2022-JP?B?GyRCOF40VkYyGyhC?=) APEL/10.3 Hi, It seems that XEmacs both 21.4 and 21.5 cannot display animated GIFs. Isn't this implemented yet? The default value of `disable-animated-pixmaps' is nil even though the doc-string says "Default is t". -- Katsumi Yamaoka From yamaoka@jpl.org Wed May 16 01:46:42 2001 Received: from jpl.org (clients.web-hosting.com [207.228.244.9] (may be forged)) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA01150 for ; Wed, 16 May 2001 01:46:42 -0400 Received: from yamaoka@jpl.org by jpl.org (jpl.org [207.228.245.242]) (8.11.1/8.11.1) id f4G5kfV27063 Wed, 16 May 2001 14:46:41 +0900 (JST) Date: 16 May 2001 14:46:29 +0900 Message-ID: From: Katsumi Yamaoka To: xemacs-beta@xemacs.org Subject: Re: Can't display GIF Anime Organization: Emacsen advocacy group References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) (revision 01) XEmacs/21.5 (beta1) (anise) (sparc-sun-solaris2.6) WEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNmJDKxsoQg==?=) CLIME/1.14.0 (=?ISO-2022-JP?B?GyRCOF40VkYyGyhC?=) APEL/10.3 Oops, I must apologize that some animated GIFs are displayed but some are not. You may see them in http://www.asahi.com/. >>>>> In >>>>> Katsumi Yamaoka wrote: > It seems that XEmacs both 21.4 and 21.5 cannot display animated > GIFs. Isn't this implemented yet? The default value of > `disable-animated-pixmaps' is nil even though the doc-string > says "Default is t". -- Katsumi Yamaoka From Aki.Vehtari@hut.fi Wed May 16 04:07:05 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA07011 for ; Wed, 16 May 2001 04:07:00 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4G86x602449 for ; Wed, 16 May 2001 11:06:59 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4G86wV04213; Wed, 16 May 2001 11:06:58 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC References: From: Aki Vehtari In-Reply-To: Date: 16 May 2001 11:06:58 +0300 Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Aki" == Aki Vehtari writes 2001-04-25: Aki> I configured with --cppflags=-DREGEX_MALLOC but... Aki> gcc -c -O3 -I. -I../src -I/proj/ave/xemacs/xemacs-21.4.0/lib-src -I/proj/ave/xemacs/xemacs-21.4.0/src -DREGEX_MALLOC -DHAVE_CONFIG_H -I/usr/local/include \ Aki> -DINHIBIT_STRING_HEADER /proj/ave/xemacs/xemacs-21.4.0/src/regex.c Aki> /proj/ave/xemacs/xemacs-21.4.0/src/regex.c: In function `sys_re_compile_fastmap': Aki> /proj/ave/xemacs/xemacs-21.4.0/src/regex.c:3412: `DECLARE_NOTHING' undeclared (first use this function) Oh well, as no-one have looked into this yet, today I finally had time myself to investigate this. Problem is that DECLARE_NOTHING is undeclared, although lisp.h, which defines it, is included. I copied following lines from lisp.h ---Clip--- #ifndef DECLARE_NOTHING #define DECLARE_NOTHING struct nosuchstruct #endif ---Clip--- to regex.c, just before DECALRE_NOTHING is first time used, and now I it compiled. As I can't find reason why DECALRE_NOTHING is not defined, although lisp.h, which defines it, is included, I hope that someone more familiar with this part of the code would check where the problem really is. Btw, I also think that REGEX_MALLOC should be defined by default for Digital UNIX. Aki From rendhalver@users.sourceforge.net Wed May 16 04:08:57 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA07073; Wed, 16 May 2001 04:08:54 -0400 Received: from ulthwe.dyndns.org (p44-tnt1.brs.ihug.com.au [203.173.188.44]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id SAA04111; Wed, 16 May 2001 18:08:43 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p44-tnt1.brs.ihug.com.au [203.173.188.44] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15106.13565.489651.38488@ulthwe.dyndns.org> Date: Wed, 16 May 2001 18:06:21 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 10 In-Reply-To: References: <15098.11302.47725.672028@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Steve Youngs writes: > |--==> "PB" == Peter Brown writes: sorry for late reply bee awar for a bit > PB> Steve Youngs writes: > >>I've just uploaded the following updated packages to the > >>'Pre-Releases' directory: > > PB> these all installed without a hitch with xemacs-21.5.1 on my RH 7.0 linux box :) > > That's great. Thanks for letting me know. will continue to as new stuff comes in :) > PB> but i had a problem with installing leim-1.17 > PB> was trying to install it (first time i have) and i go this error > > PB> package leim-1.17-pkg.tar.gz does not match md5 checksum > > I just installed it here (via xemacs.org), no error. > > Which site did you get it from? tried to install from xemacs.org i believe i've stopped playing with mule stuff for a bit will try again and let you know -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From Aki.Vehtari@hut.fi Wed May 16 04:34:14 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA08353 for ; Wed, 16 May 2001 04:34:13 -0400 Received: from biton.lce.hut.fi (biton.lce.hut.fi [130.233.245.227]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4G8YC603533 for ; Wed, 16 May 2001 11:34:12 +0300 (EET DST) Received: (from ave@localhost) by biton.lce.hut.fi (8.9.3/8.9.3) id LAA18099; Wed, 16 May 2001 11:34:12 +0300 (EET DST) X-Authentication-Warning: biton.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: [BUG] term freezes on XEmacs 21.4.* on *-dec-osf* Mail-Copies-To: never From: Aki Vehtari Date: 16 May 2001 11:34:12 +0300 Message-ID: Lines: 78 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii When larger text is inserted to term (or matlab-shell) it freezes on XEmacs 21.4.* (ev56|ev6|ev67)-dec-osf(4.0d|4.0f|5.0) On XEmacs 21.1.* term (or matlab-shell) does not freeze like this. How to reproduce the problem: --- xemacs -vanilla M-x term echo foooooooooooooooooooooooooooooooooooooooooooo echo foooooooooooooooooooooooooooooooooooooooooooo echo foooooooooooooooooooooooooooooooooooooooooooo echo foooooooooooooooooooooooooooooooooooooooooooo echo foooooooooooooooooooooooooooooooooooooooooooo echo foooooooooooooooooooooooooooooooooooooooooooo --- Below is example Installation description. Note that same problem appears with and without REGEX_MALLOC. --- uname -a: OSF1 biton.lce.hut.fi V4.0 1229 alpha alpha /proj/ave/xemacs/xemacs-21.4.2/configure '--prefix=/proj/ave/xemacs/' '--srcdir=/proj/ave/xemacs/xemacs-21.4.2' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--cppflags=-DREGEX_MALLOC' XEmacs 21.4.2 "Developer-Friendly Unix APIs" configured for `alphaev67-dec-osf4.0f'. Compilation / Installation: Source code location: /proj/ave/xemacs/xemacs-21.4.2 Installation prefix: /proj/ave/xemacs/ Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib:/usr/dt/lib Operating system description file: `s/decosf4-0.h' Machine description file: `m/alpha.h' Compiler: cc -O3 Relocating allocator for buffers: yes GNU version of malloc: yes Window System: Compiling in support for the X window system: - X Windows headers location: /usr/dt/include - X Windows libraries location: /usr/dt/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Sound: Databases: Compiling in support for Berkeley database. Compiling in support for DBM. Internationalization: Mail: Compiling in support for "flock" mail spool file locking method. Other Features: Compiling in support for ToolTalk. Compiling in support for dynamic shared object modules. From rendhalver@users.sourceforge.net Wed May 16 04:44:50 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA08886; Wed, 16 May 2001 04:44:46 -0400 Received: from ulthwe.dyndns.org (p44-tnt1.brs.ihug.com.au [203.173.188.44]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id SAA10049; Wed, 16 May 2001 18:44:42 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p44-tnt1.brs.ihug.com.au [203.173.188.44] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15106.15725.587706.152468@ulthwe.dyndns.org> Date: Wed, 16 May 2001 18:42:21 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 12 In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Steve Youngs writes: > The following packages have been updated and put into the > "Pre-Releases" directory: > > cc-mode-1.25-pkg.tar.gz > ======================= > > efs-1.23-pkg.tar.gz > =================== > > mule-base-1.38-pkg.tar.gz > ========================= > > xemacs-devel-1.34-pkg.tar.gz > ============================ > > net-utils-1.16-pkg.tar.gz > ========================= these all worked on my RH 7.0 linux box with xemacs 21.5.1 -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From steve@turnbull.sk.tsukuba.ac.jp Wed May 16 05:10:28 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA09996 for ; Wed, 16 May 2001 05:10:27 -0400 Received: by localhost id m14zxJu-000143C (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 16 May 2001 18:10:14 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> Date: Wed, 16 May 2001 18:09:57 +0900 To: Aki Vehtari Cc: xemacs-beta@xemacs.org Subject: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Ave" == Aki Vehtari writes: Aki> gcc -c -O3 -I. -I../src -I/proj/ave/xemacs/xemacs-21.4.0/lib-src Ave> Problem is that DECLARE_NOTHING is undeclared, although Ave> lisp.h, which defines it, is included. lisp.h isn't included when compiling for lib-src (eg, etags). I will probably work up a patch and add this to src/regex.c as you suggest, but along with other declarations that are needed when lisp.h doesn't get included. Ave> Btw, I also think that REGEX_MALLOC should be defined by Ave> default for Digital UNIX. I don't know about this; can you explain more? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From hniksic@arsdigita.com Wed May 16 06:08:54 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA12155 for ; Wed, 16 May 2001 06:08:54 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zyE7-0005ku-00; Wed, 16 May 2001 12:08:19 +0200 Sender: hniksic@florida.arsdigita.de To: Andy Piper Cc: XEmacs Beta List Subject: Re: Why does isearch do this [Hrvoje :)]? References: <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 16 May 2001 12:08:19 +0200 In-Reply-To: <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> (Andy Piper's message of "Tue, 15 May 2001 13:15:43 -0700") Message-ID: Lines: 12 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Andy Piper writes: > C-s I mean. What happens if you try it under windows? I don't do Windows. But apparently it works for Craig. Let's go the standard debugging route. Does it misbehave the same way when you invoke `xemacs -vanilla'? How about a clean XEmacs build fresh from the tarball? In the brave world of CVS and multiple workspaces it's easy to get stranded with a broken version of . From hniksic@arsdigita.com Wed May 16 07:08:31 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA14592 for ; Wed, 16 May 2001 07:08:31 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 14zyXS-0005p9-00 for ; Wed, 16 May 2001 12:28:18 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 16 May 2001 12:28:18 +0200 In-Reply-To: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Wed, 16 May 2001 18:09:57 +0900") Message-ID: Lines: 19 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: > Ave> Btw, I also think that REGEX_MALLOC should be defined by > Ave> default for Digital UNIX. > > I don't know about this; can you explain more? I do. Digital Unix has a small default for stack segment, so XEmacs crashes in regexp-heavy Lisp apps like Gnus and possibly font-lock. The solution is to either increase the stack size with `ulimit', or to make things work by default by defining REGEX_MALLOC, which makes regexp.c use malloc rather than alloca. Defining REGEX_MALLOC is not a perfect solution, though, because some people suspect it to leak, and it makes regexps slower. Therefore: A third, and IMHO best, solution would be for XEmacs to raise its own stack size if it notices it to be too small. It's quite easy to do for someone who has access to a Digital Unix system. From andyp@bea.com Wed May 16 12:25:53 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA29972 for ; Wed, 16 May 2001 12:25:53 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA14171; Wed, 16 May 2001 09:25:54 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001274wss.beasys.com [192.168.6.105]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id IAA03163; Wed, 16 May 2001 08:55:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20010516085259.00af8760@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 May 2001 08:53:24 -0700 To: Katsumi Yamaoka , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Can't display GIF Anime In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:15 PM 5/16/01 +0900, Katsumi Yamaoka wrote: >It seems that XEmacs both 21.4 and 21.5 cannot display animated >GIFs. Isn't this implemented yet? The default value of >`disable-animated-pixmaps' is nil even though the doc-string >says "Default is t". Its implemented and used to work. andy From andyp@bea.com Wed May 16 12:47:31 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA31030 for ; Wed, 16 May 2001 12:47:30 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA24037; Wed, 16 May 2001 09:47:36 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001274wss.beasys.com [192.168.6.105]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA03839; Wed, 16 May 2001 09:00:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20010516085743.00b105b0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 May 2001 08:58:34 -0700 To: Hrvoje Niksic From: Andy Piper Subject: Re: Why does isearch do this [Hrvoje :)]? Cc: XEmacs Beta List In-Reply-To: References: <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Seems like something triggers it. It doesn't happen in a newly started XEmacs. Some sort of interaction with the kill-ring also as that sometimes seems to be the text thats searched for. andy At 12:08 PM 5/16/01 +0200, Hrvoje Niksic wrote: >Andy Piper writes: > > > C-s I mean. What happens if you try it under windows? > >I don't do Windows. But apparently it works for Craig. > >Let's go the standard debugging route. Does it misbehave the same way >when you invoke `xemacs -vanilla'? How about a clean XEmacs build >fresh from the tarball? > >In the brave world of CVS and multiple workspaces it's easy to get >stranded with a broken version of . From darrylo@soco.agilent.com Wed May 16 13:09:10 2001 Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA32174 for ; Wed, 16 May 2001 13:09:09 -0400 Received: from msgrel1.and.agilent.com (msgrel1.and.agilent.com [130.30.33.104]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id 3BCFA283; Wed, 16 May 2001 11:08:57 -0600 (MDT) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.and.agilent.com (Postfix) with ESMTP id 7F0B11AB; Wed, 16 May 2001 13:08:50 -0400 (EDT) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id KAA28109; Wed, 16 May 2001 10:08:49 -0700 (PDT) Message-Id: <200105161708.KAA28109@mina.soco.agilent.com> To: Andy Piper Cc: Emacs Beta List Subject: Re: Why does isearch do this [Hrvoje :)]? Reply-To: Darryl Okahata In-Reply-To: Your message of "Wed, 16 May 2001 08:58:34 PDT." <4.3.2.7.2.20010516085743.00b105b0@san-francisco.beasys.com> Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: text/plain; charset=US-ASCII Date: Wed, 16 May 2001 10:08:48 -0700 From: Darryl Okahata Andy Piper wrote: > Seems like something triggers it. It doesn't happen in a newly started > XEmacs. Are you sure it's not some autoload? > Some sort of interaction with the kill-ring also as that sometimes > seems to be the text thats searched for. Does the message log show any autoloads? -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From andyp@bea.com Wed May 16 13:36:35 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA01228 for ; Wed, 16 May 2001 13:36:35 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA05861; Wed, 16 May 2001 10:36:25 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001274wss.beasys.com [192.168.6.105]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id KAA29209; Wed, 16 May 2001 10:36:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20010516103352.00b04100@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 May 2001 10:34:01 -0700 To: Darryl Okahata From: Andy Piper Subject: Re: Why does isearch do this [Hrvoje :)]? Cc: Emacs Beta List In-Reply-To: <200105161708.KAA28109@mina.soco.agilent.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:08 AM 5/16/01 -0700, Darryl Okahata wrote: >Andy Piper wrote: > > > Seems like something triggers it. It doesn't happen in a newly started > > XEmacs. > > Are you sure it's not some autoload? Fairly sure. andy From Aki.Vehtari@hut.fi Wed May 16 15:10:38 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA06123 for ; Wed, 16 May 2001 15:10:37 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4GJAb629525 for ; Wed, 16 May 2001 22:10:37 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4GJAaW06932; Wed, 16 May 2001 22:10:36 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> From: Aki Vehtari In-Reply-To: Date: 16 May 2001 22:10:36 +0300 Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Hrvoje" == Hrvoje Niksic writes: Hrvoje> A third, and IMHO best, solution would be for XEmacs to raise its own Hrvoje> stack size if it notices it to be too small. It's quite easy to do Hrvoje> for someone who has access to a Digital Unix system. I think that once again Hrvoje is right. Althouh I have access to Digital Unix system I'm afraid that fix is not easy enough that I could do it, but I can try if no-one else will. For start, should the stack size be checked when starting XEmacs or can stack size be increased just when it has been exceeded? Aki From wmperry@aventail.com Wed May 16 15:46:17 2001 Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA07685 for ; Wed, 16 May 2001 15:46:17 -0400 Received: from slow.bp.aventail.com ([24.12.70.142]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010516194612.ERJE20888.femail18.sdc1.sfba.home.com@slow.bp.aventail.com>; Wed, 16 May 2001 12:46:12 -0700 Received: from sigh (hel.bp.aventail.com [192.168.0.19]) by slow.bp.aventail.com (8.9.3/8.9.3) with SMTP id OAA24225; Wed, 16 May 2001 14:41:20 -0500 Message-ID: <004301c0de6a$c4184b40$1300a8c0@bp.aventail.com> From: "William M. Perry" To: , "Aki Vehtari" References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC Date: Wed, 16 May 2001 19:46:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 > "Hrvoje" == Hrvoje Niksic writes: > Hrvoje> A third, and IMHO best, solution would be for XEmacs to raise its own > Hrvoje> stack size if it notices it to be too small. It's quite easy to do > Hrvoje> for someone who has access to a Digital Unix system. > > I think that once again Hrvoje is right. Althouh I have access to > Digital Unix system I'm afraid that fix is not easy enough that I > could do it, but I can try if no-one else will. For start, should > the stack size be checked when starting XEmacs or can stack size be > increased just when it has been exceeded? I'm not sure if you can raise the stack size once your program has started. I know that you can do it for threads on digital unix very simply. We could put code like this where appropriate. static int __check_stack_requirements(int necessary) { #ifdef RLIMIT_STACK struct rlimit rl; if (getrlimit(RLIMIT_STACK,&rl) == 0) { if (rl.rlim_cur >= necessary) { /* Everything will work just fine... */ return (0); } if (rl.rlim_max < necessary) { /* Maximum stack size is still too small... ** Should we just fail to start? */ return (-1); } rl.rlim_cur = necessary; if (setrlimit(RLIMIT_STACK, &rl)) { /* Error when setting new stack size... */ return (-1); } return (0); #else return (0); #endif } and then do something like: if (__check_stack_requirements(min_required_by_regex_c)) { stderr_out ("Your regexps will be hosed...\n"); abort(); } -bp From Adrian.Aichner@t-online.de Wed May 16 16:14:15 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA11022 for ; Wed, 16 May 2001 16:14:14 -0400 Received: from fwd04.sul.t-online.de by mailout06.sul.t-online.com with smtp id 1507gg-0004Qx-00; Wed, 16 May 2001 22:14:26 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.45.6]) by fwd04.sul.t-online.com with esmtp id 1507gj-0QJTAOC; Wed, 16 May 2001 22:14:29 +0200 To: XEmacs Beta List , Peter Mours Subject: [Peter Mours ] xemacs in HP-UX 11.0 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 90 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Sender: 520002458184-0001@t-dialin.net --=-=-= Does anyone here know about this problem? Peter, you will have to provide a bit more information. Send in the information obtained by M-x describe-installation Best regards, Adrian --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: peterm@riedlbauer.com Wed May 16 13:40:18 2001 Return-Path: Received: from gwyn.tux.org ([207.96.122.8]) by mailin02.sul.t-online.de with esmtp id 14zzdp-20rZtAa; Wed, 16 May 2001 13:38:57 +0200 Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA15473; Wed, 16 May 2001 07:37:03 -0400 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14zzby-0006yZ-00; Wed, 16 May 2001 04:37:02 -0700 Received: from gwyn.tux.org ([207.96.122.8] ident=ident-user) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 14zzbA-0006mD-00 for ; Wed, 16 May 2001 04:36:12 -0700 Received: (from xemacweb@localhost) by gwyn.tux.org (8.9.3/8.9.1) id HAA15439 for xemacs-webmaint@xemacs.org; Wed, 16 May 2001 07:36:11 -0400 Received: from post.riedlbauer.com (mail.riedlbauer.com [213.68.15.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA15432 for ; Wed, 16 May 2001 07:36:10 -0400 Received: from riedlbauer.com (PC001706.riedlbauer.com [192.168.14.26]) by post.riedlbauer.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KGF2RT0N; Wed, 16 May 2001 13:40:40 +0200 Message-ID: <3B026722.1202AA33@riedlbauer.com> Date: Wed, 16 May 2001 13:40:18 +0200 From: Peter Mours X-Mailer: Mozilla 4.74 [de] (X11; U; Linux 2.2.16 i586) X-Accept-Language: en To: webmaster@xemacs.org Subject: xemacs in HP-UX 11.0 Sender: xemacs-webmaint-admin@xemacs.org Errors-To: xemacs-webmaint-admin@xemacs.org X-BeenThere: xemacs-webmaint@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Webmasters List-Unsubscribe: , X-Content-Length: 634 Lines: 26 Xref: D5DC120J xemacs-webmaint:1267 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi There :-) I work with HP in Germany. One of our customers have the Problem to get xemacs running on his 11.0 (32 bit) Machine. -> I have the Installprocedure and the corefile here at my place. The problem is, that I could reproduce the behaviour without any Problems :-(( -> The xemacs comes up, I can load a textfile. When I try to use the "revert buffer", xemacs dies and produce a corefile. Do you have knowledge about that Problem?? - Are you interested to fix that ??? I tried to send the core and so on to crashes@xemac.org but the Mail returned .... I am looking forward to hear from you :-) regards Peter Mours --=-=-= -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ --=-=-=-- From ben@666.com Wed May 16 19:21:51 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA21916 for ; Wed, 16 May 2001 19:21:51 -0400 Received: (qmail 54373 invoked by alias); 16 May 2001 22:52:36 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 49694 invoked by uid 0); 16 May 2001 22:50:55 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 16 May 2001 22:50:55 -0000 Message-ID: <3B0304A1.2F991A93@666.com> Date: Wed, 16 May 2001 15:52:17 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Isaac Hollander CC: "William M. Perry" , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> <200105152221.SAA08921@barry.mail.mindspring.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Isaac Hollander wrote: > > Ben> can you get a c backtrace? > Ben> the fact that the first line is > > >> ding(nil buffer-bound) > > Ben> suggests a problem with the audio support, not the mousewheel. > > Indeed. I built --with-sound=native,noesd and no matter how hard I > tried, moving the mouse to the top or bottom of the buffer and causing > lots of sound events doesn't make XEmacs crash. > > How stable is esd sound support? Should it be autodetected to true by > default? i dunno. can you get a c backtrace? > > If I try hard enough (generating enough random mouse button events), I > can get XEmacs into a state where any mouse button click results in > "button[12345] not recognized" messages, as appropriate. C-g resets > things so that mouse button works again. Unfortunately, I don't > understand X enough to debug this further. > > Isaac -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From paulkrause1@mediaone.net Wed May 16 19:57:42 2001 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA23776 for ; Wed, 16 May 2001 19:57:41 -0400 Received: from paulkrause (h002078ca16a1.ne.mediaone.net [24.128.196.78]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f4GNvX620289; Wed, 16 May 2001 19:57:33 -0400 (EDT) Message-ID: <006b01c0de64$ecab0260$6401a8c0@paulkrause> Reply-To: "Paul Krause" From: "Paul Krause" To: "Craig Lanning" , "Andy Piper" , , References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com>, <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> <200105160048.UAA19604@gwyn.tux.org> Subject: Re: Re[2]: Why does isearch do this [Hrvoje :)]? Date: Wed, 16 May 2001 20:03:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 I see the same behavior as Andy, and it really drives me crazy. The poor woman in the next cubicle must think I'm possessed the way I swear at my computer. (Win 2K, Solid Vapor) ----- Original Message ----- From: "Craig Lanning" To: "Andy Piper" ; ; Sent: Tuesday, May 15, 2001 8:44 PM Subject: Re[2]: Why does isearch do this [Hrvoje :)]? > It works fine for me > > XEmacs 21.4 (patch 2) "Developer-Friendly Unix APIs" [Lucid] (i586-pc-mingw32) of Sat May 12 2001 on CRAIGL > > XEmacs 21.5 (beta1) "anise" [Lucid] (i586-pc-mingw32) of Sat May 12 2001 on CRAIGL > > > Craig > > On Tue, 15 May 2001 13:15:43 -0700 Andy Piper wrote: > > > C-s I mean. What happens if you try it under windows? > > > > andy > > > > At 09:37 PM 5/15/01 +0200, Hrvoje Niksic wrote: > > >Andy Piper writes: > > > > > > > This has bugged me forever about 21.2/4. > > > > > > > > Do > > > > > > > > C-i > > > > > > > > Type something to search. When you find it hit > > > > > > > > C-a > > > > > > > > Then do: > > > > > > > > C-i C-i > > > > > > > > isearch then searches for the thing you looked for *before* the thing > > > > you just found instead of searching for the same string again. Its > > > > *really* annoying. > > > > > >I'm totally confused. Did you bind C-i to isearch or something? > > > > > >Even if I replace C-i with C-s, I simply don't see what you see... > > >For me it works the way it should. > > > > > > > > > > From hniksic@arsdigita.com Wed May 16 20:07:55 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA24257 for ; Wed, 16 May 2001 20:07:55 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 150BIx-0008UX-00; Thu, 17 May 2001 02:06:11 +0200 Sender: hniksic@florida.arsdigita.de To: "Paul Krause" Cc: "Craig Lanning" , "Andy Piper" , Subject: Re: Re[2]: Why does isearch do this [Hrvoje :)]? References: <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> <200105160048.UAA19604@gwyn.tux.org> <006b01c0de64$ecab0260$6401a8c0@paulkrause> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 May 2001 02:06:11 +0200 In-Reply-To: <006b01c0de64$ecab0260$6401a8c0@paulkrause> ("Paul Krause"'s message of "Wed, 16 May 2001 20:03:49 -0400") Message-ID: Lines: 11 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Paul Krause" writes: > I see the same behavior as Andy, and it really drives me crazy. The > poor woman in the next cubicle must think I'm possessed the way I > swear at my computer. Does it happen with `xemacs -vanilla' or with `xemacs -q'? In Andy's case, it doesn't. If the same goes for you, could you please trace which part of your `.emacs' causes the misbehavior? A "smart" package? A strange and harmful Custom setting? From andyp@bea.com Wed May 16 22:44:56 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31267 for ; Wed, 16 May 2001 22:44:56 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA10873; Wed, 16 May 2001 19:44:54 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001306wss.beasys.com [192.168.6.137]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id TAA01210; Wed, 16 May 2001 19:44:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20010516194151.00b20e80@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 May 2001 19:42:29 -0700 To: Hrvoje Niksic , "Paul Krause" From: Andy Piper Subject: Re: Re[2]: Why does isearch do this [Hrvoje :)]? Cc: "Craig Lanning" , In-Reply-To: References: <006b01c0de64$ecab0260$6401a8c0@paulkrause> <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515105517.00ceeae0@san-francisco.beasys.com> <4.3.2.7.2.20010515131324.00d1ef00@san-francisco.beasys.com> <200105160048.UAA19604@gwyn.tux.org> <006b01c0de64$ecab0260$6401a8c0@paulkrause> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:06 AM 5/17/01 +0200, Hrvoje Niksic wrote: >"Paul Krause" writes: > > > I see the same behavior as Andy, and it really drives me crazy. The > > poor woman in the next cubicle must think I'm possessed the way I > > swear at my computer. > >Does it happen with `xemacs -vanilla' or with `xemacs -q'? > >In Andy's case, it doesn't. If the same goes for you, could you >please trace which part of your `.emacs' causes the misbehavior? A >"smart" package? A strange and harmful Custom setting? Its not that simple. I don't get it with my .emacs. At some point during my editing it starts happening. andy From steve@turnbull.sk.tsukuba.ac.jp Wed May 16 22:51:46 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31524 for ; Wed, 16 May 2001 22:51:44 -0400 Received: by localhost id m150Dt5-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 17 May 2001 11:51:39 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15107.15547.488315.295310@turnbull.sk.tsukuba.ac.jp> Date: Thu, 17 May 2001 11:51:39 +0900 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC In-Reply-To: References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> A third, and IMHO best, solution would be for XEmacs to Hrvoje> raise its own stack size if it notices it to be too small. Hrvoje> It's quite easy to do for someone who has access to a Hrvoje> Digital Unix system. I do, but ... I have no idea whether the necessary tools are installed (eg, gcc is 2.7.2.1). I know there's no cvs, I'll get back to you on whether I can build xemacs at all later. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Wed May 16 23:06:42 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA32227; Wed, 16 May 2001 23:06:40 -0400 Received: by localhost id m150E7L-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 17 May 2001 12:06:23 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15107.16431.70087.584774@turnbull.sk.tsukuba.ac.jp> Date: Thu, 17 May 2001 12:06:23 +0900 To: Ben Wing Cc: Isaac Hollander , "William M. Perry" , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes In-Reply-To: <3B0304A1.2F991A93@666.com> References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> <200105152221.SAA08921@barry.mail.mindspring.net> <3B0304A1.2F991A93@666.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Ben" == Ben Wing writes: Ben> Isaac Hollander wrote: >> How stable is esd sound support? Should it be autodetected to >> true by default? Ben> i dunno. IMO ESD support is a crock and has always been. ESD has been implicated in numerous crashes and other problems involving interrupts and timing (which may or may not be XEmacs bugs, but they only show up when ESD is configured). ESD insists on detecting itself even if an explicit list of sound libraries is given to --with-sound. ESD has historically been a very bad neighbor. As far as I know the only fix offered for any of them is --with-sound=none,..., so I'm going to default it off in future releases of 21.4, if I can figure out how to defeat its viral feature. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From ysh@mindspring.com Wed May 16 23:14:40 2001 Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA32684; Wed, 16 May 2001 23:14:40 -0400 Received: from localhost.localdomain.mindspring.com (user-2inig7n.dialup.mindspring.com [165.121.64.247]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA27100; Wed, 16 May 2001 23:14:42 -0400 (EDT) Message-Id: <200105170314.XAA27100@johnson.mail.mindspring.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2001 23:16:36 -0400 From: Isaac Hollander To: Ben Wing Cc: Isaac Hollander , "William M. Perry" , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes In-Reply-To: <3B0304A1.2F991A93@666.com> References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> <200105152221.SAA08921@barry.mail.mindspring.net> <3B0304A1.2F991A93@666.com> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid >> Ben> can you get a c backtrace? Reproducing the crash again, I notice the following: [3]- User defined signal 1 ./xemacs I attached to the process with gdb, and as soon as I caused a sound event, XEmacs caught a SIGUSR1. #0 0x40498897 in __libc_pause () from /lib/i686/libc.so.6 #1 0x40360a20 in esd_open_sound (host=0x0) at esdlib.c:691 #2 0x40360b11 in esd_play_stream (format=4112, rate=8000, host=0x0, name=0x81ad040 "xemacs") at esdlib.c:740 #3 0x080c8fb7 in esd_play_sound_data (data=0xbfffdb80 "RIFF\"\002", length=554, vol=50) at esd.c:102 #4 0x08158a54 in Fplay_sound (sound=137128548, volume=136371572, device=138417888) at sound.c:337 #5 0x08158f84 in Fding (arg=136371572, sound=137128548, device=136371572) at sound.c:413 #6 0x080ae97f in Ffuncall (nargs=3, args=0xbfffdf14) at eval.c:3528 So esd does evil things with SIGUSR1, and I think it's interfering with XEmacs's handling of SIGUSR1. In xemacs-21.4.2/src/signal.c: static void handle_signal_if_fatal (int signo) { if (signal (signo, fatal_error_signal) == SIG_IGN) signal (signo, SIG_IGN); } and #ifdef SIGUSR1 handle_signal_if_fatal (SIGUSR1); /* POSIX */ #endif I assume the /* POSIX */ comment means that SIGUSR1 is a POSIX signal as opposed to an ANSI signal, not that the signal is handled with POSIX sementics. So there's a possibility that in between the 2 calls to signal, another signal could arrive, and since the signal is reset to default behavior, the unignored SIGUSR1 causes a crash. Would using the POSIX signal functions (sigaction and friends) help here? Isaac From ysh@mindspring.com Wed May 16 23:17:15 2001 Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA00372; Wed, 16 May 2001 23:17:13 -0400 Received: from localhost.localdomain.mindspring.com (user-2inig7n.dialup.mindspring.com [165.121.64.247]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id XAA17844; Wed, 16 May 2001 23:16:59 -0400 (EDT) Message-Id: <200105170316.XAA17844@blount.mail.mindspring.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2001 23:18:56 -0400 From: Isaac Hollander To: "Stephen J. Turnbull" Cc: Ben Wing , Isaac Hollander , "William M. Perry" , xemacs-beta@xemacs.org Subject: ESD woes In-Reply-To: <15107.16431.70087.584774@turnbull.sk.tsukuba.ac.jp> References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> <200105152221.SAA08921@barry.mail.mindspring.net> <3B0304A1.2F991A93@666.com> <15107.16431.70087.584774@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Stephen> IMO ESD support is a crock and has always been. ESD has been Stephen> implicated in numerous crashes and other problems involving interrupts Stephen> and timing (which may or may not be XEmacs bugs, but they only show up Stephen> when ESD is configured). ESD insists on detecting itself even if an And signals. See my other message. Subject header corrected; I apologize for not doing it before. From youngs@xemacs.org Thu May 17 03:07:39 2001 Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [203.2.75.229]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA07231 for ; Thu, 17 May 2001 03:07:35 -0400 Received: from slackware.mynet.pc (wdcax13-243.dialup.optusnet.com.au [198.142.220.243]) by mail005.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4H77Sl11391 for ; Thu, 17 May 2001 17:07:28 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4H6vrWo007743; Thu, 17 May 2001 16:57:53 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: XEmacs Packages new hierarchy in CVS. From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 17 May 2001 16:57:52 +1000 Message-ID: Lines: 57 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hey All. The XEmacs review board has decided that the current directory hierarchy of the 'xemacs-packages' CVS module was unnecessarily confusing. So the old hierarchy of: xemacs-packages comm games libs mule oa os prog wp has been changed to: packages xemacs-packages mule-packages The new CVS module can be retrieved with: ,---- | cvs -d :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot login | password is "zawinski" (sans quotes) | | cvs -d :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot co packages `---- You can also grab an individual package with: ,---- | cvs -d :pserver:xeamcs@cvs.xemacs.org:/usr/CVSroot co gnus `---- That gets you the 'gnus' package. If you have the time and disk space [1], please check this new module out of CVS and do some test builds. Thanks. Footnotes: [1] Approx 60 Mb for the raw tree. At least double that size for building. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From yoshiki@xemacs.org Thu May 17 03:14:31 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA08307; Thu, 17 May 2001 03:14:28 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4H7EOZ04722; Thu, 17 May 2001 16:14:24 +0900 Mail-Copies-To: nobody To: xemacs-beta@xemacs.org Cc: xemacs-review@xemacs.org Subject: XEmacs patch status list From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 17 May 2001 16:14:24 +0900 Message-ID: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 211 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Sorry for not sending for this for a while. This list is what I have now. If you sent a patch and is not listed here without reply, please send it again. 1999-11-18 Tim Bradshaw Hack fix for prefix help in xemacs 21 <199911180102.BAA21598@lostwithiel.tfeb.org> http://list-archive.xemacs.org/xemacs-patches/199911/msg00063.html Status: Not reviewed 1999-12-29 Kevin Delia Fix for ps-print.el used by NT XEmacs <386A47EC.DCFBB7B7@globalone.net> http://list-archive.xemacs.org/xemacs-patches/199912/msg00158.html Status: Not reviewed 2000-01-14 Karl M. Hegbloom man.el: Take 3 **IGNORE PREVIOUS PATCHES** <874schjf6c.fsf@bittersweet.intra> http://list-archive.xemacs.org/xemacs-patches/200001/msg00069.html Status: Not reviewed 2000-01-25 Robert.Fenk@gmx.de smtpmail-sent-it extracts RESENT-* headers wrong! <14477.29922.17067.523087@sunwibas14.forwiss.tu-muenchen.de> http://list-archive.xemacs.org/xemacs-patches/200001/msg00196.html Status: Not reviewed 2000-03-09 Rodney Stromlund Using wget to download packages http://list-archive.xemacs.org/xemacs-patches/200003/msg00059.html Status: Not reviewed 2000-06-07 MORIOKA Tomohiko eliminate hard coding parts about charset http://list-archive.xemacs.org/xemacs-patches/200006/msg00020.html Status: Not reviewed 2000-08-31 QuoteMstr Better C++ IMenu support <20000830205905.A29419@d30-146.hcvlny.optonline.net> http://list-archive.xemacs.org/xemacs-patches/200008/msg00108.html Status: Not reviewed 2000-10-04 Darryl Okahata Getting the pixel position of a window point <200010041837.LAA29896@mina.soco.agilent.com> http://list-archive.xemacs.org/xemacs-patches/200010/msg00020.html Status: Approved 2000-11-12 Klaus Frank Info fixes, Info-emacs-key, PR#1501-1503 <200011121459.PAA09119@pfitzner.informatik.rwth-aachen.de> http://list-archive.xemacs.org/xemacs-patches/200011/msg00056.html Status: Approved with mod Need to fix example. 2000-11-13 Sean MacLennan Re: package-get-hook <14863.24170.700206.526947@fillmore.storm.ca> http://list-archive.xemacs.org/xemacs-patches/200011/msg00060.html Status: Approved 2000-11-14 I.Sheldon change-request: vc.el to allow template text in vc log buffer http://list-archive.xemacs.org/xemacs-patches/200011/msg00075.html Status: Not reviewed 2000-11-19 Gregory Neil Shapiro 21.2.36: New movemail option to remove inbox instead of truncate <14872.11701.215292.104315@horsey.gshapiro.net> http://list-archive.xemacs.org/xemacs-patches/200011/msg00110.html Status: Approved with mod Need to fix spurious ftruncate 2000-12-14 Tetsuo Tsukamoto do-auto-fill fix for MULE http://list-archive.xemacs.org/xemacs-patches/200012/msg00052.html Status: Not reviewed 2000-12-19 Golubev I. N. sendmail prog & originator <02453a3fac4701-gin@mo.msk.ru> http://list-archive.xemacs.org/xemacs-patches/200012/msg00068.html Status: Not reviewed 2000-12-28 Kevin Gallagher Patch to EDT package. Now works in XEmacs. <3A4BA766.C4A5ABDB@onramp.net> http://list-archive.xemacs.org/xemacs-patches/200012/msg00089.html Status: Not reviewed 2001-01-05 Golubev I. N. xemacs_stat <02e83a560c9b32-gin@mo.msk.ru> http://list-archive.xemacs.org/xemacs-patches/200101/msg00010.html Status: Not reviewed 2001-01-09 Golubev I. N. `stat' in "lisp.h" <02e83a5b113434-gin@mo.msk.ru> http://list-archive.xemacs.org/xemacs-patches/200101/msg00034.html Status: Not reviewed 2001-01-09 Daniel Pittman VC60 support for compile.el <87g0it9x7w.fsf@inanna.rimspace.net> http://list-archive.xemacs.org/xemacs-patches/200101/msg00027.html Status: Not reviewed 2001-01-20 Nick V. Pakoulin Default values when reading from minibuffer in some cases. http://list-archive.xemacs.org/xemacs-patches/200101/msg00132.html Status: Approved 2001-01-29 Karl M. Hegbloom mwheel.el: support left and right scroll also <87ofwqmf4t.fsf@karlheg.microsharp.com> Status: Not reviewed 2001-02-05 Jerry James Enable module building Status: Not reviewed 2001-02-08 Jean-Yves Burlett Solves curses detection/terminal garbled problem on OpenBSD http://list-archive.xemacs.org/xemacs-patches/200102/msg00040.html Status: Discussion 2001-02-16 Simon Josefsson mail-lib/rmailout.el http://list-archive.xemacs.org/xemacs-patches/200102/msg00094.html Status: Unknown 2001-02-24 Mike Alexander Running sub-processes from modal loop <16821421.3191976093@mta-1.pnet.msen.com> http://list-archive.xemacs.org/xemacs-patches/200102/msg00130.html Status: Discussion 2001-03-19 Karl M. Hegbloom [cus-edit.el] Edit faces: Support GTK Window System also. <87d7bdfwxw.fsf@microsharp.com> http://list-archive.xemacs.org/xemacs-patches/200103/msg00065.html Status: Not reviewed 2001-04-25 Stephen J. Turnbull [packages] Change bug address in emacsbug.el <15078.34617.367597.513600@turnbull.sk.tsukuba.ac.jp> http://list-archive.xemacs.org/xemacs-patches/200104/msg00093.html Status: Not reviewed 2001-04-25 Albert L. Ting Re: vc-hooks.el patch <15079.331.923129.704788@betty.artisan.com> http://list-archive.xemacs.org/xemacs-patches/200104/msg00100.html Status: Discussion 2001-04-29 Simon Josefsson new subr.el function: make-temp-file http://list-archive.xemacs.org/xemacs-patches/200104/msg00122.html Status: Discussion 2001-05-10 Paul Stodghill Patch for sound under latest Cygwin http://list-archive.xemacs.org/xemacs-patches/200105/msg00053.html Status: Not reviewed 2001-05-10 Daiki Ueno side effect on font-lock-keywords http://list-archive.xemacs.org/xemacs-patches/200105/msg00051.html Status: Not reviewed 2001-05-11 Adrian Aichner [PATCH] Getting XEmacs-21.4.2 to Build on Native Windows http://list-archive.xemacs.org/xemacs-patches/200105/msg00056.html Status: Not reviewed 2001-05-12 Karl M. Hegbloom [configure.in,config.h.in,movemail.c] Use mkstemp if possible (warning suppression, "security") <87g0ea77tc.fsf@bittersweet.intra.hegbloom.net> http://list-archive.xemacs.org/xemacs-patches/200105/msg00069.html Status: Not reviewed 2001-05-13 Karl M. Hegbloom [lisp/packages.el:locate-data-file] Allow gzipped files in data-directory-list <878zk1xyy7.fsf@bittersweet.intra.hegbloom.net> http://list-archive.xemacs.org/xemacs-patches/200105/msg00075.html Status: Not reviewed 2001-05-15 Simon Josefsson mail-lib/rfc822.el emacs 21 sync http://list-archive.xemacs.org/xemacs-patches/200105/msg00096.html Status: Approved Self approval by the package maintainer -- Yoshiki Hayashi From starksb@ebi.ac.uk Thu May 17 04:55:26 2001 Received: from alpha1.ebi.ac.uk (alpha1.ebi.ac.uk [193.62.196.122]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA25129 for ; Thu, 17 May 2001 04:55:25 -0400 Received: from BRYCE.ebi.ac.uk (bryce.dhcp.ebi.ac.uk [193.62.198.162]) by alpha1.ebi.ac.uk (8.9.3/8.9.3) with ESMTP id JAA341385; Thu, 17 May 2001 09:55:13 +0100 (BST) Date: Thu, 17 May 2001 09:55:12 +0100 Message-ID: <9995-Thu17May2001095512+0100-starksb@ebi.ac.uk> X-Mailer: emacs 20.7.1 (via feedmail 9-beta-7 I); VM 6.92 under Emacs 20.7.1 From: David Starks-Browning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: xemacs-beta@xemacs.org Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC In-Reply-To: <15107.15547.488315.295310@turnbull.sk.tsukuba.ac.jp> References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> <15107.15547.488315.295310@turnbull.sk.tsukuba.ac.jp> > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> A third, and IMHO best, solution would be for XEmacs to > Hrvoje> raise its own stack size if it notices it to be too small. > Hrvoje> It's quite easy to do for someone who has access to a > Hrvoje> Digital Unix system. I should be able to build a CVS version of xemacs on Compaq Tru64 UNIX V5.0A. GCC is 2.95.3. I may also be able to build on Digital UNIX V4.0D, but it's not certain, because all necessary tools may not work on that platform here. (Just because some of our local tools may have been built on 5.0, and may not run on 4.0.) Would this be helpful? All I can do is build, and test if someone tells me specifically what to test. I'm not qualified to touch the source code. I'd like to contribute if I can, because I know (first hand) how confusing the absurdly small default stacksize limit can be for inexperienced Digital UNIX users. Note that default (DFLSSIZ in /usr/include/machines/vmparam.h I think) was increased from 2048KB in Digital UNIX 4.0 to 8192KB in Tru64 UNIX 5.0. Is it still a problem for xemacs with the larger default stack size in 5.0? Since it's sooooo easy for the user to solve this problem with ulimit, wouldn't an entry in the PROBLEMS file be good enough? (Apologies if I'm on the wrong track here. I did not study some earlier messages in this thread very carefully, and have made some assumptions about what I think you're all talking about.) Kind regards, David ------------------------------------------------------------------- David Starks-Browning | starksb@ebi.ac.uk EMBL Outstation -- | The European Bioinformatics Institute | Wellcome Trust Genome Campus | tel: +44 (1223) 494 616 Hinxton, Cambridge, CB10 1SD, UK | fax: +44 (1223) 494 468 ------------------------------------------------------------------- From yoshiki@xemacs.org Thu May 17 05:17:31 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA28301 for ; Thu, 17 May 2001 05:17:30 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4H9HNZ06347; Thu, 17 May 2001 18:17:23 +0900 Mail-Copies-To: nobody To: "Stephen J. Turnbull" Cc: karlheg@hegbloom.net (Karl M. Hegbloom), XEmacs Beta Subject: Re: [etc/xemacs-ja.1] Shouldn't it be named "xemacs.ja.1"? References: <874rupxbrj.fsf@bittersweet.intra.hegbloom.net> <15103.32907.490375.397597@turnbull.sk.tsukuba.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 17 May 2001 18:17:23 +0900 In-Reply-To: <15103.32907.490375.397597@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 14 May 2001 15:51:55 +0900") Message-ID: <874rukgwrg.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 33 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) "Stephen J. Turnbull" writes: > >>>>> "Karl" == Karl M Hegbloom writes: > > Karl> "dh_installman" looks for man pages with names formed like > Karl> "xemacs.ja.1" to find non-english man pages so it can > Karl> install them in the right location; eg: > Karl> /usr/share/man/ja/man1. > > Karl> Isn't that a pretty standard naming convention? > > Never heard of it before as a convention. Seems preferable to me to > have separate directories for different languages rather than have > them all clutter up the same directory with many copies of the same > thing, most useless to most users and developers. I agree. > Karl> Shouldn't that man page be renamed? (perhaps copy the ,v in > Karl> CVS to the new name, then cvs remove the old one to preserve > Karl> history) > > Not before checking non-Debian systems to see what they do. I'd rather just cvs remove this one. The translation is quite outdated and quality is not very good. Some time ago, a friend of mine told me that it contains wrong translation and indeed it does. If someone cares enough to correct it, then we can add it back to repository (possibly with different name and/or different directory). -- Yoshiki Hayashi From yoshiki@xemacs.org Thu May 17 05:28:56 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA29784 for ; Thu, 17 May 2001 05:28:55 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4H9SoZ06438; Thu, 17 May 2001 18:28:50 +0900 Mail-Copies-To: nobody To: James LewisMoss Cc: Andy Piper , xemacs-beta@xemacs.org Subject: Re: Update to last message References: <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> <4.3.2.7.2.20010508110730.00b18cc0@san-francisco.beasys.com> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 17 May 2001 18:28:50 +0900 In-Reply-To: (James LewisMoss's message of "08 May 2001 15:19:34 -0400") Message-ID: <871ypogw8d.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 17 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) James LewisMoss writes: > Andy> Do you set a bunch of stuff in Xdefaults? Does this show up > Andy> even with vanilla? andy > > I've tracked it down to changing one customization. > > If I change the Progress Feedback Style to "small" I get a bunch of X > errors, but no crash. Changing it back to "large" and the crash > happens when I open the next file. I cannot reproduce it. Debian sid and XEmacs 21.5 CVS a few days ago. Could it be xaw-wrapper and xaw3d thing? This is the only possibility I can guess. -- Yoshiki Hayashi From youngs@xemacs.org Thu May 17 05:48:52 2001 Received: from mail005.syd.optusnet.com.au (mail005.syd.optusnet.com.au [203.2.75.229]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA31996 for ; Thu, 17 May 2001 05:48:50 -0400 Received: from slackware.mynet.pc (wdcax13-243.dialup.optusnet.com.au [198.142.220.243]) by mail005.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4H9mkl29447 for ; Thu, 17 May 2001 19:48:47 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4H9i0Nq009019; Thu, 17 May 2001 19:44:00 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 12 References: <15106.15725.587706.152468@ulthwe.dyndns.org> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 17 May 2001 19:44:00 +1000 In-Reply-To: <15106.15725.587706.152468@ulthwe.dyndns.org> (Peter Brown's message of "Wed, 16 May 2001 18:42:21 +1000") Message-ID: Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "PB" == Peter Brown writes: PB> Steve Youngs writes: >>The following packages have been updated and put into the >>"Pre-Releases" directory: [...] PB> these all worked on my RH 7.0 linux box with xemacs 21.5.1 Thanks, Peter. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From steve@turnbull.sk.tsukuba.ac.jp Thu May 17 06:06:23 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA01672; Thu, 17 May 2001 06:06:22 -0400 Received: by localhost id m150Kfa-000143C (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 17 May 2001 19:06:10 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15107.41607.26516.542347@turnbull.sk.tsukuba.ac.jp> Date: Thu, 17 May 2001 19:05:59 +0900 To: Yoshiki Hayashi Cc: karlheg@hegbloom.net (Karl M. Hegbloom), XEmacs Beta Subject: Re: [etc/xemacs-ja.1] Shouldn't it be named "xemacs.ja.1"? In-Reply-To: <874rukgwrg.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <874rupxbrj.fsf@bittersweet.intra.hegbloom.net> <15103.32907.490375.397597@turnbull.sk.tsukuba.ac.jp> <874rukgwrg.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Yoshiki" == Yoshiki Hayashi writes: Yoshiki> I'd rather just cvs remove this one. The translation is Yoshiki> quite outdated and quality is not very good. Well, I'll trust your judgement on that for 21.5, take a quick peek at it for form's sake, and probably remove it in 21.4 too. Maybe we should ask for volunteers on xemacs-mule-ja? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Thu May 17 06:19:39 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA03302; Thu, 17 May 2001 06:19:38 -0400 Received: by localhost id m150Ksc-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 17 May 2001 19:19:38 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15107.42426.523156.26319@turnbull.sk.tsukuba.ac.jp> Date: Thu, 17 May 2001 19:19:38 +0900 To: Yoshiki Hayashi Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: XEmacs patch status list In-Reply-To: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Yoshiki" == Yoshiki Hayashi writes: Yoshiki> This list is Yoshiki> what I have now. If you sent a patch and is not listed Yoshiki> here without reply, please send it again. I'm having trouble with the Web, Mike Alexander's patch labelled with (?) I'm guessing at contents. 2001-02-24 Mike Alexander Running sub-processes from modal loop <16821421.3191976093@mta-1.pnet.msen.com> http://list-archive.xemacs.org/xemacs-patches/200102/msg00130.html Status: Discussion (?) --> I think this is in 21.4. Superceded for 21.5 by a Ben patch? 2001-03-19 Karl M. Hegbloom [cus-edit.el] Edit faces: Support GTK Window System also. <87d7bdfwxw.fsf@microsharp.com> http://list-archive.xemacs.org/xemacs-patches/200103/msg00065.html Status: Not reviewed --> In 21.4. Not applied to 21.5. 2001-05-10 Paul Stodghill Patch for sound under latest Cygwin http://list-archive.xemacs.org/xemacs-patches/200105/msg00053.html Status: Not reviewed --> Reviewed, tested, approved, applied to 21.4. Not applied to 21.5. 2001-05-11 Adrian Aichner [PATCH] Getting XEmacs-21.4.2 to Build on Native Windows http://list-archive.xemacs.org/xemacs-patches/200105/msg00056.html Status: Not reviewed --> Superceded by earlier patch applied to 21.4. Not for 21.5. Missing: There's a Glynn Clements patch for input-method-motif.c, already in 21.4, which I will apply to 21.5 with the Hegbloom and Stodghill patches. I'll give details later. There's a patch by Zhaoway and a similar (and thus redundant) one by Karl Hegbloom for --with-scrollbars=no; I don't think it's in 21.5 yet but will check. Karl's I reviewed and rejected since the problem already was addressed by Zhaoway. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From yoshiki@xemacs.org Thu May 17 06:49:22 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA06904; Thu, 17 May 2001 06:49:20 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4HAnIZ07063; Thu, 17 May 2001 19:49:18 +0900 Mail-Copies-To: nobody To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org, ben@xemacs.org Subject: Re: XEmacs patch status list References: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> <15107.42426.523156.26319@turnbull.sk.tsukuba.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 17 May 2001 19:49:18 +0900 In-Reply-To: <15107.42426.523156.26319@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Thu, 17 May 2001 19:19:38 +0900") Message-ID: <87sni4fdxt.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 63 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) "Stephen J. Turnbull" writes: > 2001-02-24 Mike Alexander > Running sub-processes from modal loop > <16821421.3191976093@mta-1.pnet.msen.com> > http://list-archive.xemacs.org/xemacs-patches/200102/msg00130.html > Status: Discussion > > (?) --> I think this is in 21.4. Superceded for 21.5 by a Ben patch? Ben, could you comment? > 2001-03-19 Karl M. Hegbloom > [cus-edit.el] Edit faces: Support GTK Window System also. > <87d7bdfwxw.fsf@microsharp.com> > http://list-archive.xemacs.org/xemacs-patches/200103/msg00065.html > Status: Not reviewed > > --> In 21.4. Not applied to 21.5. I will apply it to 21.5. > 2001-05-10 Paul Stodghill > Patch for sound under latest Cygwin > > http://list-archive.xemacs.org/xemacs-patches/200105/msg00053.html > Status: Not reviewed > > --> Reviewed, tested, approved, applied to 21.4. Not applied to 21.5. This one, too. > 2001-05-11 Adrian Aichner > [PATCH] Getting XEmacs-21.4.2 to Build on Native Windows > > http://list-archive.xemacs.org/xemacs-patches/200105/msg00056.html > Status: Not reviewed > > --> Superceded by earlier patch applied to 21.4. Not for 21.5. I thought I removed this one from my list... > Missing: > > There's a Glynn Clements patch for input-method-motif.c, already in > 21.4, which I will apply to 21.5 with the Hegbloom and Stodghill > patches. I'll give details later. I don't remember this one. Either I removed it from the list because you said you'll apply or simply I didn't add it to the list. > There's a patch by Zhaoway and a similar (and thus redundant) one by > Karl Hegbloom for --with-scrollbars=no; I don't think it's in 21.5 yet > but will check. Karl's I reviewed and rejected since the problem > already was addressed by Zhaoway. This one (Zhaoway's patch) is applied. Thanks for your comment. -- Yoshiki Hayashi From hniksic@arsdigita.com Thu May 17 07:30:15 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA11057 for ; Thu, 17 May 2001 07:30:14 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 150Lyv-0002JK-00 for ; Thu, 17 May 2001 13:30:13 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> <15107.15547.488315.295310@turnbull.sk.tsukuba.ac.jp> <9995-Thu17May2001095512+0100-starksb@ebi.ac.uk> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 17 May 2001 13:30:13 +0200 In-Reply-To: <9995-Thu17May2001095512+0100-starksb@ebi.ac.uk> (David Starks-Browning's message of "Thu, 17 May 2001 09:55:12 +0100") Message-ID: Lines: 24 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii David Starks-Browning writes: > Since it's sooooo easy for the user to solve this problem with ulimit, > wouldn't an entry in the PROBLEMS file be good enough? Haven't you looked? It's been there for ages! ** Digital UNIX/OSF/VMS/Ultrix *** XEmacs crashes on Digital Unix within font-lock, or when dealing with large compilation buffers. The default stack size under Digital Unix is rather small (2M as opposed to Solaris 8M), hosing the regexp code, which uses alloca() extensively, overflowing the stack when complex regexps are used. Workarounds: 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh equivalent; 2) Recompile regex.c with REGEX_MALLOC defined. People don't read PROBLEMS. People prefer programs that work, and I can understand that sentiment. It should be really easy to increase the stack size programatically. From rendhalver@users.sourceforge.net Thu May 17 07:48:25 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA12020; Thu, 17 May 2001 07:48:19 -0400 Received: from ulthwe.dyndns.org (p86-tnt1.brs.ihug.com.au [203.173.188.86]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id VAA10884; Thu, 17 May 2001 21:48:05 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p86-tnt1.brs.ihug.com.au [203.173.188.86] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15107.47586.301722.331147@ulthwe.dyndns.org> Date: Thu, 17 May 2001 21:45:38 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Steve Youngs writes: > Hey All. > > The XEmacs review board has decided that the current directory > hierarchy of the 'xemacs-packages' CVS module was unnecessarily > confusing. > The new CVS module can be retrieved with: [snip] > > ,---- > | cvs -d :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot login > | password is "zawinski" (sans quotes) > | > | cvs -d :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot co packages > `---- [snip] > If you have the time and disk space [1], please check this new module > out of CVS and do some test builds. hey steve just tried to checkout this i got this error [rendhalver@ulthwe xemacs]$ cvs -d :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot co packages cvs checkout: in directory packages: cvs checkout: cannot open CVS/Entries for reading: No such file or directory cvs [checkout aborted]: cannot open CVS/Entries.Static: No such file or directory um is this a problem on my end or yours ?? i can checkout xemacs fine -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From CraigL@Knology.net Thu May 17 08:03:07 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id IAA12580 for ; Thu, 17 May 2001 08:03:07 -0400 Message-Id: <200105171203.IAA12580@gwyn.tux.org> Received: (qmail 23144 invoked from network); 17 May 2001 12:03:07 -0000 Received: from user-24-214-22-213.knology.net (24.214.22.213) by user-24-214-63-14.knology.net with SMTP; 17 May 2001 12:03:07 -0000 Date: Thu, 17 May 2001 07:59:44 -0400 (EDT) From: Craig Lanning Subject: Re: XEmacs patch status list To: Yoshiki Hayashi cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE In-Reply-To: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: Mahogany, 0.62 'Mars', compiled for Linux 2.2.12-20smp i686 Is this list for 21.5 or 21.4? The following patch was sent in for 21.5: http://list-archive.xemacs.org/xemacs-patches/200105/msg00072.html Do you still need it re-sent? Craig On 17 May 2001 16:14:24 +0900 Yoshiki Hayashi wrote: > Sorry for not sending for this for a while. This list is > what I have now. If you sent a patch and is not listed here > without reply, please send it again. > > [...] From rendhalver@users.sourceforge.net Thu May 17 09:04:08 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA15395; Thu, 17 May 2001 09:04:03 -0400 Received: from ulthwe.dyndns.org (p86-tnt1.brs.ihug.com.au [203.173.188.86]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id XAA16996; Thu, 17 May 2001 23:03:58 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p86-tnt1.brs.ihug.com.au [203.173.188.86] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15107.52140.427062.974959@ulthwe.dyndns.org> Date: Thu, 17 May 2001 23:01:32 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. In-Reply-To: <15107.47586.301722.331147@ulthwe.dyndns.org> References: <15107.47586.301722.331147@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Peter Brown writes: > Steve Youngs writes: > hey steve > > just tried to checkout this > i got this error > > > [rendhalver@ulthwe xemacs]$ cvs -d :pserver:xemacs@cvs.xemacs.org:/usr/CVSroot co packages > cvs checkout: in directory packages: > cvs checkout: cannot open CVS/Entries for reading: No such file or directory > cvs [checkout aborted]: cannot open CVS/Entries.Static: No such file or directory > > > um is this a problem on my end or yours ?? *blush* just ignore this one silly brain not doing its usual thing already had a directory called packages that had nothing to do with CVS at all that was causing the error sorry -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From jimdres@mindspring.com Thu May 17 10:56:58 2001 Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA22117; Thu, 17 May 2001 10:54:28 -0400 Received: from eeyore.lewismoss.org (user-2ivf7m4.dialup.mindspring.com [165.247.158.196]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id KAA22339; Thu, 17 May 2001 10:54:23 -0400 (EDT) Received: from dres by eeyore.lewismoss.org with local (Exim 3.22 #1 (Debian)) id 150P8y-0001mn-00; Thu, 17 May 2001 10:52:48 -0400 To: Yoshiki Hayashi Cc: xemacs-beta@xemacs.org Subject: Re: Update to last message References: <4.3.2.7.2.20010507094036.00aefaa0@san-francisco.beasys.com> <4.3.2.7.2.20010508085530.00af17b0@san-francisco.beasys.com> <4.3.2.7.2.20010508100346.00b0f100@san-francisco.beasys.com> <4.3.2.7.2.20010508110730.00b18cc0@san-francisco.beasys.com> <871ypogw8d.fsf@u.sanpo.t.u-tokyo.ac.jp> From: James LewisMoss In-Reply-To: Yoshiki Hayashi's message of "17 May 2001 18:28:50 +0900" X-Url: http://jimdres.home.mindspring.com X-Organization: Debian/Software in the Public Interest Original-Original-Sender: James LewisMoss X-Face: "R3Ms&!j++.]J8DwisON-l7#SOloY'V?!^-!2 9G+7Z7OzClzr2{3eni9BN\pzkTp}ehc,\AhKBZ\Sf/HVG+p\*?'(&ct2w6Fr:w9m o|9R&.D-)1]:&sN-6o'\`7W${f1$2BCy6qSl&._{ILYCZ?X-[?M!](N Date: 17 May 2001 10:52:28 -0400 Message-ID: Lines: 27 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: James LewisMoss >>>>> On 17 May 2001 18:28:50 +0900, Yoshiki Hayashi said: Yoshiki> James LewisMoss writes: Andy> Do you set a bunch of stuff in Xdefaults? Does this show up Andy> even with vanilla? andy >> >> I've tracked it down to changing one customization. >> >> If I change the Progress Feedback Style to "small" I get a bunch >> of X errors, but no crash. Changing it back to "large" and the >> crash happens when I open the next file. Yoshiki> I cannot reproduce it. Debian sid and XEmacs 21.5 CVS a few Yoshiki> days ago. Could it be xaw-wrapper and xaw3d thing? This is Yoshiki> the only possibility I can guess. Not related to xaw3d. This situation was fixed in sid (afaik). It looks like bad values to an XDrawLine. I haven't tracked it down beyond that yet. Jim -- @James LewisMoss | Blessed Be! @ http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach From didier@lrde.epita.fr Thu May 17 11:15:22 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA23582; Thu, 17 May 2001 11:15:21 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id RAA16459 Thu, 17 May 2001 17:13:03 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 150PSf-0005l2-00; Thu, 17 May 2001 17:13:09 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 150PS3-0005Uu-00; Thu, 17 May 2001 17:12:31 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (Steve Youngs's message of "17 May 2001 16:57:52 +1000") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 17 May 2001 17:12:31 +0200 Message-ID: Lines: 25 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id LAA23582 Steve Youngs wrote: > Hey All. > > The XEmacs review board has decided that the current directory > hierarchy of the 'xemacs-packages' CVS module was unnecessarily > confusing. Just for the record, I've been unable to check out the complete package archive correctly for *years*. On my debian unstable system, cvs 1.11 barfs when checking out skk: [...] U packages/mule-packages/skk/etc/ReadMe.10 U packages/mule-packages/skk/etc/ReadMe.English Terminated with fatal signal 11 The recent server upgrade apparently didn't fix this problem. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From sperber@informatik.uni-tuebingen.de Thu May 17 11:32:00 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA24655 for ; Thu, 17 May 2001 11:31:57 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8DF7C1063 for ; Thu, 17 May 2001 17:31:55 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4HFVtt10437; Thu, 17 May 2001 17:31:55 +0200 (CEST) (envelope-from sperber) To: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 17 May 2001 17:31:55 +0200 In-Reply-To: (Didier Verna's message of "17 May 2001 17:12:31 +0200") Message-ID: Lines: 26 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "drv" == Didier Verna writes: drv> Steve Youngs wrote: >> Hey All. >> >> The XEmacs review board has decided that the current directory >> hierarchy of the 'xemacs-packages' CVS module was unnecessarily >> confusing. drv> Just for the record, I've been unable to check out the complete drv> package archive correctly for *years*. On my debian unstable system, cvs 1.11 drv> barfs when checking out skk: drv> [...] drv> U packages/mule-packages/skk/etc/ReadMe.10 drv> U packages/mule-packages/skk/etc/ReadMe.English drv> Terminated with fatal signal 11 This is apparently a server-side problem. The out-of-memory problems are also still around. I see it happen only with ssh. :pserver: works better. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From didier@lrde.epita.fr Thu May 17 11:41:43 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA25188 for ; Thu, 17 May 2001 11:41:42 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id RAA19126 Thu, 17 May 2001 17:39:18 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 150Ps4-0006dl-00; Thu, 17 May 2001 17:39:24 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 150PrT-0005YW-00; Thu, 17 May 2001 17:38:47 +0200 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "17 May 2001 17:31:55 +0200") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 17 May 2001 17:38:46 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id LAA25188 sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) wrote: > This is apparently a server-side problem. The out-of-memory problems > are also still around. I see it happen only with ssh. :pserver: > works better. Hmmm. I indeed used :ext: with my own account to perform the checkout. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From darrylo@soco.agilent.com Thu May 17 11:44:04 2001 Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA25858 for ; Thu, 17 May 2001 11:44:03 -0400 Received: from msgrel1.and.agilent.com (msgrel1.and.agilent.com [130.30.33.104]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id 9F477442; Thu, 17 May 2001 09:43:48 -0600 (MDT) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.and.agilent.com (Postfix) with ESMTP id 65107121; Thu, 17 May 2001 11:43:46 -0400 (EDT) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id IAA26198; Thu, 17 May 2001 08:43:44 -0700 (PDT) Message-Id: <200105171543.IAA26198@mina.soco.agilent.com> To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Re[2]: Why does isearch do this [Hrvoje :)]? Reply-To: Darryl Okahata In-Reply-To: Your message of "Wed, 16 May 2001 19:42:29 PDT." <4.3.2.7.2.20010516194151.00b20e80@san-francisco.beasys.com> Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: text/plain; charset=US-ASCII Date: Thu, 17 May 2001 08:43:43 -0700 From: Darryl Okahata Andy Piper wrote: > Its not that simple. I don't get it with my .emacs. At some point during my > editing it starts happening. If it's really unrelated to autoloads, or some evil mode, it could be a nasty memory corruption error (improper gcpro's, etc.). If so, good luck tracking it down. [ I suppose it could also be a cygwin problem (I assume that you're using cygwin). Is there a correlation with the compiler used (cygwin, mingw, vc++, etc.)? What's Paul using? ] -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From youngs@xemacs.org Thu May 17 12:16:00 2001 Received: from mail003.syd.optusnet.com.au (mail003.syd.optusnet.com.au [203.2.75.251]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA28194 for ; Thu, 17 May 2001 12:15:58 -0400 Received: from slackware.mynet.pc (wdcax13-068.dialup.optusnet.com.au [198.142.220.68]) by mail003.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4HGFnO22656 for ; Fri, 18 May 2001 02:15:49 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4HGAbeK019226; Fri, 18 May 2001 02:10:37 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Updated Packages in Pre-Releases - May 18 From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 18 May 2001 02:10:37 +1000 Message-ID: Lines: 177 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii The following packages are now in the 'Pre-Releases' directory: build-1.02-pkg.tar.gz ===================== 2001-05-13 Adrian Aichner * build.el (build-from-CVS): Name buffer correctly. * build.el (build-tarball-site): Update download sites from XEmacs-21.4.2/etc/FTP. * build.el (build-with-MS): Use version.sh of directory we build in and customize build-report-version-file accordingly (without saving in order to stay out of build-report's way). * build.el (build-with-MS-make-commandline): Removed. calc-1.16-pkg.tar.gz ==================== 2001-05-12 Karl M. Hegbloom * calc.el (calc-quit): Guard against kbuf eq nil 2001-05-11 Ben Wing * Makefile: Fix to compile in the absence of an installed package tree. edit-utils-1.60-pkg.tar.gz ========================== 2001-05-11 Ben Wing * func-menu.el: typo fix. * recent-files.el: autoload the init function. efs-1.25-pkg.tar.gz =================== 2001-05-17 Michael Sperber [Mr. Preprocessor] * RELEASE: 1.20pre1 2001-05-17 Michael Sperber [Mr. Preprocessor] * efs.el (efs-skip-msgs-alist): Create, generalizing `efs-skip-msgs'. This hopefully will cure the gratuitous "EPSV not understood" messages spewed out by some ftp clients. (efs-skip-cmd-msg-p): Create. (efs-cmd-ok-cmds-msgs-alist): Create, generalizing `efs-cmd-ok-cmds' and `efs-cmd-ok-msgs'. (efs-process-handle-line): Use above. (efs-send-cmd): Handle null directory to avoid arg count mismatch. (efs-good-msgs): Shorten "hash mark" regexp. (efs-hash-mark-msgs): Shorten "hash mark" regexp. 2001-05-06 Michael Sperber [Mr. Preprocessor] * efs.el (efs-write-region): Restore `buffer-modified-p' on all conditions. 2001-01-17 Edwin Steiner * efs.el (efs-quote-local-paths): Adds a customization variable `efs-quote-local-paths'. If it is non-nil, local path names in FTP commands are quoted (\ becomes \\ ...) by the new function `efs-quote-local-path.' This is to support a ported version of a unix FTP client under Win98 which expects local path names to be quoted. 2000-10-15 Martin Buchholz * *: spelling fixes. 2000-10-15 Michael Sperber [Mr. Preprocessor] * efs.el (efs-ls): CWD to nondirectory part of `file' instead in an attempt to prevent spurious CWD's to non-directories. 2000-10-15 Katsumi Yamaoka * efs.el (efs-ls): Preserve `temp' and `nlist' across continuation. 2000-07-16 Michael Sperber [Mr. Preprocessor] * efs.el (efs-ls): Proper `noerror' handling for CWD. 2000-07-12 Ben Wing * efs.el: * efs.el (efs-null-device): New. * efs.el (efs-tmp-name-template): Fix up problems with Cygwin FTP client and Windows native XEmacs. * efs.el (efs-expand-tilde): Use efs-null-device. * efs.el (efs-guess-host-type): ditto. mailcrypt-2.08-pkg.tar.gz ========================= 2001-05-06 Brian Warner * mc-gpg.el (mc-gpg-lookup-key): Change key-regexp to tolerate extra fields at the end of lines emitted by --with-colons mode. Needed to handle new output format in gnupg-1.0.5, otherwise you get "No GPG secret key for xxx" errors. xemacs-base-1.54-pkg.tar.gz =========================== 2001-05-13 Adrian Aichner * compile.el (compilation-setup): Add `compile-mouse-maybe-goto-error' to global value of `mouse-track-click-hook' to fix mouse-track-insert between buffers. 2001-05-11 Ben Wing * compile.el (compilation-find-file): warning fix. * sort.el: * sort.el (sort-regexp-history): New. * sort.el (sort-regexp-fields): * sort.el (sort-regexp-fields-numerically): * sort.el (sort-columns-subprocess): snarf the region before asking questions. xemacs-devel-1.35-pkg.tar.gz ============================ 2001-05-16 Didier Verna * Patcher 2.4 is released. Packages also in Pre-Releases announced earlier: ----------------------------------------------- cc-mode-1.25-pkg.tar.gz egg-its-1.26-pkg.tar.gz mule-base-1.38-pkg.tar.gz net-utils-1.16-pkg.tar.gz pc-1.20-pkg.tar.gz prog-modes-1.38-pkg.tar.gz Installing these: ================ Manually: -------- 1) Download whichever packages you wish to install from: ftp.xemacs.org/pub/xemacs/beta/experimental/packages/ 2) Unpack them to: [1] /usr/local/lib/xemacs/xemacs-packages/ 3) Re-start XEmacs. Automatically: (XEmacs 21.1.14) ------------- 1) Options -> Manage Packages -> Add Download Site -> Pre-Releases 2) Options -> Manage Packages -> List and Install 3) Select the packages you wish to install (there are brief instructions at the bottom of the Packages buffer). 4) Packages -> Install/Remove Selected 5) Re-start XEmacs. Automatically: (XEmacs 21.2 and above) ------------- 1) Tools -> Packages -> Add Download Site -> Pre-Releases 2) Tools -> Packages -> List and Install 3 - 5) As per XEmacs 21.1.14. Thank you all very much for taking the time to test these. Please let me know of your successes as well as any failures. Footnotes: [1] Any Mule packages go in /usr/local/lib/xemacs/mule-packages/ -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From ovidiu@orion.nsr.hp.com Thu May 17 13:06:08 2001 Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA31363; Thu, 17 May 2001 13:06:07 -0400 Received: from orion.nsr.hp.com (orion.nsr.hp.com [15.47.171.122]) by palrel2.hp.com (Postfix) with ESMTP id A74CA3DDD; Thu, 17 May 2001 10:06:02 -0700 (PDT) Received: (from ovidiu@localhost) by orion.nsr.hp.com (8.9.3/8.9.3/client.cv) id KAA03682; Thu, 17 May 2001 10:06:01 -0700 Message-Id: <200105171706.KAA03682@orion.nsr.hp.com> X-Mailer: exmh 2.2 06/23/2000 with XEmacs 21.1.14 on Linux 2.2.13 From: Ovidiu Predescu To: Didier Verna Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. In-Reply-To: Your message of "17 May 2001 17:38:46 +0200." X-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ X-Image-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ovidiu.tiff X-Face: ?(@Y~qjBA}~8ZMh5gM4{Q{bE_*:sCJ3@Z?{B*Co=J!#8bb~-z?-0._vJjt~MM59!MjxG%>U 5>MW^2-\7~z04buszR^=m^U|m66>FdR@cFwhb;.A(8*D.QmLkK]z,md0'HiOE\pyeiv_PACR+P:Cm. wq_%l':E:q]g-UCc>r&s@BVo'kFN;(\9PF22Myg5w%nUBWQ6MJJ#qL#w>2oxckP'H:\$9F"mxsz]Dg k{1`fTcP'Y$CgGnc^paTV$dzhVX+;(U$;Eb)P<>G)g) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 10:06:01 -0700 Sender: ovidiu@orion.nsr.hp.com On 17 May 2001 17:38:46 +0200, Didier Verna wrote: > sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) wrote: > > > This is apparently a server-side problem. The out-of-memory problems > > are also still around. I see it happen only with ssh. :pserver: > > works better. > > Hmmm. I indeed used :ext: with my own account to perform the checkout. What I usually do in this case is to cd to the partially extracted directory and run cvs -q update -d -P This extracts the remaining of the tree. I do this repeatedly, until I get the whole tree. Greetings, -- Ovidiu Predescu http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) From didier@lrde.epita.fr Thu May 17 13:07:46 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA31496; Thu, 17 May 2001 13:07:45 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id TAA26892 Thu, 17 May 2001 19:05:37 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 150RDc-00012B-00; Thu, 17 May 2001 19:05:44 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 150RCz-0006fN-00; Thu, 17 May 2001 19:05:05 +0200 To: Ovidiu Predescu Cc: Didier Verna , sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: <200105171706.KAA03682@orion.nsr.hp.com> X-Attribution: drv In-Reply-To: <200105171706.KAA03682@orion.nsr.hp.com> (Ovidiu Predescu's message of "Thu, 17 May 2001 10:06:01 -0700") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj X-Web: http://www.xemacs.org X-Url: http://www.xemacs.org X-Home-Page: http://www.xemacs.org Organization: The XEmacs Project Date: 17 May 2001 19:05:05 +0200 Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id NAA31496 Ovidiu Predescu wrote: > What I usually do in this case is to cd to the partially extracted directory > and run > > cvs -q update -d -P > > This extracts the remaining of the tree. I do this repeatedly, until I > get the whole tree. That's never worked either :-( -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From mta@arbortext.com Thu May 17 14:02:21 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA02531; Thu, 17 May 2001 14:02:20 -0400 Date: Thu, 17 May 2001 14:02:18 -0400 From: Mike Alexander To: "Stephen J. Turnbull" , Yoshiki Hayashi cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: XEmacs patch status list Message-ID: <2265660513.990108138@[172.27.6.51]> In-Reply-To: <15107.42426.523156.26319@turnbull.sk.tsukuba.ac.jp> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit --On Thursday, May 17, 2001 7:19 PM +0900 "Stephen J. Turnbull" wrote: > I'm having trouble with the Web, Mike Alexander's patch labelled with > (?) I'm guessing at contents. > > 2001-02-24 Mike Alexander > Running sub-processes from modal loop > <16821421.3191976093@mta-1.pnet.msen.com> > http://list-archive.xemacs.org/xemacs-patches/200102/msg00130.html > Status: Discussion > > (?) --> I think this is in 21.4. Superceded for 21.5 by a Ben patch? This patch, or a later version of it, has been applied to both 21.4 and 21.5. I say this assuming that version 1.47.2.2 is the version in 21.4. That's where the R21-4-3 tag is located although the R21-2-latest-beta tag is still on version 1.47 Mike Alexander mailto:mta@arbortext.com Arbortext, Inc. +1-734-997-0200 From xemacs-announce-admin@xemacs.org Thu May 17 14:12:59 2001 Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA03380; Thu, 17 May 2001 14:12:56 -0400 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 150SBw-0006hE-00; Thu, 17 May 2001 11:08:04 -0700 Received: from gwyn.tux.org ([207.96.122.8] ident=ident-user) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 150SBU-0006Yi-00 for ; Thu, 17 May 2001 11:07:36 -0700 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA02990 for ; Thu, 17 May 2001 14:07:33 -0400 Received: by localhost id m150SBS-000143C (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 18 May 2001 03:07:34 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.4965.888565.989681@turnbull.sk.tsukuba.ac.jp> Date: Fri, 18 May 2001 03:07:33 +0900 To: xemacs-announce@xemacs.org From: "Stephen Turnbull, XEmacs 21.4 Release Manager" Subject: XEmacs 21.4.3 "Academic Rigor" is released. X-Mailer: VM 6.92 under 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid Sender: xemacs-announce-admin@xemacs.org Errors-To: xemacs-announce-admin@xemacs.org X-BeenThere: xemacs-announce@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Announcements List-Unsubscribe: , * XEmacs 21.4.3 "Academic Rigor" is released. "Academic Rigor" is the fourth in the OXYMORON series. Relative to XEmacs 21.4.2 "Developer-Friendly Unix APIs", it contains fixes to two build bugs on Windows platforms and one for TTY-only, and a few typo fixes in the documentation. More detailed information about the changes is presented below. The first release in this series, Xemacs 21.4.0 "Solid Vapor", contained a large number of improvements and extensions to the current stable version, XEmacs 21.1.14. For more information about the OXYMORON series, see etc/NEWS, the initial release announcement http://www.xemacs.org/Releases/21.4.0.html and the release planning page, http://www.xemacs.org/Releases/Public-21.2/. For general information about XEmacs, the developers, and the user community, see our home page, http://www.xemacs.org/. * XEmacs 21.4.3 is "gamma" software. Besides the usual "no warranty" disclaimer (see etc/WARRANTY, sections 10 and 11), we are now experimenting with a level of stability intermediate between "beta" and "stable", dubbed "gamma". At this point all the developers and most of our beta testers trust the 21.4 code base with all their editing needs. However, for several reasons, for users who absolutely must minimize risk, we continue to recommend the 21.1 series. Nevertheless, almost all users will get very high reliability from XEmacs 21.4, and in return, access to many new features and improved functionality. No new destabilizing code will be added; each release in the 21.4 series should be strictly more stable and bug-free than the preceding one. We also recommend the 21.4 series to distribution packagers (such as Linux distributions and the open source BSD "ports" or "packages" maintainers) for their "testing" and "development" distributions. * Changes included in XEmacs 21.4.3 "Academic Rigor" There are no user-visible behavior changes. - (All Windows) Restore include of src/events-mod.h. - (Cygwin) Detect Windows native sound under Cygwin - (TTY-only) Restore patch for building --with-scrollbars=no - (small stack Unix) Can build with -DREGEX_MALLOC. - Update package docs - More photos - Misc comment fixes in source Thanks to Adrian Aichner (and several others) and Karl Hegbloom for catching me where I missed patches. Thanks to Yoshiki Hayashi, Paul Stodghill, and Steve Youngs for patches. * Getting and Installing XEmacs 21.4.3 XEmacs 21.4.3 is available in source form, including pre-compiled "core" Lisp libraries and pre-built Info files, from ftp.xemacs.org and mirrors (http://www.xemacs.org/Download/index.html#mirror_index). The file INSTALL in the top directory of the sources explains how to build XEmacs on Unix. The equivalent for Windows is nt/README. Note that building XEmacs 21.4 on Windows ME and other 9x variants is not currently supported. If you want to help fix the problems, please join the xemacs-nt mailing list. See http://www.xemacs.org/Download/ for general information about downloading XEmacs. For those wedded to their old command-line FTP client, the following URLs may be useful: ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4/xemacs-21.4.3.tar.gz or build the Lisp and Info from source, saving download time, with ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4/xemacs-21.4.3-src.tar.gz In either case, you need the "packaged Lisp" for more than the most basic functionality. You may use packages previously installed for use with XEmacs 21.1 or later without change. For new installations, the "SUMO" distribution of (almost) all packaged Lisp is available as ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo.tar.gz ftp://ftp.xemacs.org/pub/xemacs/packages/xemacs-mule-sumo.tar.gz The latter should be installed only if you are building XEmacs with the MULE multilingual support; it contains Lisp files that cannot be correctly loaded by a unibyte XEmacs. See README.packages. XEmacs 21.4.3 is also available via anonymous CVS. To get the latest in the 21.4 series, check out (or update) with the "release-21-4" tag. This should be sufficient for almost all users; throughout this series patches will be carefully screened to ensure that every release is more stable than the last. If for some reason you specifically want this release, use the "r21-4-3" tag. See http://cvs.xemacs.org/ for general instructions on getting XEmacs via anonymous CVS. Binary kits are not planned at this time, except for selected releases for the MS Windows platform. Setups based on the Cygwin "netinstaller", Wise installer, and Installshield are in various degrees of readiness. The adventurous can subscribe to the xemacs-nt mailing list to learn about prerelease tests. The current public release for Windows is based on 21.4.0 "Solid Vapor". http://www.xemacs.org/Download/win32/setup.exe We are considering providing binary kits for important platforms that lack independent distributors once 21.4 is accepted as "stable". Volunteers should contact the Release Manager, "Stephen Turnbull" , and let me know for which platforms you can build. * Important notices for CVS users: The structure of the CVS repository for packaged Lisp is in the process of being reorganized, thanks to Steve Youngs. This will involve a change in the default hierarchy of workspaces. Please watch the xemacs-beta mailing list for details. The structure of the CVS repository for XEmacs sources has been rationalized thanks to Michael Sperber. The development code is now on the trunk. See earlier release announcements for details. Eg, http://www.xemacs.org/Releases/21.4.0.content#cvs * Thanks ... to all the developers, reviewers, and testers; to the Electrotechnical Laboratory and BeOpen.com for financial support; to Tux.org and SourceForge[tm] for hosting services; and to our users. May 17, 2001 XEmacs 21.4 Release Manager Stephen J. Turnbull -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From dahlman@CS.ColoState.EDU Thu May 17 14:32:16 2001 Received: from sibelius.cs.colostate.edu (sibelius.cs.colostate.edu [129.82.45.48]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA04970 for ; Thu, 17 May 2001 14:32:15 -0400 Received: (from dahlman@localhost) by sibelius.cs.colostate.edu (8.9.3/8.9.3) id MAA13668; Thu, 17 May 2001 12:32:05 -0600 (MDT) Date: Thu, 17 May 2001 12:32:05 -0600 (MDT) Message-Id: <200105171832.MAA13668@sibelius.cs.colostate.edu> From: eric dahlman To: xemacs-beta@xemacs.org Subject: M-y is stubborn This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta46) "Urania" [Lucid] (sparc-sun-solaris2.8) of Tue Apr 10 2001 on sibelius configured using `configure --prefix=/s/chopin/d/proj/meps/common' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I have noticed that when I yank text with C-y and then want to go back through the kill ring with M-y it takes several M-y's before the first thing yanked is replaced by something different. I have noticed this for a while across several versions, I just finely got irritated enough to complain about it ;-) The recent keystrokes below contain my entire test run in a vanilla xemacs. I believe the the first M-y should have altered my inserted text but in this case it did not change until the fourth try. Thanks, -Eric Recent keystrokes: button1 button1up a a a RET b b b RET c c c RET d d d RET e e e RET up up up C-k C-y down down down C-y up up left left left C-k C-y down down down RET C-y up up up up up left left left C-k C-y down down down down down RET C-b down C-y RET C-y M-y M-y M-y M-y misc-user Recent messages (most recent first): Parsing /s/chopin/a/grad/dahlman/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... From turner@blueskystudios.com Thu May 17 14:32:44 2001 Received: from ns.blueskystudios.com (ns.blueskystudios.com [63.108.102.34]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA05001; Thu, 17 May 2001 14:32:44 -0400 Received: from bet.blueskystudios.com (maginot-psn.blueskystudios.com [192.168.2.1]) by ns.blueskystudios.com (8.9.3/8.9.3) with ESMTP id OAA33761; Thu, 17 May 2001 14:32:43 -0400 (EDT) Received: from denmark.blueskystudios.com (denmark.blueskystudios.com [10.1.10.71]) by bet.blueskystudios.com (8.11.1/8.11.1) with ESMTP id f4HIWhu64440; Thu, 17 May 2001 14:32:43 -0400 (EDT) Received: (from turner@localhost) by denmark.blueskystudios.com (8.9.3/8.9.3) id OAA87725; Thu, 17 May 2001 14:32:42 -0400 (EDT) From: "John A. Turner" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.6474.244656.828253@denmark.blueskystudios.com> Date: Thu, 17 May 2001 14:32:42 -0400 To: youngs@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: mule question In-Reply-To: References: <15070.11973.9609.164337@denmark.blueskystudios.com> X-PGP-Fingerprint: 64 CF BC 31 E1 15 ED 5D E1 BE F5 7F CD 5D 99 34 X-Caffeination-Level: High X-URL: http://john.turner.org/ X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Face: One of my favorite quotes... Music is the cup which holds the wine of silence; sound is that cup, but empty; noise is that cup, but broken. - Robert Fripp >>>>> "SY" == Steve Youngs : SY> This definitely shouldn't happen. A non-Mule XEmacs won't see the SY> packages in ./mule-packages/. Or, at least it won't by default. SY> SY> What's in your load-path? SY> SY> Could we see your: SY> SY> ~/.emacs or ~/.xemacs/init.el SY> M-x describe-installation SY> SY> please. after re-building the non-mule with --package-path=/usr/net/rnd/lib/xemacs/xemacs-packages instead of --package-path=/usr/net/rnd/lib/xemacs though in another msg in that thread SJT said he didn't think this was the best solution... however, since the above cured that particular itch, I stopped scratching it... -JT From steve@turnbull.sk.tsukuba.ac.jp Thu May 17 14:35:00 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA05206; Thu, 17 May 2001 14:34:59 -0400 Received: by localhost id m150Sbs-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 18 May 2001 03:34:52 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.6586.576361.974082@turnbull.sk.tsukuba.ac.jp> Date: Fri, 18 May 2001 03:34:34 +0900 To: Mike Alexander Cc: Yoshiki Hayashi , xemacs-beta@xemacs.org Subject: Re: XEmacs patch status list In-Reply-To: <2265660513.990108138@[172.27.6.51]> References: <15107.42426.523156.26319@turnbull.sk.tsukuba.ac.jp> <2265660513.990108138@[172.27.6.51]> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Mike" == Mike Alexander writes: > 2001-02-24 Mike Alexander > Running sub-processes from modal loop Mike> This patch, or a later version of it, has been applied to Mike> both 21.4 and 21.5. Good. Mike> I say this assuming that version 1.47.2.2 is the version in Mike> 21.4. That's where the R21-4-3 tag is located although the Mike> R21-2-latest-beta tag is still on version 1.47 That's correct. The r21-2-latest-beta tag is now obsolete; there will be no more releases in the 21.2 series. It has forked into 21.4 and 21.5. The current "latest" tag is "r21-5-latest-beta". The stable branches don't really need "latest" tags, since both Vin and I tend to batch our commits just before the release, and they don't have them. Identify the current status of those branches with the branch tags, "release-21-1" and "release-21-1". 21.5 is on the trunk, so it doesn't have a branch tag. Life with CVS is like that. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From andyp@bea.com Thu May 17 15:26:29 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA09291; Thu, 17 May 2001 15:26:25 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA00819; Thu, 17 May 2001 12:26:31 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001320wss.beasys.com [192.168.6.151]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id MAA26244; Thu, 17 May 2001 12:26:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20010517121830.00b0a920@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 May 2001 12:24:04 -0700 To: xemacs-patches@xemacs.org From: Andy Piper Subject: Minor build fixes for 21.4.3 Cc: xemacs-beta@xemacs.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_6612738==_" --=====================_6612738==_ Content-Type: text/plain; charset="us-ascii"; format=flowed I didn't deliberately do this just after Stephen released. These are needed for correct compilation under cygwin 1.3.1. Should be applied to 21.5 as well [I'm beginning to love perforce - the way you can do integs across versions easily]. andy 2001-05-17 Andy Piper * sysfile.h: don't assume that file attributes are boolean 2001-05-17 Andy Piper * win32.h: * win32.h (NOCOMATTRIBUTE): sync with latest cygwin version. --=====================_6612738==_ Content-Type: application/octet-stream; name="min.patch" Content-Disposition: attachment; filename="min.patch" Content-Transfer-Encoding: base64 SW5kZXg6IG5ldGluc3RhbGwvd2luMzIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdXNyL0NWU3Jv b3QvWEVtYWNzL3hlbWFjcy9uZXRpbnN0YWxsL3dpbjMyLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9u IDEuMgpkaWZmIC11IC1yMS4yIHdpbjMyLmgKLS0tIG5ldGluc3RhbGwvd2luMzIuaAkyMDAxLzA0 LzEyIDE4OjIyOjU2CTEuMgorKysgbmV0aW5zdGFsbC93aW4zMi5oCTIwMDEvMDUvMTcgMTk6MjA6 NTMKQEAgLTIxLDI0ICsyMSwxNCBAQAogI2lmbmRlZiBfTUlOSV9XSU4zMl8KICNkZWZpbmUgX01J TklfV0lOMzJfCiAKLSNkZWZpbmUgX1VOSU9OX05BTUUoeCkKLSNkZWZpbmUgX1NUUlVDVF9OQU1F KHgpCiAjZGVmaW5lIE5PQ09NQVRUUklCVVRFCiAKICNpbmNsdWRlIDxzdGRhcmcuaD4KLSNpZmRl ZiBXSU4zMl9OQVRJVkUKLS8qIE1TVkMgaXMgYmFya2luZyB3aXRoIHRoZSBsaXN0IGFib3ZlLCBz b21ldGhpbmcgZWxzZSBpcyBtaXNzaW5nLCBzbwotICAgSSdtIHVzaW5nIDx3aW5kb3dzLmg+IGFu ZCBsZWFuLW4tbWVhbi4gRlAsIDIwMDAtMjMtMTIgKi8KKworI2RlZmluZSBXSU4zMl9MRUFOX0FO RF9NRUFOCiAjaW5jbHVkZSA8d2luZG93cy5oPgotI2VuZGlmCi0jaW5jbHVkZSA8d2luZGVmLmg+ Ci0jaW5jbHVkZSA8YmFzZXR5cHMuaD4KLSNpbmNsdWRlIDx3aW5iYXNlLmg+Ci0jaW5jbHVkZSA8 d2luZ2RpLmg+Ci0jaW5jbHVkZSA8d2ludXNlci5oPgotI2luY2x1ZGUgPHdpbmluZXQuaD4KLSNp bmNsdWRlIDx3aW5yZWcuaD4KIAorI2luY2x1ZGUgPHdpbmluZXQuaD4KICNpbmNsdWRlIDx3aW5k b3dzeC5oPgogCiAvKiBDb3BlIHdpdGggbmF0aXZlIHdpbjMyICYgbWluZ3cgZGlmZmVyZW5jZXMu ICBXcml0dGVuIGJ5IEYuIFBvcGluZWF1CkluZGV4OiBzcmMvc3lzZmlsZS5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K UkNTIGZpbGU6IC91c3IvQ1ZTcm9vdC9YRW1hY3MveGVtYWNzL3NyYy9zeXNmaWxlLmgsdgpyZXRy aWV2aW5nIHJldmlzaW9uIDEuOQpkaWZmIC11IC1yMS45IHN5c2ZpbGUuaAotLS0gc3JjL3N5c2Zp bGUuaAkyMDAxLzA0LzEyIDE4OjI0OjIyCTEuOQorKysgc3JjL3N5c2ZpbGUuaAkyMDAxLzA1LzE3 IDE5OjIwOjU3CkBAIC0xNzgsNyArMTc4LDcgQEAKICNkZWZpbmUgbHN0YXQgeGVtYWNzX3N0YXQK ICNlbmRpZgogCi0jaWYgIVNfSVJVU1IKKyNpZm5kZWYgU19JUlVTUgogIyBpZiBTX0lSRUFECiAj ICBkZWZpbmUgU19JUlVTUiBTX0lSRUFECiAjIGVsc2UKQEAgLTE4Niw3ICsxODYsNyBAQAogIyBl bmRpZgogI2VuZGlmCiAKLSNpZiAhU19JV1VTUgorI2lmbmRlZiBTX0lXVVNSCiAjIGlmIFNfSVdS SVRFCiAjICBkZWZpbmUgU19JV1VTUiBTX0lXUklURQogIyBlbHNlCkBAIC0xOTQsNyArMTk0LDcg QEAKICMgZW5kaWYKICNlbmRpZgogCi0jaWYgIVNfSVhVU1IKKyNpZm5kZWYgU19JWFVTUgogIyBp ZiBTX0lFWEVDCiAjICBkZWZpbmUgU19JWFVTUiBTX0lFWEVDCiAjIGVsc2UK --=====================_6612738==_-- From oberman@ptavv.es.net Thu May 17 17:07:26 2001 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA16401 for ; Thu, 17 May 2001 17:07:26 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f4HL7Lc19966 for ; Thu, 17 May 2001 14:07:21 -0700 (PDT) Message-Id: <200105172107.f4HL7Lc19966@ptavv.es.net> To: XEmacs Beta List Subject: Problems with 21.4.3 "Academic Rigor" Date: Thu, 17 May 2001 14:07:21 -0700 From: "Kevin Oberman" I have had several problems with 21.4.3, the first to mention is that I could not do a send-pr. When I invoke M-x send-pr, I get the message: send-pr: the GNATS site xemacs.org does not have a categories list. Sigh. So I am sending in several problem reports to this list pending the ability to run send-pr. Built on Tru64 UNIX V4.0d and configured as: ./configure --without-gcc '--cflags=-fast -std' --with-site-lisp --site-includes=/usr/local/include More serious problems to follow. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From oberman@ptavv.es.net Thu May 17 17:15:35 2001 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA16823 for ; Thu, 17 May 2001 17:15:32 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f4HLFWc30089 for ; Thu, 17 May 2001 14:15:32 -0700 (PDT) Message-Id: <200105172115.f4HLFWc30089@ptavv.es.net> To: XEmacs Beta List Subject: Problems migrating init file in 21.4.3 Date: Thu, 17 May 2001 14:15:32 -0700 From: "Kevin Oberman" I just installed 21.4.3. send-pr (see earlier message) won't work, so I'm just mailing the bugs in. After fixing or commenting out code in my .emacs file that would not play with 21.4.3, I tried M-x migrate-user-init-file. It seemed to run OK, but the next time I started XEmacs, it said it could not find my init file. I looked in ~/.xemacs and saw init.el, but it was a link to ./emacs.laptop. But .emacs.laptop is located in my root directory. Why is it trying to use .emacs.laptop? I don't know. But I fixed the symlink and it seems to be OK, now. It may be because I had a symlink for .emacs. I don't remember, but it is possible. It did correctly strip the custom stuff out and put it in ~/.xemacs/custom.el. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From oberman@ptavv.es.net Thu May 17 17:40:08 2001 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA17879 for ; Thu, 17 May 2001 17:40:05 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f4HLdYc28642 for ; Thu, 17 May 2001 14:39:34 -0700 (PDT) Message-Id: <200105172139.f4HLdYc28642@ptavv.es.net> To: XEmacs Beta List Subject: No gnuserv installed in 21.4.3 Date: Thu, 17 May 2001 14:39:34 -0700 From: "Kevin Oberman" Sorry, but as previously reported, send-pr does not seem to be working in 21.4.3. After installing 21.4.3 I could not longer start gnuserv. I checked and there was no binary installed. I checked and I saw no indication that 'make install' made any attempt to install gnuserv. Here is the relevant text from the 'make install': for subdir in lib-src src; do (cd ./${subdir} && make CC='cc' CFLAGS='-fast -std' LDFLAGS='' CPPFLAGS='' install prefix=/usr/local exec_prefix=/usr/local bindir=/usr/local/bin libdir=/usr/local/lib archlibdir=/usr/local/lib/xemacs-21.4.3/alphaev56-dec-osf4.0d) ; done Installing utilities for users to run. for file in gnuclient ellcc etags ctags b2m ootags ; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c lib-src/${file} /usr/local/bin/${file}) ; done for file in gnudoit gnuattach rcs-checkin ; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c /home/oberman/utils/xemacs-21.4.3/lib-src/${file} /usr/local/bin/${file}) ; done I then went back into xemacs-21.4.3/lib-src and did 'make install. Still no joy: make install Installing utilities for users to run. for file in gnuclient ellcc etags ctags b2m ootags ; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c lib-src/${file} /usr/local/bin/${file}) ; done for file in gnudoit gnuattach rcs-checkin ; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c /home/oberman/utils/xemacs-21.4.3/lib-src/${file} /usr/local/bin/${file}) ; done Finally I did 'make clean', 'make', 'make install'. This worked: # make install Installing utilities run internally by XEmacs. ./make-path /usr/local/lib/xemacs-21.4.3/alphaev56-dec-osf4.0d if test "`(cd /usr/local/lib/xemacs-21.4.3/alphaev56-dec-osf4.0d && /bin/pwd)`" != "`/bin/pwd`"; then for f in gnuserv fakemail wakeup profile make-docfile digest-doc sorted-doc movemail cvtmail yow hexl mmencode; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c lib-src/$f /usr/local/lib/xemacs-21.4.3/alphaev56-dec-osf4.0d/$f) ; done ; fi if test "`(cd /usr/local/lib/xemacs-21.4.3/alphaev56-dec-osf4.0d && /bin/pwd)`" != "`(cd /home/oberman/utils/xemacs-21.4.3/lib-src && /bin/pwd)`"; then for f in rcs2log vcdiff gzip-el.sh add-big-package.sh; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c /home/oberman/utils/xemacs-21.4.3/lib-src/$f /usr/local/lib/xemacs-21.4.3/alphaev56-dec-osf4.0d/$f); done ; fi Installing utilities for users to run. for file in gnuclient ellcc etags ctags b2m ootags ; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c lib-src/${file} /usr/local/bin/${file}) ; done for file in gnudoit gnuattach rcs-checkin ; do (cd .. && /home/oberman/utils/xemacs-21.4.3/install.sh -c /home/oberman/utils/xemacs-21.4.3/lib-src/${file} /usr/local/bin/${file}) ; done A quick look at the Makefile makes it appearant that the problem is somehow in: ${archlibdir}: all @echo; echo "Installing utilities run internally by XEmacs." ./make-path ${archlibdir} if test "`(cd ${archlibdir} && $(pwd))`" != "`$(pwd)`"; then \ I'm not much at shell programming, and I am baffled as to what is supposed to be happening here. But it is not working right! R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From oberman@ptavv.es.net Thu May 17 17:49:35 2001 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA18348 for ; Thu, 17 May 2001 17:49:34 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f4HLnXc31113 for ; Thu, 17 May 2001 14:49:33 -0700 (PDT) Message-Id: <200105172149.f4HLnXc31113@ptavv.es.net> To: xemacs-beta@xemacs.org Subject: x-set-frame-icon-pixmap no longer there Date: Thu, 17 May 2001 14:49:33 -0700 From: "Kevin Oberman" Seems like the function x-set-frame-icon-pixmap has vanished since 21.1.13. Any idea how to replace it? I see the variable: frame-icon-glyph which looks promising, but the documentation does not make it clear how I should use it. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From mschulkind@mailandnews.com Thu May 17 18:05:58 2001 Received: from MailAndNews.com ([199.29.68.121]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA19153 for ; Thu, 17 May 2001 18:05:58 -0400 Received: from myroom [65.96.9.187] (mschulkind@mailandnews.com) by MailAndNews.com; Thu, 17 May 2001 18:05:33 -0400 X-WM-Posted-At: MailAndNews.com; Thu, 17 May 01 18:05:33 -0400 Message-ID: <000c01c0df1d$7652aff0$0500a8c0@myroom> From: "Matt Schulkind" To: Subject: Displayed Tabs Date: Thu, 17 May 2001 18:04:56 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C0DEFB.E12638F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C0DEFB.E12638F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How would I go about having all open files have a tab right below the = toolbar, right now I'm not quite sure how xemacs chooses which files go = there, but I'd like all to go there. Also, where in the furture would I = find this information out on my own? Please cc all replies to me as I'm not on the list. -Matt ------=_NextPart_000_0009_01C0DEFB.E12638F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How would I go about having all open = files have a=20 tab right below the toolbar, right now I'm not quite sure how xemacs = chooses=20 which files go there, but I'd like all to go there. Also, where in the = furture=20 would I find this information out on my own?
 
Please cc all replies to me as I'm not = on the=20 list.
 
-Matt
------=_NextPart_000_0009_01C0DEFB.E12638F0-- From andyp@bea.com Thu May 17 18:24:03 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA20023 for ; Thu, 17 May 2001 18:23:59 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA11930; Thu, 17 May 2001 15:24:05 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001365wss.beasys.com [192.168.6.196]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08723; Thu, 17 May 2001 15:24:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20010517152012.00b0e9e0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 May 2001 15:21:38 -0700 To: "Matt Schulkind" , From: Andy Piper Subject: Re: Displayed Tabs In-Reply-To: <000c01c0df1d$7652aff0$0500a8c0@myroom> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The tabs are grouped by mode. Look in custom in the buffers-tab group for customization points. andy At 06:04 PM 5/17/01 -0400, Matt Schulkind wrote: >How would I go about having all open files have a tab right below the >toolbar, right now I'm not quite sure how xemacs chooses which files go >there, but I'd like all to go there. Also, where in the furture would I >find this information out on my own? > >Please cc all replies to me as I'm not on the list. > >-Matt From hniksic@arsdigita.com Thu May 17 18:24:10 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA20039 for ; Thu, 17 May 2001 18:24:09 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 150WBh-0004Uy-00; Fri, 18 May 2001 00:24:05 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List , "Kevin Oberman" Subject: Re: x-set-frame-icon-pixmap no longer there References: <200105172149.f4HLnXc31113@ptavv.es.net> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 18 May 2001 00:24:05 +0200 In-Reply-To: <200105172149.f4HLnXc31113@ptavv.es.net> ("Kevin Oberman"'s message of "Thu, 17 May 2001 14:49:33 -0700") Message-ID: Lines: 10 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Kevin Oberman" writes: > Seems like the function x-set-frame-icon-pixmap has vanished since > 21.1.13. Any idea how to replace it? I see the variable: > frame-icon-glyph which looks promising, but the documentation does not > make it clear how I should use it. Try: (set-glyph-image frame-icon-glyph "image-file-name") From oberman@ptavv.es.net Thu May 17 19:10:46 2001 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA22181 for ; Thu, 17 May 2001 19:10:46 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f4HNAfc03845; Thu, 17 May 2001 16:10:42 -0700 (PDT) Message-Id: <200105172310.f4HNAfc03845@ptavv.es.net> To: Hrvoje Niksic cc: XEmacs Beta List Subject: Re: x-set-frame-icon-pixmap no longer there In-reply-to: Your message of "18 May 2001 00:24:05 +0200." Date: Thu, 17 May 2001 16:10:41 -0700 From: "Kevin Oberman" Thanks, Hrvoje! That did the trick. Now I can tell which system the icon is from. (I have a custom icon for each system I run XEmacs on.) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 > Sender: hniksic@florida.arsdigita.de > From: Hrvoje Niksic > Date: 18 May 2001 00:24:05 +0200 > > "Kevin Oberman" writes: > > > Seems like the function x-set-frame-icon-pixmap has vanished since > > 21.1.13. Any idea how to replace it? I see the variable: > > frame-icon-glyph which looks promising, but the documentation does not > > make it clear how I should use it. > > Try: > > (set-glyph-image frame-icon-glyph "image-file-name") > From youngs@xemacs.org Thu May 17 19:29:52 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA23380 for ; Thu, 17 May 2001 19:29:50 -0400 Received: from slackware.mynet.pc (wdcax13-068.dialup.optusnet.com.au [198.142.220.68]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4HNTke08252 for ; Fri, 18 May 2001 09:29:47 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4HNOXoB022181; Fri, 18 May 2001 09:24:33 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 18 May 2001 09:24:33 +1000 In-Reply-To: (Didier Verna's message of "17 May 2001 17:12:31 +0200") Message-ID: Lines: 25 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "drv" == Didier Verna writes: drv> Just for the record, I've been unable to check out the complete drv> package archive correctly for *years*. On my debian unstable system, cvs 1.11 drv> barfs when checking out skk: drv> [...] drv> U packages/mule-packages/skk/etc/ReadMe.10 drv> U packages/mule-packages/skk/etc/ReadMe.English drv> Terminated with fatal signal 11 Yeah, it's barfing on 'SKK-JISYO.L'. I had the same problem, and after half a dozen retries I ended up grabbing a copy of the file I had somewhere else and manually editing CVS/Entries. [1] Footnotes: [1] Please don't try this at home kids. I got away with it simply because I was damn lucky. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From yoshiki@xemacs.org Thu May 17 22:13:54 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31086; Thu, 17 May 2001 22:13:53 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4I2DlZ12801; Fri, 18 May 2001 11:13:47 +0900 Mail-Copies-To: nobody To: Craig Lanning Cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: XEmacs patch status list References: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> <200105171203.IAA12580@gwyn.tux.org> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 18 May 2001 11:13:46 +0900 In-Reply-To: <200105171203.IAA12580@gwyn.tux.org> (Craig Lanning's message of "Thu, 17 May 2001 07:59:44 -0400 (EDT)") Message-ID: <87wv7fe751.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 20 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Craig Lanning writes: > Is this list for 21.5 or 21.4? For 21.5. > The following patch was sent in for 21.5: > http://list-archive.xemacs.org/xemacs-patches/200105/msg00072.html > > Do you still need it re-sent? No, I just added it to my list. I think everyone still has it in his or her mailbox. Thanks for reminding me. It's ticked in my gnus summary buffer, but I forgot to add it to the list. I should improve my patch tracking script so that it would be more robust and automated... -- Yoshiki Hayashi From yoshiki@xemacs.org Thu May 17 22:18:56 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31322; Thu, 17 May 2001 22:18:55 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4I2IpZ12882; Fri, 18 May 2001 11:18:51 +0900 To: Andy Piper Cc: xemacs-review@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Minor build fixes for 21.4.3 References: <4.3.2.7.2.20010517121830.00b0a920@san-francisco.beasys.com> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 18 May 2001 11:18:51 +0900 In-Reply-To: <4.3.2.7.2.20010517121830.00b0a920@san-francisco.beasys.com> (Andy Piper's message of "Thu, 17 May 2001 12:24:04 -0700") Message-ID: <87u22je6wk.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 13 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Andy Piper writes: > I didn't deliberately do this just after Stephen released. These are needed > for correct compilation under cygwin 1.3.1. Should be applied to 21.5 as > well [I'm beginning to love perforce - the way you can do integs across > versions easily]. Let's help developing Subversion so that we can use decent open source software configuration management system. :-) http://subversion.tigris.org/ -- Yoshiki Hayashi From yoshiki@xemacs.org Thu May 17 22:23:22 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31571 for ; Thu, 17 May 2001 22:23:20 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4I2NJZ12955; Fri, 18 May 2001 11:23:19 +0900 Mail-Copies-To: nobody To: "Stephen J. Turnbull" Cc: karlheg@hegbloom.net (Karl M. Hegbloom), XEmacs Beta Subject: Re: [etc/xemacs-ja.1] Shouldn't it be named "xemacs.ja.1"? References: <874rupxbrj.fsf@bittersweet.intra.hegbloom.net> <15103.32907.490375.397597@turnbull.sk.tsukuba.ac.jp> <874rukgwrg.fsf@u.sanpo.t.u-tokyo.ac.jp> <15107.41607.26516.542347@turnbull.sk.tsukuba.ac.jp> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 18 May 2001 11:23:19 +0900 In-Reply-To: <15107.41607.26516.542347@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Thu, 17 May 2001 19:05:59 +0900") Message-ID: <87r8xne6p4.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 16 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) "Stephen J. Turnbull" writes: > >>>>> "Yoshiki" == Yoshiki Hayashi writes: > > Yoshiki> I'd rather just cvs remove this one. The translation is > Yoshiki> quite outdated and quality is not very good. > > Well, I'll trust your judgement on that for 21.5, take a quick peek at > it for form's sake, and probably remove it in 21.4 too. > > Maybe we should ask for volunteers on xemacs-mule-ja? Will do. -- Yoshiki Hayashi From steve@turnbull.sk.tsukuba.ac.jp Thu May 17 23:18:43 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA01761 for ; Thu, 17 May 2001 23:18:42 -0400 Received: by localhost id m150amj-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 18 May 2001 12:18:37 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15108.38009.30437.133236@turnbull.sk.tsukuba.ac.jp> Date: Fri, 18 May 2001 12:18:17 +0900 To: "Kevin Oberman" Cc: XEmacs Beta List Subject: No gnuserv installed in 21.4.3 In-Reply-To: <200105172139.f4HLdYc28642@ptavv.es.net> References: <200105172139.f4HLdYc28642@ptavv.es.net> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Thanks for all the careful reports! >>>>> "Kevin" == Kevin Oberman writes: Kevin> I checked and I saw no indication that 'make install' made Kevin> any attempt to install gnuserv. Here is the relevant text Kevin> from the 'make install': Since the "Installing utilities run internally by XEmacs." banner doesn't appear in any of the failures, I deduce that your conjecture about the shell script is incorrect. For some reason, make is concluding that ${archlibdir} is up-to-date even though it is empty. I am not a make expert, but I guess what needs to be done is to declare ${archlibdir} to be a phony target, so that it will get remade regardless of whether it exists or not. Note this code has been around for ages; it's not new to 21.4. What version of make are you using? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From ben@666.com Fri May 18 00:56:28 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id AAA06640 for ; Fri, 18 May 2001 00:56:28 -0400 Received: (qmail 54873 invoked by alias); 18 May 2001 04:56:22 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 54798 invoked by uid 0); 18 May 2001 04:56:20 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 18 May 2001 04:56:20 -0000 Message-ID: <3B04ABCF.F57DA046@666.com> Date: Thu, 17 May 2001 21:57:51 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Isaac Hollander CC: "William M. Perry" , xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> <200105152221.SAA08921@barry.mail.mindspring.net> <3B0304A1.2F991A93@666.com> <200105170314.XAA27100@johnson.mail.mindspring.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Isaac Hollander wrote: > > >> > Ben> can you get a c backtrace? > > Reproducing the crash again, I notice the following: > > [3]- User defined signal 1 ./xemacs > > I attached to the process with gdb, and as soon as I caused a sound > event, XEmacs caught a SIGUSR1. > > #0 0x40498897 in __libc_pause () from /lib/i686/libc.so.6 > #1 0x40360a20 in esd_open_sound (host=0x0) at esdlib.c:691 > #2 0x40360b11 in esd_play_stream (format=4112, rate=8000, host=0x0, > name=0x81ad040 "xemacs") at esdlib.c:740 > #3 0x080c8fb7 in esd_play_sound_data (data=0xbfffdb80 "RIFF\"\002", > length=554, vol=50) at esd.c:102 > #4 0x08158a54 in Fplay_sound (sound=137128548, volume=136371572, > device=138417888) at sound.c:337 > #5 0x08158f84 in Fding (arg=136371572, sound=137128548, device=136371572) > at sound.c:413 > #6 0x080ae97f in Ffuncall (nargs=3, args=0xbfffdf14) at eval.c:3528 > > So esd does evil things with SIGUSR1, and I think it's interfering with > XEmacs's handling of SIGUSR1. > > In xemacs-21.4.2/src/signal.c: > > static void > handle_signal_if_fatal (int signo) > { > if (signal (signo, fatal_error_signal) == SIG_IGN) > signal (signo, SIG_IGN); > } > > and > > #ifdef SIGUSR1 > handle_signal_if_fatal (SIGUSR1); /* POSIX */ > #endif > > I assume the /* POSIX */ comment means that SIGUSR1 is a POSIX signal as > opposed to an ANSI signal, not that the signal is handled with POSIX > sementics. > > So there's a possibility that in between the 2 calls to signal, another > signal could arrive, and since the signal is reset to default behavior, > the unignored SIGUSR1 causes a crash. > > Would using the POSIX signal functions (sigaction and friends) help here? actually we do use POSIX signals, although it's not obvious. take a look at syssignal.h and you'll see we #define signal. in this case, however, we're always aborting on USR1. [we don't actually make use of USR1 other than to make sure we do some cleanup before aborting on a fatal signal.] evidentally you should try modifying the code in esd.c to set up a temporary SIGUSR1 handler that does nothing during the call to esd_play_stream. > > Isaac -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Fri May 18 02:02:14 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id CAA09676 for ; Fri, 18 May 2001 02:02:10 -0400 Received: (qmail 73330 invoked by alias); 18 May 2001 06:02:08 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 73289 invoked by uid 0); 18 May 2001 06:02:07 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 18 May 2001 06:02:07 -0000 Message-ID: <3B04BB3E.464CAB6C@666.com> Date: Thu, 17 May 2001 23:03:42 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoshiki Hayashi CC: "Stephen J. Turnbull" , xemacs-beta@xemacs.org, xemacs-review@xemacs.org, ben@xemacs.org Subject: Re: XEmacs patch status list References: <87d798h2gf.fsf@u.sanpo.t.u-tokyo.ac.jp> <15107.42426.523156.26319@turnbull.sk.tsukuba.ac.jp> <87sni4fdxt.fsf@u.sanpo.t.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yoshiki Hayashi wrote: > > "Stephen J. Turnbull" writes: > > > 2001-02-24 Mike Alexander > > Running sub-processes from modal loop > > <16821421.3191976093@mta-1.pnet.msen.com> > > http://list-archive.xemacs.org/xemacs-patches/200102/msg00130.html > > Status: Discussion > > > > (?) --> I think this is in 21.4. Superceded for 21.5 by a Ben patch? > > Ben, could you comment? i think he means i already applied it, which i did. > > > 2001-03-19 Karl M. Hegbloom > > [cus-edit.el] Edit faces: Support GTK Window System also. > > <87d7bdfwxw.fsf@microsharp.com> > > http://list-archive.xemacs.org/xemacs-patches/200103/msg00065.html > > Status: Not reviewed > > > > --> In 21.4. Not applied to 21.5. > > I will apply it to 21.5. > > > 2001-05-10 Paul Stodghill > > Patch for sound under latest Cygwin > > > > http://list-archive.xemacs.org/xemacs-patches/200105/msg00053.html > > Status: Not reviewed > > > > --> Reviewed, tested, approved, applied to 21.4. Not applied to 21.5. > > This one, too. > > > 2001-05-11 Adrian Aichner > > [PATCH] Getting XEmacs-21.4.2 to Build on Native Windows > > > > http://list-archive.xemacs.org/xemacs-patches/200105/msg00056.html > > Status: Not reviewed > > > > --> Superceded by earlier patch applied to 21.4. Not for 21.5. > > I thought I removed this one from my list... > > > Missing: > > > > There's a Glynn Clements patch for input-method-motif.c, already in > > 21.4, which I will apply to 21.5 with the Hegbloom and Stodghill > > patches. I'll give details later. > > I don't remember this one. Either I removed it from the > list because you said you'll apply or simply I didn't add > it to the list. > > > There's a patch by Zhaoway and a similar (and thus redundant) one by > > Karl Hegbloom for --with-scrollbars=no; I don't think it's in 21.5 yet > > but will check. Karl's I reviewed and rejected since the problem > > already was addressed by Zhaoway. > > This one (Zhaoway's patch) is applied. > > Thanks for your comment. > > -- > Yoshiki Hayashi -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From sperber@informatik.uni-tuebingen.de Fri May 18 02:37:25 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA11072; Fri, 18 May 2001 02:37:24 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7FC7643A; Fri, 18 May 2001 08:37:22 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4I6bKm19437; Fri, 18 May 2001 08:37:20 +0200 (CEST) (envelope-from sperber) To: Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Help test EFS From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 18 May 2001 08:37:20 +0200 Message-ID: Lines: 28 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Steve Youngs has just released EFS package version 1.25. This is an experimental prerelease of EFS available as /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/efs-1.25-pkg.tar.gz In order to turn this into an official package release, I urgently need your help in testing it. I've tested EFS on a number of servers, but I only have access to Unix machines for client testing. So I especially need some reports from Windows users, connecting to both Unix and Windows ftp servers. This is especially as some subtle but possibly crucial aspects of the EFS<->client interactions have changed. I'm slowly working towards a testing suite, but it is not yet done and the urgency of the XEmacs/Cygwin situation has prompted me to try to release earlier. Let me emphasize that, if I cannot get some testing done by the community, the release will be significantly delayed, as we cannot risk putting out a faulty EFS to the general user community, given its current prominent role in the XEmacs package system. I appreciate your help. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From yamaoka@jpl.org Fri May 18 05:35:52 2001 Received: from jpl.org (clients.web-hosting.com [207.228.244.9] (may be forged)) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA18997 for ; Fri, 18 May 2001 05:35:52 -0400 Received: from yamaoka@jpl.org by jpl.org (jpl.org [207.228.245.242]) (8.11.1/8.11.1) id f4I9Zp318814 Fri, 18 May 2001 18:35:51 +0900 (JST) Date: 18 May 2001 18:35:37 +0900 Message-ID: From: Katsumi Yamaoka To: xemacs-beta@xemacs.org Subject: Re: Can't display GIF Anime Organization: Emacsen advocacy group References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) (revision 01) XEmacs/21.4 (patch 3) (Academic Rigor) (sparc-sun-solaris2.6) WEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNmJDKxsoQg==?=) CLIME/1.14.0 (=?ISO-2022-JP?B?GyRCOF40VkYyGyhC?=) APEL/10.3 >>>>> In >>>>> Katsumi Yamaoka wrote: > Oops, > I must apologize that some animated GIFs are displayed but some > are not. You may see them in http://www.asahi.com/. For examples: http://www.asahi.com/ad/clients/americanhome/aha0514tile.gif http://www.asahi.com/ad/clients/goujin/goujin0507.gif http://www.asahi.com/ad/clients/nicos/nicos0507.gif http://www.asahi.com/ad/clients/recruit/recruit0514.gif http://www.asahi.com/ad/clients/tokyo12univ/tokyo0514.gif Netscape, xanim or "gifsicle|xv -" can show the above image files but XEmacs couldn't. However, I am not inconvenienced with them since they are no more than advertisements. :-) -- Katsumi Yamaoka From yoshiki@xemacs.org Fri May 18 06:43:02 2001 Received: from mail.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA21793 for ; Fri, 18 May 2001 06:43:00 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4IAgwZ18062 for ; Fri, 18 May 2001 19:42:58 +0900 Mail-Copies-To: nobody To: xemacs-beta@xemacs.org Subject: [BUG] Too agressive byte code optimizer From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 18 May 2001 19:42:58 +0900 Message-ID: <87zocb7xal.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 19 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) When following form is eval'ed, it signals an error: Wrong type argument: number-char-or-marker-p, a (= 'a) However, if it's byte-compiled, it returns t. (disassemble (byte-compile (lambda () (= 'a)))) shows: byte code: args: nil 0 constant t 1 return Martin? -- Yoshiki Hayashi From warly@mandrakesoft.com Fri May 18 07:29:51 2001 Received: from proca.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA23625 for ; Fri, 18 May 2001 07:29:49 -0400 Received: by proca.mandrakesoft.com (Postfix, from userid 501) id 251031072F; Fri, 18 May 2001 13:29:23 +0200 (CEST) Sender: warly@mandrakesoft.com To: xemacs-beta@xemacs.org Subject: Xemacs 21.4.2 terminal environment variable From: Warly Organization: Mandrakesoft Date: 18 May 2001 13:29:23 +0200 In-Reply-To: <87zocb7xal.fsf@u.sanpo.t.u-tokyo.ac.jp> (Yoshiki Hayashi's message of "18 May 2001 19:42:58 +0900") Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii with 21.4.2, lauching a shell causes: unknown terminal "emacs" unknown terminal "emacs" [warly@proca warly]$ Does 21.4 changed the TERM value ? Does I need to create a emacs terminfo entry ? -- Warly From didier@lrde.epita.fr Fri May 18 07:39:05 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA23985; Fri, 18 May 2001 07:39:04 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id NAA25396 Fri, 18 May 2001 13:36:41 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 150iZ0-00004r-00; Fri, 18 May 2001 13:36:58 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 150iXO-0000sL-00; Fri, 18 May 2001 13:35:18 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (Didier Verna's message of "17 May 2001 17:12:31 +0200") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 18 May 2001 13:35:02 +0200 Message-ID: Lines: 19 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id HAA23985 I wrote: > Steve Youngs wrote: > > > Hey All. > > > > The XEmacs review board has decided that the current directory > > hierarchy of the 'xemacs-packages' CVS module was unnecessarily > > confusing. Also, it seems that XEMACS_PACKAGES and MULE_PACKAGES are not taken into account: `make' does generate autoloads and compile everything. I haven't tried make install yet. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From trebuche@nortelnetworks.com Fri May 18 08:37:16 2001 Received: from qnsgs000.nortel.com (h237s130a211n47.user.nortelnetworks.com [47.211.130.237]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA26021 for ; Fri, 18 May 2001 08:37:11 -0400 Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 18 May 2001 12:54:50 +0100 Received: from zjbac006.net.matranortel.com ([131.129.65.26]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K0PFQXY8; Fri, 18 May 2001 12:54:49 +0100 Received: from europem01.nt.com (wadcs01x.europe.nortel.com [47.217.49.187]) by zjbac006.net.matranortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KXG6PLFQ; Fri, 18 May 2001 13:54:48 +0200 Sender: trebuchet@nortel.com Message-ID: <3B050D56.B4050F80@europem01.nt.com> Date: Fri, 18 May 2001 13:53:58 +0200 From: "Felicien Trebuchet" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: Xemacs 21.4.3 launch error References: Content-Type: multipart/mixed; boundary="------------CE3123A14021DDA69155B641" This is a multi-part message in MIME format. --------------CE3123A14021DDA69155B641 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When starting xemacs from a command shell, I get the following message "exec: No such file or directory", before Xemacs starts up. Here is my build configuration uname -a: SunOS wadcs01x 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-5_10 ./configure '--site-includes=/var/tmp/local/include' '--site-libraries=/var/tmp/local/lib' '--prefix=/var/tmp/XEmacs' '--with-sound=all' '--with-pop' '--error-checking=none' XEmacs 21.4.3 "Academic Rigor" configured for `sparc-sun-solaris2.6'. Compilation / Installation: Source code location: /var/tmp/xemacs-21.4.3 Installation prefix: /var/tmp/XEmacs Additional header files: /var/tmp/local/include Additional libraries: /var/tmp/local/lib Runtime library search path: /var/tmp/local/lib:/usr/dt/lib:/usr/openwin/lib:/home/trebuchet/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3:/home/trebuchet/local/lib Operating system description file: `s/sol2.h' Machine description file: `m/sparc.h' Compiler: gcc Relocating allocator for buffers: yes GNU version of malloc: yes Window System: Compiling in support for the X window system: - X Windows headers location: /usr/dt/include /usr/openwin/include - X Windows libraries location: /usr/dt/lib /usr/openwin/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for NAS (network audio system). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for GNU DBM. Internationalization: Mail: Compiling in support for POP mail retrieval. Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for ToolTalk. Compiling in support for dynamic shared object modules. --------------CE3123A14021DDA69155B641 Content-Type: text/x-vcard; charset=us-ascii; name="trebuche.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Trebuchet, Felicien [GOLF:4808:EXCH] Content-Disposition: attachment; filename="trebuche.vcf" begin:vcard n:TREBUCHET;Félicien x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:trebuche@nortelnetworks.com x-mozilla-cpt:wadcs01x;2 fn:Félicien TREBUCHET end:vcard --------------CE3123A14021DDA69155B641-- From youngs@xemacs.org Fri May 18 08:51:11 2001 Received: from mail003.syd.optusnet.com.au (mail003.syd.optusnet.com.au [203.2.75.251]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA26614 for ; Fri, 18 May 2001 08:51:06 -0400 Received: from slackware.mynet.pc (wdcax13-145.dialup.optusnet.com.au [198.142.220.145]) by mail003.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4ICp1O22606 for ; Fri, 18 May 2001 22:51:01 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4ICniNk028896; Fri, 18 May 2001 22:49:44 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: Date: 18 May 2001 22:49:44 +1000 In-Reply-To: (Didier Verna's message of "18 May 2001 13:35:02 +0200") Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "drv" == Didier Verna writes: drv> Also, it seems that XEMACS_PACKAGES and MULE_PACKAGES are not taken drv> into account: `make' does generate autoloads and compile everything. I haven't drv> tried make install yet. How do you mean? Can you elaborate a bit, please? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From glynn.clements@virgin.net Fri May 18 08:56:05 2001 Received: from mta2-svc.virgin.net (mta2-svc.virgin.net [62.253.164.42]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA26850 for ; Fri, 18 May 2001 08:56:04 -0400 Received: from cerise.nosuchdomain.co.uk ([62.252.68.104]) by mta2-svc.virgin.net (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010518125604.TXNC259.mta2-svc.virgin.net@cerise.nosuchdomain.co.uk>; Fri, 18 May 2001 13:56:04 +0100 Received: (from glynn@localhost) by cerise.nosuchdomain.co.uk (8.9.3/8.9.3) id NAA01804; Fri, 18 May 2001 13:43:05 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15109.6361.475114.446011@cerise.nosuchdomain.co.uk> Date: Fri, 18 May 2001 13:43:05 +0100 To: Warly Cc: xemacs-beta@xemacs.org Subject: Re: Xemacs 21.4.2 terminal environment variable In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Warly wrote: > with 21.4.2, lauching a shell causes: > > unknown terminal "emacs" > unknown terminal "emacs" > [warly@proca warly]$ > > Does 21.4 changed the TERM value ? No; it's always been "emacs". > Does I need to create a emacs terminfo entry ? Only if your curses library ignores $TERMCAP; "shell" should set this to something appropriate. Also, note that the version of XEmacs itself shouldn't have any bearing on this; it is all down to "shell", which is a separate package. -- Glynn Clements From didier@lrde.epita.fr Fri May 18 08:59:05 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA27113; Fri, 18 May 2001 08:59:03 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id OAA03097 Fri, 18 May 2001 14:56:46 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 150joW-0002Yx-00; Fri, 18 May 2001 14:57:04 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 150jnr-000154-00; Fri, 18 May 2001 14:56:23 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (Steve Youngs's message of "18 May 2001 22:49:44 +1000") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 18 May 2001 14:56:22 +0200 Message-ID: Lines: 24 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id IAA27113 Steve Youngs wrote: > How do you mean? Can you elaborate a bit, please? For instance, I don't want to install skk, so my MULE_PACKAGES setting in Local.rules is this: MULE_PACKAGES = \ edict \ egg-its \ leim \ locale \ lookup \ mule-base I would then expect that `make' and `make install' skip the skk directory, but that's not the case. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From lday@cisco.com Fri May 18 09:42:51 2001 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA29419 for ; Fri, 18 May 2001 09:42:50 -0400 Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA03706 for ; Fri, 18 May 2001 09:42:32 -0400 (EDT) Received: from cisco.com (hrn2-dhcp-161-44-86-208.cisco.com [161.44.86.208]) by cia.cisco.com (Mirapoint) with ESMTP id AFK09048 (AUTH lday); Fri, 18 May 2001 09:42:33 -0400 (EDT) Message-ID: <3B052727.75009552@cisco.com> Date: Fri, 18 May 2001 09:44:08 -0400 From: Luuwen Day X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From oberman@ptavv.es.net Fri May 18 10:48:41 2001 Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA00730 for ; Fri, 18 May 2001 10:48:40 -0400 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f4IEmTc06275; Fri, 18 May 2001 07:48:29 -0700 (PDT) Message-Id: <200105181448.f4IEmTc06275@ptavv.es.net> To: "Stephen J. Turnbull" cc: XEmacs Beta List Subject: Re: No gnuserv installed in 21.4.3 In-reply-to: Your message of "Fri, 18 May 2001 12:18:17 +0900." <15108.38009.30437.133236@turnbull.sk.tsukuba.ac.jp> Date: Fri, 18 May 2001 07:48:29 -0700 From: "Kevin Oberman" Bingo! You hit the nail on the head. (Not that it was not obvious that I was barking up the wrong tree.) In the past I have always used GNU make to build and install XEmacs. But, for some reason, I used the make that came with my Tru64 UNIX to do the make. It has no obvious version number, but the RCS strings are all dated between 1994 and 1998, so it's not very new. I tried gmake a few minutes ago and it worked like a champ. So the problem is between the Makefile and the native Tru64 make. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From darrylo@soco.agilent.com Fri May 18 13:34:53 2001 Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA10425; Fri, 18 May 2001 13:34:39 -0400 Received: from msgrel1.and.agilent.com (msgrel1.and.agilent.com [130.30.33.104]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 2F79C193C; Fri, 18 May 2001 11:34:35 -0600 (MDT) Received: from mina.soco.agilent.com (mina.soco.agilent.com [141.121.54.157]) by msgrel1.and.agilent.com (Postfix) with ESMTP id DE2E7EA; Fri, 18 May 2001 13:34:33 -0400 (EDT) Received: from mina.soco.agilent.com (darrylo@localhost [127.0.0.1]) by mina.soco.agilent.com (8.9.3 (PHNE_22672)/8.9.3 SMKit7.1.1_Agilent) with ESMTP id KAA29519; Fri, 18 May 2001 10:34:32 -0700 (PDT) Message-Id: <200105181734.KAA29519@mina.soco.agilent.com> To: Steve Youngs Cc: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. Reply-To: Darryl Okahata In-Reply-To: Your message of "17 May 2001 16:57:52 +1000." Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 May 2001 10:34:30 -0700 From: Darryl Okahata Steve Youngs wrote: > Footnotes: > [1] Approx 60 Mb for the raw tree. At least double that size for > building. Just FYI, It's closer to 70+MB (over 73MB on my system). I just did a checkout of the main CVS trunk (21.5.XX, I assume), and here are some numbers (raw source checkouts): xemacs 28+MB packages 73+MB packages/mule-packages 11+MB packages/xemacs-packages 62+MB -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. From Dr.Volker.Zell@oracle.com Fri May 18 13:47:07 2001 Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA11166; Fri, 18 May 2001 13:47:06 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4IHfuD29743; Fri, 18 May 2001 10:41:56 -0700 (PDT) Received: from vzell.de.oracle.com (shivapppd60.de.oracle.com [140.84.22.251]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4IHkSD11434; Fri, 18 May 2001 10:46:32 -0700 (PDT) X-Mailer: 21.4 (patch 3) "Academic Rigor" XEmacs Lucid (via feedmail 8 I) To: xemacs-beta@xemacs.org, Steve Youngs CC: warner@lothar.com Subject: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems X-Face: I-*}xvwusAv%MlABo'jVNP7TDXf5bb*L[q,r{DnsR1GoL07^Wf)sAu%>!LjXAFlZZN+`OQu }?#du]C)[*%ERKR#+l#sX'EoNbSO~|.x@ogoS5|"-u? Date: 18 May 2001 19:47:08 +0200 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi I think there is a bug in the regular expression in mc-gpg.el which is used in mailcrypt-3.5.5 together with gnupg-1.0.5. This is what Brian Warner gets whith his version of gpg: ;31:warner@zs2-pc4% gpg --list-secret-keys --with-colons --no-greeting ;/home/warner/.gnupg/secring.gpg ;------------------------------- ;sec::1024:17:1FE9CBFDC63B6750:1998-08-04:0:::Brian Warner (temporary GPG key) : ;ssb::1024:20:C68E8DE9F759FBDE:1998-08-04:0::: ;sec::768:17:16BD446D567E33CF:1998-08-04:0:::signature (sample signature key) : ;sec::768:16:D514CB72B37D9AF4:1998-08-04:0:::crypt (crypt) : ;sec::1024:17:4DBDD3258230A3E0:1998-08-04:0:::dummyy : ;ssb::1024:20:549B0E6CBBBB43D1:1998-08-04:0::: And this is his regexp for matching: (key-regexp "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):$" ) I'm using gpg-1.05 compiled under cygwin (passing all tests) with (see subject) and I get: [712]> gpg --list-secret-keys --no-greeting --batch --with-colons /users/vzell/.gnupg/secring.gpg ------------------------------- sec:u:1024:17:0A8F8157EBCFE3E8:2001-05-18::::Dr. Volker Zell (Ciko) ::: ssb::1024:16:2179761C5E488513:2001-05-18::::::: vzell@VZELL /tmp [713]> gpg --list-secret-keys --no-greeting --batch --with-colons "Dr. Volker Zell (Ciko) " sec:u:1024:17:0A8F8157EBCFE3E8:2001-05-18::::Dr. Volker Zell (Ciko) ::scESC: ssb::1024:16:2179761C5E488513:2001-05-18::::::e: As you can see I get two more : at the end of each line. Therefore I have to use the following regexp. But then everything works. At least for me. (key-regexp "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\)[^:]*:[^:]*:[^:]*:$" ) Ciao Volker From Aki.Vehtari@hut.fi Fri May 18 15:08:48 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA17440 for ; Fri, 18 May 2001 15:08:45 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4IJ8h630468 for ; Fri, 18 May 2001 22:08:44 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4IJ8hk12062; Fri, 18 May 2001 22:08:43 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: Re: Question about bug reporting References: <15078.33619.705270.405774@turnbull.sk.tsukuba.ac.jp> From: Aki Vehtari In-Reply-To: <15078.33619.705270.405774@turnbull.sk.tsukuba.ac.jp> Date: 18 May 2001 22:08:43 +0300 Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Aki" == Aki Vehtari writes: Aki> Sending bug report using menu entry "Help - Send Bug Report" Aki> would send bug report to xemacs@xemacs.org (at least in Aki> XEmacs 21.4). "Stephen" == Stephen J Turnbull writes: Stephen> To be honest, you should send them here, to xemacs-beta. Well, are you going to change it? 21.4.3 still sends bug reports to xemacs@xemacs.org... Aki From toy@rtp.ericsson.se Fri May 18 16:10:37 2001 Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA27327 for ; Fri, 18 May 2001 16:10:27 -0400 Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4IKAM814400 for ; Fri, 18 May 2001 15:10:22 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4IKAMP10776 for ; Fri, 18 May 2001 15:10:22 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Fri May 18 15:10:08 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id QAA17105 for ; Fri, 18 May 2001 16:10:17 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id QAA21163; Fri, 18 May 2001 16:10:07 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: XEmacs Developers Subject: 21.5.1 crash on solaris From: Raymond Toy Date: 18 May 2001 16:10:05 -0400 Message-ID: <4nzoca1krm.fsf@rtp.ericsson.se> Lines: 138 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= I was reading a mail message in GNUS that had attachments. I clicked on one expecting to save the application/octet-stream attachment. The file-save dialog box popped up, but never finished drawing. Then xemacs crashed. The C backtrace with a partial lisp backtrace (the rest is in memory somewhere waiting to be flushed out). Ray --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=Installation uname -a: SunOS edgedsp4 5.7 Generic_106541-14 sun4u sparc SUNW,Ultra-30 ../configure '--verbose' '--extra-verbose' '--with-mule' '--with-pop' '--with-sound=noesd' '--package-path=/apps/public/XEmacs/lib' '--prefix=/apps/public/XEmacs/21.5' '--bindir=/apps/public/XEmacs/21.5/bin/solaris2.7' '--with-workshop' '--with-dialogs=motif' '--with-widgets=motif' '--site-includes=/apps/public/solaris2.7/usr/openwin/include /apps/public/solaris2.7/include' '--site-libraries=/apps/public/solaris2.7/usr/openwin/lib /apps/public/solaris2.7/lib' XEmacs 21.5-b1 "anise" configured for `sparc-sun-solaris2.7'. Compilation / Installation: Source code location: /apps/public/XEmacs/src/xemacs-21.5.1 Installation prefix: /apps/public/XEmacs/21.5 Additional header files: /apps/public/solaris2.7/usr/openwin/include /apps/public/solaris2.7/include Additional libraries: /apps/public/solaris2.7/usr/openwin/lib /apps/public/solaris2.7/lib Runtime library search path: /usr/ccs/lib:/apps/gnu/solaris2.7/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2:/apps/public/solaris2.7/usr/openwin/lib:/apps/public/solaris2.7/lib:/usr/dt/lib:/usr/openwin/lib Operating system description file: `s/sol2.h' Machine description file: `m/sparc.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith Relocating allocator for buffers: yes GNU version of malloc: yes Window System: Compiling in support for the X window system: - X Windows headers location: /usr/dt/include /usr/openwin/include - X Windows libraries location: /usr/dt/lib /usr/openwin/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Compiling in support for NAS (network audio system). Databases: Compiling in support for GNU DBM. Compiling in support for LDAP. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using Motif to provide XIM support. Mail: Compiling in support for POP mail retrieval. Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for ToolTalk. Compiling in support for Sun WorkShop. Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable C backtrace: (gdb) bt #0 0xfec18790 in _libc_kill () from /usr/lib/libc.so.1 #1 0x92d0c in fatal_error_signal (sig=3D11) at /apps/public/XEmacs/src/xem= acs-21.5.1/src/emacs.c:535 #2 #3 0x1b739c in pixel_to_glyph_translation (f=3D0x1252200, x_coord=3D164, y= _coord=3D277, col=3D0xffbebc40, row=3D0xffbebc3c, obj_x=3D0xffbebc38, obj_y= =3D0xffbebc34, w=3D0xffbebc30, bufpos=3D0xffbebc2c, closest=3D0xffbebc28, m= odeline_closest=3D0xffbebc24, obj1=3D0xffbebc20, obj2=3D0xffbebc1c) at /app= s/public/XEmacs/src/xemacs-21.5.1/src/redisplay.c:8639 #4 0x134c84 in Fmouse_position (device=3D3311620) at /apps/public/XEmacs/s= rc/xemacs-21.5.1/src/frame.c:1783 #5 0x9d4a8 in Ffuncall (nargs=3D-1, args=3D0xffbebd6c) at /apps/public/XEm= acs/src/xemacs-21.5.1/src/eval.c:3528 #6 0x62c30 in execute_optimized_program (program=3D0x9b0f52 "\211\031@\211= \032=AB\t=C4\n!\ba?=AD\003=C5 *\207\211K", stack_depth=3D0, constants_data= =3D0x748610) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:746 #7 0x6277c in funcall_compiled_function (fun=3D3, nargs=3D1, args=3D0xffbe= bfec) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #8 0x9d688 in Ffuncall (nargs=3D1, args=3D0xffbebfe8) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #9 0x9e358 in run_hook_with_args_in_buffer (buf=3D0x328804, nargs=3D2, arg= s=3D0xffbebfe8, cond=3DRUN_HOOKS_TO_COMPLETION) at /apps/public/XEmacs/src/= xemacs-21.5.1/src/eval.c:4020 #10 0x9e488 in va_run_hook_with_args (hook_var=3D3129344, nargs=3D1) at /ap= ps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:4033 #11 0x206a54 in emacs_Xt_handle_magic_event (emacs_event=3D0xebe100) at /ap= ps/public/XEmacs/src/xemacs-21.5.1/src/event-Xt.c:1910 #12 0xfb944 in execute_internal_event (event=3D15458540) at /apps/public/XE= macs/src/xemacs-21.5.1/src/event-stream.c:514 #13 0xfe4b0 in Fdispatch_event (event=3D15458540) at /apps/public/XEmacs/sr= c/xemacs-21.5.1/src/event-stream.c:4251 #14 0x74a9c in Fcommand_loop_1 () at /apps/public/XEmacs/src/xemacs-21.5.1/= src/cmdloop.c:583 #15 0x74d34 in command_loop_1 (dummy=3D6842496) at /apps/public/XEmacs/src/= xemacs-21.5.1/src/cmdloop.c:494 #16 0x990f8 in condition_case_1 (handlers=3D3080204, bfun=3D0x74ce8 , barg=3D3311620, hfun=3D0x74d94 , harg=3D3311620) at /= apps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:1651 #17 0x74ccc in call_command_loop (catch_errors=3D3080204) at /apps/public/X= Emacs/src/xemacs-21.5.1/src/cmdloop.c:256 #18 0x190858 in Fread_minibuffer_internal (prompt=3D9689140) at /apps/publi= c/XEmacs/src/xemacs-21.5.1/src/minibuf.c:188 #19 0x9d4a8 in Ffuncall (nargs=3D1, args=3D0xffbec56c) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3528 #20 0x62c30 in execute_optimized_program (program=3D0xffbec613 "\207", stac= k_depth=3D1, constants_data=3D0x4eab10) at /apps/public/XEmacs/src/xemacs-2= 1.5.1/src/bytecode.c:746 #21 0x67104 in Fbyte_code (instructions=3D-4274688, constants=3D5155584, st= ack_depth=3D5) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:2405 #22 0x9ccc0 in Feval (form=3D5171972) at /apps/public/XEmacs/src/xemacs-21.= 5.1/src/eval.c:3331 #23 0xa1f98 in internal_catch (tag=3D3414380, func=3D0x9c4b4 , arg= =3D5171972, threw=3D0x0) at /apps/public/XEmacs/src/xemacs-21.5.1/src/eval.= c:1317 #24 0x63bfc in execute_rare_opcode (stack_ptr=3D0xffbec93c, program_ptr=3D0= x9b2161 "=DEa=AB\b=F3=F4=ED\"\202\225", opcode=3DBcatch) at /apps/public/XE= macs/src/xemacs-21.5.1/src/bytecode.c:1252 #25 0x629c4 in execute_optimized_program (program=3D0x9b2161 "=DEa=AB\b=F3= =F4=ED\"\202\225", stack_depth=3D141, constants_data=3D0x4e3410) at /apps/p= ublic/XEmacs/src/xemacs-21.5.1/src/bytecode.c:656 #26 0x6277c in funcall_compiled_function (fun=3D6, nargs=3D7, args=3D0xffbe= cb20) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #27 0x9d688 in Ffuncall (nargs=3D7, args=3D0xffbecb1c) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #28 0x62c30 in execute_optimized_program (program=3D0xeaa75d ",\211\031=AC\= 006=CC=CD!=AA\027\n=AB\021\t\f:=AB\005\f@=AA\002\fk=AB\004\n=AA\004=CE\t!*\= 207/\a\n=A5\200", stack_depth=3D7, constants_data=3D0x4ed010) at /apps/publ= ic/XEmacs/src/xemacs-21.5.1/src/bytecode.c:746 #29 0x6277c in funcall_compiled_function (fun=3D9, nargs=3D7, args=3D0xffbe= cd08) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #30 0x9d688 in Ffuncall (nargs=3D7, args=3D0xffbecd04) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #31 0x62c30 in execute_optimized_program (program=3D0x10bdeda ".\t\207", st= ack_depth=3D7, constants_data=3D0x4eb510) at /apps/public/XEmacs/src/xemacs= -21.5.1/src/bytecode.c:746 #32 0x6277c in funcall_compiled_function (fun=3D9, nargs=3D7, args=3D0xffbe= cef0) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #33 0x9d688 in Ffuncall (nargs=3D7, args=3D0xffbeceec) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #34 0x62c30 in execute_optimized_program (program=3D0xffbecfa3 "\207", stac= k_depth=3D7, constants_data=3D0x4ea610) at /apps/public/XEmacs/src/xemacs-2= 1.5.1/src/bytecode.c:746 #35 0x67104 in Fbyte_code (instructions=3D-4272232, constants=3D5154304, st= ack_depth=3D17) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:2405 #36 0x9ccc0 in Feval (form=3D4945172) at /apps/public/XEmacs/src/xemacs-21.= 5.1/src/eval.c:3331 #37 0x976d0 in Fprogn (args=3D4945544) at /apps/public/XEmacs/src/xemacs-21= .5.1/src/eval.c:775 #38 0x992b4 in run_condition_case_handlers (val=3D19176160, var=3D3311620) = at /apps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:1687 #39 0x99098 in condition_case_1 (handlers=3D3080204, bfun=3D0x9c4b4 = , barg=3D5103096, hfun=3D0x99160 , harg=3D3311= 620) at /apps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:1634 #40 0x9952c in condition_case_3 (bodyform=3D5103096, var=3D3311620, handler= s=3D4945616) at /apps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:1729 #41 0x63c54 in execute_rare_opcode (stack_ptr=3D0xffbed42c, program_ptr=3D0= x902858 "\207=CA=CB=CC\"\210=CD\r\f\013\n\t\b\016\016&\a\207\210\004", opco= de=3DBcondition_case) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode= .c:1271 #42 0x629c4 in execute_optimized_program (program=3D0x902858 "\207=CA=CB=CC= \"\210=CD\r\f\013\n\t\b\016\016&\a\207\210\004", stack_depth=3D143, constan= ts_data=3D0x4edf10) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c= :656 #43 0x6277c in funcall_compiled_function (fun=3D8, nargs=3D7, args=3D0xffbe= d618) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #44 0x9d688 in Ffuncall (nargs=3D7, args=3D0xffbed614) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #45 0x62c30 in execute_optimized_program (program=3D0x9076b4 "\2072\210\004= ", stack_depth=3D7, constants_data=3D0x4ede90) at /apps/public/XEmacs/src/x= emacs-21.5.1/src/bytecode.c:746 #46 0x6277c in funcall_compiled_function (fun=3D8, nargs=3D2, args=3D0xffbe= d800) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #47 0x9d688 in Ffuncall (nargs=3D2, args=3D0xffbed7fc) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #48 0x62c30 in execute_optimized_program (program=3D0x11af1b7 "\025=CE\r!\0= 21=CF\r!=AB\t=D0=D1=D2\r\"!=AD\005=D3\013\r\"+\207\024", stack_depth=3D2, c= onstants_data=3D0x8f8f90) at /apps/public/XEmacs/src/xemacs-21.5.1/src/byte= code.c:746 #49 0x6277c in funcall_compiled_function (fun=3D5, nargs=3D1, args=3D0xffbe= d9d8) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #50 0x9d688 in Ffuncall (nargs=3D1, args=3D0xffbed9d4) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #51 0x62c30 in execute_optimized_program (program=3D0xf1488f ",\202=F0", st= ack_depth=3D1, constants_data=3D0x757010) at /apps/public/XEmacs/src/xemacs= -21.5.1/src/bytecode.c:746 #52 0x6277c in funcall_compiled_function (fun=3D13, nargs=3D2, args=3D0xffb= edbd0) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #53 0x9d688 in Ffuncall (nargs=3D2, args=3D0xffbedbcc) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #54 0x62c30 in execute_optimized_program (program=3D0xf57168 "*)\207=D8", s= tack_depth=3D2, constants_data=3D0x76d410) at /apps/public/XEmacs/src/xemac= s-21.5.1/src/bytecode.c:746 #55 0x6277c in funcall_compiled_function (fun=3D5, nargs=3D1, args=3D0xffbe= dda8) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #56 0x9d688 in Ffuncall (nargs=3D1, args=3D0xffbedda4) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #57 0x62c30 in execute_optimized_program (program=3D0x10bd559 "\210eb\210= =C9y\210`d}\210=D1=C8\013=D2\t@!=AB\004=C9=AA\004\tGS\r\211\035@;=AB\005\r@= =AA\005=C9\r8@)$).\a\fb\210=D3 =C9y\210`|\210=D4\r\013=CF\r!C#\210\fb\210+\= 207", stack_depth=3D1, constants_data=3D0xd48190) at /apps/public/XEmacs/sr= c/xemacs-21.5.1/src/bytecode.c:746 #58 0x6277c in funcall_compiled_function (fun=3D7, nargs=3D1, args=3D0xffbe= df88) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #59 0x9d688 in Ffuncall (nargs=3D1, args=3D0xffbedf84) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #60 0x62c30 in execute_optimized_program (program=3D0x10aeeae "+\207options= o", stack_depth=3D1, constants_data=3D0x73db50) at /apps/public/XEmacs/src/= xemacs-21.5.1/src/bytecode.c:746 #61 0x6277c in funcall_compiled_function (fun=3D3, nargs=3D1, args=3D0xffbe= e154) at /apps/public/XEmacs/src/xemacs-21.5.1/src/bytecode.c:518 #62 0x9d688 in Ffuncall (nargs=3D1, args=3D0xffbee150) at /apps/public/XEma= cs/src/xemacs-21.5.1/src/eval.c:3563 #63 0x6984c in Fcall_interactively (function=3D10857532, record_flag=3D3311= 620, keys=3D3311620) at /apps/public/XEmacs/src/xemacs-21.5.1/src/callint.c= :1008 #64 0x9be58 in Fcommand_execute (cmd=3D10857532, record_flag=3D3311620, key= s=3D3311620) at /apps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:2970 #65 0xfd790 in execute_command_event (command_builder=3D0x6baa00, event=3D1= 6462872) at /apps/public/XEmacs/src/xemacs-21.5.1/src/event-stream.c:3914 #66 0xfe180 in Fdispatch_event (event=3D16462872) at /apps/public/XEmacs/sr= c/xemacs-21.5.1/src/event-stream.c:4198 #67 0x74a9c in Fcommand_loop_1 () at /apps/public/XEmacs/src/xemacs-21.5.1/= src/cmdloop.c:583 #68 0x74d34 in command_loop_1 (dummy=3D6842496) at /apps/public/XEmacs/src/= xemacs-21.5.1/src/cmdloop.c:494 #69 0x990f8 in condition_case_1 (handlers=3D3080204, bfun=3D0x74ce8 , barg=3D3311620, hfun=3D0x74d94 , harg=3D3311620) at /= apps/public/XEmacs/src/xemacs-21.5.1/src/eval.c:1651 #70 0x74ea4 in command_loop_2 (dummy=3D3311620) at /apps/public/XEmacs/src/= xemacs-21.5.1/src/cmdloop.c:256 #71 0xa1f98 in internal_catch (tag=3D3391948, func=3D0x74e58 , arg=3D3311620, threw=3D0x0) at /apps/public/XEmacs/src/xemacs-21.5.1/sr= c/eval.c:1317 #72 0x741b4 in initial_command_loop (load_me=3D3311620) at /apps/public/XEm= acs/src/xemacs-21.5.1/src/cmdloop.c:305 #73 0x94994 in sort_args (argc=3D2538496, argv=3D0xffbee9a4) at /apps/publi= c/XEmacs/src/xemacs-21.5.1/src/emacs.c:2346 Lisp backtrace follows: mouse-position() # bind (ignored) balloon-help-mouse-leave-frame-hook(#) # (condition-case ... . error) # (unwind-protect ...) read-minibuffer-internal("Save MIME part to: ") byte-code("..." [standard-output standard-input prompt recursion-depth mi= nibuffer-depth t read-minibuffer-internal] 2) # (catch exit ...) # bind (mouse-grabbed-buffer current-prefix-arg minibuffer-history-variab= le minibuffer-history-position minibuffer-scroll-window) # (unwind-protect ...) # bind (minibuffer-default _history_ oconfig mconfig frame buffer window = oframe owindow dir default abbrev-table history readp keymap initial-conten= ts prompt) read-from-minibuffer("Save MIME part to: " "~/tmp/gnus-mime/26050_CTMsolu= tionA_corrected.zip" # nil file-nam= e-history nil nil) # bind (minibuffer-completion-table minibuffer-completion-predicate minib= uffer-completion-confirm last-exact-completion insert completer initial-con= tents must-match default dir prompt history) read-file-name-2(file-name-history "Save MIME part to: " "/home/unix/toy/= tmp/gnus-mime/26050_CTMsolutionA_corrected.zip" nil nil nil read-file-name-= internal) # (unwind-protect ...) # bind (user-data dirwin filewin frame butbuf dirbuf filebuf file-p compl= eter initial-contents must-match default dir prompt history) mouse-read-file-name-1(file-name-history "Save MIME part to: " "/home/uni= x/toy/tmp/gnus-mime/26050_CTMsolutionA_corrected.zip" nil nil nil read-file= -name-internal) byte-code("..." [initial-contents must-match default dir prompt history m= ouse-read-file-name-1 completer] 8) # bind (completer initial-contents must-match default dir prompt history) read-file-name-1(file-name-history "Save MIME part to: " "/home/unix/toy/tmp/gnus-mime/26050_CTMsolutionA_corrected.zip" nil nil n= il read-file-name-internal) # bind (history initial-contents must-match default dir prompt) read-file-name("Save MIME part to: " "/home/unix/toy/tmp/gnus-mime/26050_= CTMsolutionA_corrected.zip") # bind (file filename name handle) mm-save-part((#"> ("application/octet-stream" (name . "2= 6050_CTMsolutionA_corrected.zip")) base64 nil ("attachment" (filename . "26= 050_CTMsolutionA_corrected.zip")) nil nil nil)) # (unwind-protect ...) # bind (mm non-viewer cur) # (unwind-protect ...) # (unwind-protect ...) # bind (temp-buffer default-enable-multibyte-characters outbuf method han= dle) mm-display-external((#"> ("application/octet-stream" (na= me . "26050_CTMsolutionA_corrected.zip")) base64 nil ("attachment" (filenam= e . "26050_CTMsolutionA_corrected.zip")) nil nil nil) mailcap-save-binary-f= ile) # bind (method type) # (unwind-protect ...) # bind (no-default handle) mm-display-part((#"> ("application/octet-stream" (name .= "26050_CTMsolutionA_corrected.zip")) base64 nil ("attachment" (filename . = "26050_CTMsolutionA_corrected.zip")) nil nil nil)) # (unwind-protect ...) # bind (win beg) # (unwind-protect ...) # (unwind-protect ...) # bind (window mail-parse-charset mail-parse-ignored-charsets id point bu= ffer-read-only handle) gnus-mm-display-part((#"> ("application/octet-stream" (n= ame . "26050_CTMsolutionA_corrected.zip")) base64 nil ("attachment" (filena= me . "26050_CTMsolutionA_corrected.zip")) nil nil nil)) # bind (fun data pos event) gnus-article-push-button(#) # bind (command-debug-status) call-interactively(gnus-article-push-button) # (condition-case ... . error) --=-=-=-- From baz@barriebremner.com Fri May 18 17:17:19 2001 Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA04661 for ; Fri, 18 May 2001 17:17:18 -0400 Received: from [195.92.198.123] (helo=mail17.svr.pol.co.uk) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 150rcY-0004k3-00 for xemacs-beta@xemacs.org; Fri, 18 May 2001 22:17:14 +0100 Received: from modem-42.belfalas.dialup.pol.co.uk ([62.136.139.42] helo=flux.localdomain) by mail17.svr.pol.co.uk with smtp (Exim 3.13 #0) id 150rcW-0004jy-00 for xemacs-beta@xemacs.org; Fri, 18 May 2001 22:17:13 +0100 Received: (qmail 3419 invoked by uid 500); 18 May 2001 21:17:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15109.37196.439373.191482@flux.localdomain> Date: Fri, 18 May 2001 22:17:00 +0100 From: Barrie Bremner To: xemacs-beta@xemacs.org Subject: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems In-Reply-To: References: X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Uptime: 21 hours 43 minutes >>>>> "Volker" == Volker Zell writes: Volker> Hi I think there is a bug in the regular expression in Volker> mc-gpg.el which is used in mailcrypt-3.5.5 together with Volker> gnupg-1.0.5. I'm seeing the same problems with XEmacs 21.5 beta 1 "anise", mailcrypt-3.5.5, GnuPG 1.0.5, under Linux (Redhat 7.1). I've downgraded to GnuPG 1.0.4 in the mean time. As I've mentioned, I'm not to bright - how do I go about applying/testing Volker's fix? Do I just hack mc-gpg.el and rebuild Mailcrypt? What about code to detect GnuPG <= 1.0.4 and => 1.0.5 - is it possible to detect this and add it to Mailcrypt so as not to break old GnuPG versions with Mailcrypt (even tho everyone should upgrade :-) I think I should start learning Elisp :-) Baz. Volker> This is what Brian Warner gets whith his version of gpg: Volker> ;31:warner@zs2-pc4% gpg --list-secret-keys --with-colons Volker> --no-greeting ;/home/warner/.gnupg/secring.gpg Volker> ;------------------------------- Volker> ;sec::1024:17:1FE9CBFDC63B6750:1998-08-04:0:::Brian Warner Volker> (temporary GPG key) : Volker> ;ssb::1024:20:C68E8DE9F759FBDE:1998-08-04:0::: Volker> ;sec::768:17:16BD446D567E33CF:1998-08-04:0:::signature Volker> (sample signature key) : Volker> ;sec::768:16:D514CB72B37D9AF4:1998-08-04:0:::crypt (crypt) Volker> : Volker> ;sec::1024:17:4DBDD3258230A3E0:1998-08-04:0:::dummyy Volker> : ;ssb::1024:20:549B0E6CBBBB43D1:1998-08-04:0::: Volker> And this is his regexp for matching: Volker> (key-regexp Volker> "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):$" Volker> ) Volker> I'm using gpg-1.05 compiled under cygwin (passing all Volker> tests) with (see subject) and I get: Volker> [712]> gpg --list-secret-keys --no-greeting --batch Volker> --with-colons /users/vzell/.gnupg/secring.gpg Volker> ------------------------------- Volker> sec:u:1024:17:0A8F8157EBCFE3E8:2001-05-18::::Dr. Volker Volker> Zell (Ciko) ::: Volker> ssb::1024:16:2179761C5E488513:2001-05-18::::::: Volker> vzell@VZELL /tmp [713]> gpg --list-secret-keys Volker> --no-greeting --batch --with-colons "Dr. Volker Zell Volker> (Ciko) " Volker> sec:u:1024:17:0A8F8157EBCFE3E8:2001-05-18::::Dr. Volker Volker> Zell (Ciko) ::scESC: Volker> ssb::1024:16:2179761C5E488513:2001-05-18::::::e: Volker> As you can see I get two more : at the end of each Volker> line. Therefore I have to use the following regexp. But Volker> then everything works. At least for me. Volker> (key-regexp Volker> "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\)[^:]*:[^:]*:[^:]*:$" Volker> ) Volker> Ciao Volker -- Barrie J. Bremner OpenPGP public key ID: 5164F553 baz [at] barriebremner.com http://barriebremner.com/ baz /baz/ n. 1. [common] The third metasyntactic variable. 2. interj. A term of mild annoyance. 3. Occasionally appended to foo to produce `foobaz' -- Jargon File v4.3.0, www.tuxedo.org/jargon 4. Me. From Adrian.Aichner@t-online.de Fri May 18 18:30:13 2001 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA08844 for ; Fri, 18 May 2001 18:30:12 -0400 Received: from fwd02.sul.t-online.de by mailout01.sul.t-online.com with smtp id 150slU-0002xf-04; Sat, 19 May 2001 00:30:32 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.12]) by fwd02.sul.t-online.com with esmtp id 150sld-0oQp7oC; Sat, 19 May 2001 00:30:41 +0200 To: XEmacs Beta List Subject: Failure in latest patcher.el X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 38 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net Hi Didier, Ben, All! Here's the backtrace I get in (emacs-version) "XEmacs 21.1 (patch 14) \"Cuyahoga Valley\" [Lucid] (i386-pc-win32) of Sun May 13 2001 on D5DC120J" with patcher-version "2.4" Best regards, Adrian Signaling: (wrong-number-of-arguments # 5) extent-list(nil nil nil nil patcher-diff) (car (extent-list nil nil nil nil (quote patcher-diff))) ) (let ((diff-extent ...) (change-logs-extent ...) (regenerate t)) (save-excursion (when patcher-change-logs ... ...) (when diff-extent ... ...) (goto-char patcher-patch-marker) (message "Generating the diff...") (sit-for 0) (apply ... shell-file-name nil t nil shell-command-switch ...) (message "Generating the diff... done") (sit-for 0) (setq diff-extent ...) (set-extent-properties diff-extent ...) (if ... ... ...))) ) patcher-generate-diff() (save-excursion (insert "\n\n") (setq patcher-change-logs-marker (point-marker)) (insert "\n") (and override (setq command ...)) (setq command (patcher-construct-command command files)) (let (...) (and diff-prologue ...)) (setq patcher-project project patcher-files files patcher-diff-command command patcher-patch-marker (point-marker)) (patcher-generate-diff)) ) (let ((command ...) (directory ...)) (funcall (intern ...) project (concat "[PATCH] " subject)) (patcher-minor-mode t) (cd directory) (let (...) (and mail-prologue ...)) (save-excursion (insert "\n\n") (setq patcher-change-logs-marker ...) (insert "\n") (and override ...) (setq command ...) (let ... ...) (setq patcher-project project patcher-files files patcher-diff-command command patcher-patch-marker ...) (patcher-generate-diff))) ) patcher-mail-1(("xemacs-packages" "c:\\Hacking\\XEmacs\\xemacs-packages" :inheritance ("xemacs-21.2")) "Bug fix for build-with-MS of libs/build/build.el" nil t) (lambda (project subject &optional arg) "Prepare a mail about a patch to apply on a project.\nPROJECT is the name of the project (see the variables `patcher-projects'\nand `patcher-subprojects').\nSUBJECT is the subject of the mail.\n\nWhen called interactively, use a prefix (ARG) to override the value of\nthe diff command to use for this project. If you want to work on a\nsubset of the project (e.g. some files, subdirectories etc), you have two\nalternatives:\n\n- for temporary subprojects, you can use the function\n `patcher-mail-subproject', which lets you specify the list of modified\n files / directories.\n- otherwise, you can also define the subprojects in the variable\n `patcher-subprojects' and continue using this function.\n\nPlease note that you can have multiple occurrences of a Patcher mail at\nthe same time, but not more than one at a time on the same project unless\nyou use `patcher-mail-subproject' and the sections of the project don't\noverlap." (interactive (let* ... ...)) (patcher-mail-1 project subject (patcher-project-option project :files) (and arg ...)))(("xemacs-packages" "c:\\Hacking\\XEmacs\\xemacs-packages" :inheritance ("xemacs-21.2")) "Bug fix for build-with-MS of libs/build/build.el" (4)) call-interactively(patcher-mail) command-execute(patcher-mail t) execute-extended-command((4)) call-interactively(execute-extended-command) -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From rendhalver@users.sourceforge.net Fri May 18 20:16:20 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA13295; Fri, 18 May 2001 20:16:17 -0400 Received: from ulthwe.dyndns.org (p137-tnt1.brs.ihug.com.au [203.173.188.137]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id KAA19239; Sat, 19 May 2001 10:16:13 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p137-tnt1.brs.ihug.com.au [203.173.188.137] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15109.47803.153050.682997@ulthwe.dyndns.org> Date: Sat, 19 May 2001 10:13:47 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 18 In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Steve Youngs writes: > The following packages are now in the 'Pre-Releases' directory: hi steve these all installed on my RH 7.0 Linux box > build-1.02-pkg.tar.gz > ===================== > calc-1.16-pkg.tar.gz > ==================== > edit-utils-1.60-pkg.tar.gz > ========================== > efs-1.25-pkg.tar.gz > =================== > mailcrypt-2.08-pkg.tar.gz > ========================= > xemacs-base-1.54-pkg.tar.gz > =========================== > xemacs-devel-1.35-pkg.tar.gz > ============================ From youngs@xemacs.org Sat May 19 00:12:56 2001 Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [203.2.75.228]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA21623 for ; Sat, 19 May 2001 00:12:50 -0400 Received: from slackware.mynet.pc (wdcax13-145.dialup.optusnet.com.au [198.142.220.145]) by mail004.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4J4Cjh22155 for ; Sat, 19 May 2001 14:12:45 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4J49JbI028833; Sat, 19 May 2001 14:09:19 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: XEmacs Packages new hierarchy in CVS. References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 19 May 2001 14:09:19 +1000 In-Reply-To: (Didier Verna's message of "18 May 2001 14:56:22 +0200") Message-ID: Lines: 33 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "drv" == Didier Verna writes: drv> For instance, I don't want to install skk, so my MULE_PACKAGES setting drv> in Local.rules is this: drv> MULE_PACKAGES = \ drv> edict \ drv> egg-its \ drv> leim \ drv> locale \ drv> lookup \ drv> mule-base drv> I would then expect that `make' and `make install' skip the skk drv> directory, but that's not the case. Oh OK. You still need to prepend the parent directory to each package you want to install: MULE_PACKAGES = mule-packages/edict mule-packages/egg-its Also, the only make target that looks at [XEMACS|MULE]_PACKAGES is 'install'. Please note that I didn't change the build process, I just moved the directories around. There's still plenty of room for improvement. :-) -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Sat May 19 00:22:56 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA21972 for ; Sat, 19 May 2001 00:22:55 -0400 Received: from slackware.mynet.pc (wdcax13-145.dialup.optusnet.com.au [198.142.220.145]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4J4Mpe18674 for ; Sat, 19 May 2001 14:22:52 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4J4CE9p028883; Sat, 19 May 2001 14:12:14 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 18 References: <15109.47803.153050.682997@ulthwe.dyndns.org> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 19 May 2001 14:12:14 +1000 In-Reply-To: <15109.47803.153050.682997@ulthwe.dyndns.org> (Peter Brown's message of "Sat, 19 May 2001 10:13:47 +1000") Message-ID: Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "PB" == Peter Brown writes: PB> Steve Youngs writes: >>The following packages are now in the 'Pre-Releases' directory: PB> hi steve PB> these all installed on my RH 7.0 Linux box Thanks Peter. Are they all running fine too? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Sat May 19 00:22:58 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA21975 for ; Sat, 19 May 2001 00:22:57 -0400 Received: from slackware.mynet.pc (wdcax13-145.dialup.optusnet.com.au [198.142.220.145]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4J4Mne18652 for ; Sat, 19 May 2001 14:22:50 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4J4GYZW028891; Sat, 19 May 2001 14:16:34 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 19 May 2001 14:16:34 +1000 In-Reply-To: ("Dr. Volker Zell"'s message of "18 May 2001 19:47:08 +0200") Message-ID: Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "VZ" == Volker Zell writes: VZ> Hi VZ> I think there is a bug in the regular expression in mc-gpg.el VZ> which is used in mailcrypt-3.5.5 together with gnupg-1.0.5. I've put a new mailcrypt package in the 'Pre-Releases' directory that fixes this. /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/mailcrypt-2.08-pkg.tar.gz -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From paulkrause1@mediaone.net Sat May 19 01:00:32 2001 Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA24204 for ; Sat, 19 May 2001 01:00:32 -0400 Received: from paulkrause (h002078ca16a1.ne.mediaone.net [24.128.196.78]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f4J50I626516; Sat, 19 May 2001 01:00:18 -0400 (EDT) Message-ID: <005601c0e021$8d6939c0$6401a8c0@paulkrause> Reply-To: "Paul Krause" From: "Paul Krause" To: "Darryl Okahata" , "Andy Piper" Cc: References: <200105171543.IAA26198@mina.soco.agilent.com> Subject: Re: Re[2]: Why does isearch do this [Hrvoje :)]? Date: Sat, 19 May 2001 01:07:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Darryl Okahata" > [ I suppose it could also be a cygwin problem (I assume that you're > using cygwin). Is there a correlation with the compiler used (cygwin, > mingw, vc++, etc.)? What's Paul using? ] I'm using Windows Native. I see it on both binary downloads and my own builds. I think it started around the time the shifted-motion keys were introduced. Other than that, my reports are the same as Andy's, that is, I see no problem in fresh emacs, whether not I use vanilla. But it crops up regularly as soon as I start to do a lot of kill-search-yank editing. From steve@turnbull.sk.tsukuba.ac.jp Sat May 19 01:52:37 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA26362 for ; Sat, 19 May 2001 01:52:35 -0400 Received: by localhost id m150zfA-000143C (Debian Smail-3.2.0.111 2000-Feb-17 #2); Sat, 19 May 2001 14:52:28 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15110.2572.851847.831633@turnbull.sk.tsukuba.ac.jp> Date: Sat, 19 May 2001 14:52:12 +0900 To: Aki Vehtari Cc: xemacs-beta@xemacs.org Subject: Re: Question about bug reporting In-Reply-To: References: <15078.33619.705270.405774@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Ave" == Aki Vehtari writes: Ave> Well, are you going to change it? 21.4.3 still sends bug Ave> reports to xemacs@xemacs.org... Unfortunately the relevant code is not in the core, it's in packages. I can't just make the change on my own, it would affect 21.1. too. I've submitted a patch, but it's going to take some discussion by the Review Board before anything happens. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From rendhalver@users.sourceforge.net Sat May 19 02:16:53 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA27005; Sat, 19 May 2001 02:16:49 -0400 Received: from ulthwe.dyndns.org (p95-tnt1.brs.ihug.com.au [203.173.188.95]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id QAA17089; Sat, 19 May 2001 16:15:01 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p95-tnt1.brs.ihug.com.au [203.173.188.95] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15110.3796.22353.693940@ulthwe.dyndns.org> Date: Sat, 19 May 2001 16:12:36 +1000 To: Steve Youngs Cc: XEmacs Beta Subject: Re: Updated Packages in Pre-Releases - May 18 In-Reply-To: References: <15109.47803.153050.682997@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Steve Youngs writes: > |--==> "PB" == Peter Brown writes: > Thanks Peter. :) > Are they all running fine too? havent had a play with them yet doing weekend things :) will have a look soon and let you know -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From ovidiu@cup.hp.com Sat May 19 02:42:42 2001 Received: from hercules.home (adsl-63-200-51-47.dsl.snfc21.pacbell.net [63.200.51.47]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA27808 for ; Sat, 19 May 2001 02:42:41 -0400 Received: (from ovidiu@localhost) by hercules.home (8.9.3/8.9.3) id XAA09801; Fri, 18 May 2001 23:42:39 -0700 Message-Id: <200105190642.XAA09801@hercules.home> X-Mailer: exmh 2.3.1 01/18/2001 with XEmacs 21.1.14 on Linux 2.2.18 From: Ovidiu Predescu To: xemacs-beta@xemacs.org Subject: texinfo mode frustrations X-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ X-Image-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ovidiu.tiff X-Face: ?(@Y~qjBA}~8ZMh5gM4{Q{bE_*:sCJ3@Z?{B*Co=J!#8bb~-z?-0._vJjt~MM59!MjxG%>U 5>MW^2-\7~z04buszR^=m^U|m66>FdR@cFwhb;.A(8*D.QmLkK]z,md0'HiOE\pyeiv_PACR+P:Cm. wq_%l':E:q]g-UCc>r&s@BVo'kFN;(\9PF22Myg5w%nUBWQ6MJJ#qL#w>2oxckP'H:\$9F"mxsz]Dg k{1`fTcP'Y$CgGnc^paTV$dzhVX+;(U$;Eb)P<>G)g) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 May 2001 23:42:39 -0700 Sender: ovidiu@cup.hp.com Hi, I'm getting really frustrated by the way the texinfo mode works, and I was wondering if it's only me that has these problems. Essentially I try to use the texinfo mode to update all the nodes in my document. The basic pattern I follow is to outline the general structure of the document first, and then start working on each individual chapter. Each chapter has its own sections, subsections and so on. At the time of outlining the structure of the document I don't necessarily know all the section names. So I find myself very often in need for introducing a new section in between two others. I'd like to use the texinfo mode to automatically update the node pointers, using the texinfo-every-node-update and texinfo-all-menus-update. However this seems to not work as expected. For example it forgets to add pointers to the top node, and sometimes even to the next or previous node. Even if I explicitly write them, the next time I run the command it will remove them. So what I ended up doing is not use the command altogether, and editing the node pointers manually. Very unproductive! Needless to say, when I run such a document file through makeinfo or texinfo, I get tons of complains about missing node pointers. Anybody else seeing this, or am I doing something stupid here? Regards, -- Ovidiu Predescu http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) From simon@josefsson.org Sat May 19 06:05:21 2001 Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA01646 for ; Sat, 19 May 2001 06:05:20 -0400 Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f4JA5Gq29232 for ; Sat, 19 May 2001 12:05:16 +0200 To: xemacs-beta@xemacs.org Subject: fyi mail-lib status From: Simon Josefsson User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103 Date: 19 May 2001 12:05:23 +0200 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii FYI, status of the mail-lib package visavi syncing it with FSF (which is my goal with it). File: Modifications compared to Emacs: ------------------------------------------------------ highlight-headers.el N/A (not part of Emacs). mail-abbrevs.el N/A (not part of Emacs). rmail-mini.el N/A (not part of Emacs). base64.el None. mailheader.el None. rfc2104.el None. rfc822.el None. starttls.el None. mail-utils.el Small. Weird QP stuff not in our version. XEmacs additions. reporter.el Small. Due to 'rfc822-goto-eoh' missing in XEmacs. browse-url.el [in progress] rmailout.el [in progress] mail-extr.el Medium. smtpmail.el Medium. AUTH/STARTTLS support, MULE changes. sendmail.el Large. pop3.el Heavy modifications. (Rename to xpop3.el?) From alexm@hsys.msk.ru Sat May 19 06:22:11 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA02110 for ; Sat, 19 May 2001 06:22:11 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp131-72.dialup.mtu-net.ru [62.118.131.72]) by mtu.ru (Postfix) with ESMTP id 3A4E97323 for ; Sat, 19 May 2001 14:22:08 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 11756 invoked by uid 1000); 19 May 2001 10:16:43 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: "Kevin Oberman" To: XEmacs Beta List Subject: Re: Problems with 21.4.3 "Academic Rigor" References: <200105172107.f4HL7Lc19966@ptavv.es.net> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 19 May 2001 14:16:43 +0400 In-Reply-To: "Kevin Oberman"'s message of "Thu, 17 May 2001 14:07:21 -0700" Message-ID: <87vgmxr6d0.fsf@tyranny.hsys.msk.ru> Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "KO" == Kevin Oberman writes: KO> I have had several problems with 21.4.3, the first to mention is that I KO> could not do a send-pr. KO> When I invoke M-x send-pr, I get the message: send-pr: the GNATS site KO> xemacs.org does not have a categories list. Same thing with 21.1.10. It does not even try to contact the Internet (I have dial-on-demand connection). KO> Sigh. So I am sending in several problem reports to this list pending KO> the ability to run send-pr. --alexm From pkrause@soundbite.com Sat May 19 11:23:53 2001 Received: from fenway.corp.soundbite.com ([64.55.62.249]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA10848; Sat, 19 May 2001 11:23:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: re: patch for PR1504: scroll crash MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C0E077.B2771D28" Date: Sat, 19 May 2001 11:23:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: re: patch for PR1504: scroll crash Thread-Index: AcDgd7JAM6UBcpgASPWZc+CyR1ajwg== From: "Paul Krause" To: Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E077.B2771D28 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please ignore the patch posted to xemacs-patches, it is incorrect. =20 I appear to be patch challenged for the time being. The computer with a working CVS and the computer where I can reproduce the bug are incommunicado, and I made a cut-and-paste error attempting to prepare the patch. The version I posted probably won't even compile. =20 I have attached the entire contexts of the file to be patched to this message. If someone with a non-bogus development environment would use to prepare a correct patch I would be grateful. =20 Original patch: To: < xemacs-patches@xemacs.org >=20 Subject: patch for PR1504: scroll crash=20 From: "Paul Krause" < paulkrause1@mediaone.net >=20 Date: Sat, 19 May 2001 00:57:55 -0400=20 Cc: < xmeacs-nt@xemacs.org >=20 Message-ID: < 003601c0e020$67f10d40$6401a8c0@paulkrause >=20 =20 ------_=_NextPart_001_01C0E077.B2771D28 Content-Type: application/octet-stream; name="scrollbar-msw.c" Content-Transfer-Encoding: base64 Content-Description: scrollbar-msw.c Content-Disposition: attachment; filename="scrollbar-msw.c" Lyogc2Nyb2xsYmFyIGltcGxlbWVudGF0aW9uIC0tIG1zd2luZG93cyBpbnRlcmZhY2UuDQogICBD b3B5cmlnaHQgKEMpIDE5OTQsIDE5OTUgQm9hcmQgb2YgVHJ1c3RlZXMsIFVuaXZlcnNpdHkgb2Yg SWxsaW5vaXMuDQogICBDb3B5cmlnaHQgKEMpIDE5OTQgQW1kYWhsIENvcnBvcmF0aW9uLg0KICAg Q29weXJpZ2h0IChDKSAxOTk1IFN1biBNaWNyb3N5c3RlbXMsIEluYy4NCiAgIENvcHlyaWdodCAo QykgMTk5NSBEYXJyZWxsIEtpbmRyZWQgPGRraW5kcmVkK0BjbXUuZWR1Pi4NCg0KVGhpcyBmaWxl IGlzIHBhcnQgb2YgWEVtYWNzLg0KDQpYRW1hY3MgaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiBy ZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdA0KdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBH TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkgdGhlDQpGcmVlIFNvZnR3 YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9yIChhdCB5b3VyIG9wdGlvbikgYW55 DQpsYXRlciB2ZXJzaW9uLg0KDQpYRW1hY3MgaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhh dCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0IFdJVEhPVVQNCkFOWSBXQVJSQU5UWTsgd2l0aG91dCBl dmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mIE1FUkNIQU5UQUJJTElUWSBvcg0KRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlDQpmb3IgbW9yZSBkZXRhaWxzLg0KDQpZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5 IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KYWxvbmcgd2l0aCBYRW1hY3M7IHNl ZSB0aGUgZmlsZSBDT1BZSU5HLiAgSWYgbm90LCB3cml0ZSB0bw0KdGhlIEZyZWUgU29mdHdhcmUg Rm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLA0KQm9zdG9uLCBN QSAwMjExMS0xMzA3LCBVU0EuICAqLw0KDQovKiBTeW5jaGVkIHVwIHdpdGg6IE5vdCBpbiBGU0Yu ICovDQoNCiNpbmNsdWRlIDxjb25maWcuaD4NCiNpbmNsdWRlICJsaXNwLmgiDQoNCiNpbmNsdWRl ICJjb25zb2xlLW1zdy5oIg0KI2luY2x1ZGUgImV2ZW50cy5oIg0KI2luY2x1ZGUgImZyYW1lLmgi DQojaW5jbHVkZSAic2Nyb2xsYmFyLW1zdy5oIg0KI2luY2x1ZGUgInNjcm9sbGJhci5oIg0KI2lu Y2x1ZGUgInNwZWNpZmllci5oIg0KI2luY2x1ZGUgIndpbmRvdy5oIg0KDQovKiBXZSB1c2UgYSBz aW1pbGFyIHNvcnQgb2YgdmVydGljYWwgc2Nyb2xsYmFyIGRyYWcgaGFjayBmb3IgbXN3aW5kb3dz DQogKiBzY3JvbGxiYXJzIGFzIGlzIHVzZWQgZm9yIE1vdGlmIG9yIEx1Y2lkIHNjcm9sbGJhcnMg dW5kZXIgWC4NCiAqIFdlIGRvIGNoYXJhY3Rlci1iYXNlZCBpbnN0ZWFkIG9mIGxpbmUtYmFzZWQg c2Nyb2xsaW5nLCB3aGljaCBjYW4gbWVhbiB0aGF0DQogKiB3aXRob3V0IHRoZSBoYWNrIGl0IGlz IGltcG9zc2libGUgdG8gZHJhZyB0byB0aGUgZW5kIG9mIGEgYnVmZmVyLiAqLw0KI2RlZmluZSBW RVJUSUNBTF9TQ1JPTExCQVJfRFJBR19IQUNLDQoNCnN0YXRpYyBpbnQgdmVydGljYWxfZHJhZ19p bl9wcm9ncmVzcyA9IDA7DQoNCnN0YXRpYyB2b2lkDQptc3dpbmRvd3NfY3JlYXRlX3Njcm9sbGJh cl9pbnN0YW5jZSAoc3RydWN0IGZyYW1lICpmLCBpbnQgdmVydGljYWwsDQoJCQkJICAgICBzdHJ1 Y3Qgc2Nyb2xsYmFyX2luc3RhbmNlICpzYikNCnsNCiAgaW50IG9yaWVudGF0aW9uOw0KDQogIHNi LT5zY3JvbGxiYXJfZGF0YSA9IHhuZXdfYW5kX3plcm8gKHN0cnVjdCBtc3dpbmRvd3Nfc2Nyb2xs YmFyX2RhdGEpOw0KDQogIGlmICh2ZXJ0aWNhbCkNCiAgICBvcmllbnRhdGlvbiA9IFNCU19WRVJU Ow0KICBlbHNlDQogICAgb3JpZW50YXRpb24gPSBTQlNfSE9SWjsNCg0KICBTQ1JPTExCQVJfTVNX X0hBTkRMRSAoc2IpID0NCiAgICBDcmVhdGVXaW5kb3dFeCgwLCAiU0NST0xMQkFSIiwgMCwgb3Jp ZW50YXRpb258V1NfQ0hJTEQsDQoJCSBDV19VU0VERUZBVUxULCBDV19VU0VERUZBVUxULA0KCQkg Q1dfVVNFREVGQVVMVCwgQ1dfVVNFREVGQVVMVCwNCgkJIEZSQU1FX01TV0lORE9XU19IQU5ETEUg KGYpLA0KCQkgTlVMTCwgTlVMTCwgTlVMTCk7DQogIFNDUk9MTEJBUl9NU1dfSU5GTyAoc2IpLmNi U2l6ZSA9IHNpemVvZihTQ1JPTExJTkZPKTsNCiAgU0NST0xMQkFSX01TV19JTkZPIChzYikuZk1h c2sgPSBTSUZfQUxMOw0KICBHZXRTY3JvbGxJbmZvKFNDUk9MTEJBUl9NU1dfSEFORExFIChzYiks IFNCX0NUTCwNCgkJJlNDUk9MTEJBUl9NU1dfSU5GTyAoc2IpKTsNCiAgU2V0V2luZG93TG9uZyAo U0NST0xMQkFSX01TV19IQU5ETEUoc2IpLCBHV0xfVVNFUkRBVEEsIChMT05HKXNiKTsNCg0KI2lm IDANCiAgew0KCSAgSFdORCBoID0gU0NST0xMQkFSX01TV19IQU5ETEUgKHNiKTsNCgkgIGludCB4 ID0gU2V0V2luZG93TG9uZyAoU0NST0xMQkFSX01TV19IQU5ETEUoc2IpLCBHV0xfVVNFUkRBVEEs IChMT05HKXNiKTsNCgkgIGludCB5ID0gR2V0TGFzdEVycm9yKCk7DQoJICBzdHJ1Y3Qgc2Nyb2xs YmFyX2luc3RhbmNlICp6ID0gKHN0cnVjdCBzY3JvbGxiYXJfaW5zdGFuY2UgKilHZXRXaW5kb3dM b25nIChTQ1JPTExCQVJfTVNXX0hBTkRMRShzYiksDQoJCSAgR1dMX1VTRVJEQVRBKTsNCgkgICp6 ID0gKno7DQogIH0NCiNlbmRpZg0KfQ0KDQpzdGF0aWMgdm9pZA0KbXN3aW5kb3dzX2ZyZWVfc2Ny b2xsYmFyX2luc3RhbmNlIChzdHJ1Y3Qgc2Nyb2xsYmFyX2luc3RhbmNlICpzYikNCnsNCiAgRGVz dHJveVdpbmRvdyAoU0NST0xMQkFSX01TV19IQU5ETEUgKHNiKSk7DQogIGlmIChzYi0+c2Nyb2xs YmFyX2RhdGEpDQogICAgeGZyZWUgKHNiLT5zY3JvbGxiYXJfZGF0YSk7DQp9DQoNCnN0YXRpYyB2 b2lkDQptc3dpbmRvd3NfcmVsZWFzZV9zY3JvbGxiYXJfaW5zdGFuY2UgKHN0cnVjdCBzY3JvbGxi YXJfaW5zdGFuY2UgKnNiKQ0Kew0KICBTaG93U2Nyb2xsQmFyIChTQ1JPTExCQVJfTVNXX0hBTkRM RSAoc2IpLCBTQl9DVEwsIDApOw0KICBTQ1JPTExCQVJfTVNXX1NJWkUgKHNiKSA9IDA7DQp9DQoN CiNkZWZpbmUgVVBEQVRFX1BPU19GSUVMRChmaWVsZCkJCQkJCQkgICBcDQogIGlmIChuZXdfIyNm aWVsZCA+PSAwICYmIFNDUk9MTEJBUl9NU1dfREFUQSAoc2IpLT5maWVsZCAhPSBuZXdfIyNmaWVs ZCkgeyBcDQogICAgU0NST0xMQkFSX01TV19EQVRBIChzYiktPmZpZWxkID0gbmV3XyMjZmllbGQ7 CQkJICAgXA0KICAgIHBvc19jaGFuZ2VkID0gMTsJCQkJCQkJICAgXA0KICB9DQoNCnN0YXRpYyB2 b2lkDQptc3dpbmRvd3NfdXBkYXRlX3Njcm9sbGJhcl9pbnN0YW5jZV92YWx1ZXMgKHN0cnVjdCB3 aW5kb3cgKncsDQoJCQkJCSAgICBzdHJ1Y3Qgc2Nyb2xsYmFyX2luc3RhbmNlICpzYiwNCgkJCQkJ ICAgIGludCBuZXdfbGluZV9pbmNyZW1lbnQsDQoJCQkJCSAgICBpbnQgbmV3X3BhZ2VfaW5jcmVt ZW50LA0KCQkJCQkgICAgaW50IG5ld19taW5pbXVtLCBpbnQgbmV3X21heGltdW0sDQoJCQkJCSAg ICBpbnQgbmV3X3NsaWRlcl9zaXplLA0KCQkJCQkgICAgaW50IG5ld19zbGlkZXJfcG9zaXRpb24s DQoJCQkJCSAgICBpbnQgbmV3X3Njcm9sbGJhcl93aWR0aCwNCgkJCQkJICAgIGludCBuZXdfc2Ny b2xsYmFyX2hlaWdodCwNCgkJCQkJICAgIGludCBuZXdfc2Nyb2xsYmFyX3gsDQoJCQkJCSAgICBp bnQgbmV3X3Njcm9sbGJhcl95KQ0Kew0KICBpbnQgcG9zX2NoYW5nZWQgPSAwOw0KICBsb25nIHN0 eWxlcyA9IEdldFdpbmRvd0xvbmcgKFNDUk9MTEJBUl9NU1dfSEFORExFIChzYiksIEdXTF9TVFlM RSk7DQogIGludCB2ZXJ0ID0gc3R5bGVzICYgU0JTX1ZFUlQ7DQoNCiAgaWYgKHN0eWxlcyA9PSAw KSB7DQogICAgbXN3aW5kb3dzX291dHB1dF9sYXN0X2Vycm9yKCJHZXRXaW5kb3dMb25nIik7DQog ICAgcmV0dXJuOw0KICB9DQoNCiNpZiAwDQogIHN0ZGVycl9vdXQgKCJbJWQsICVkXSwgcGFnZSA9 ICVkLCBwb3MgPSAlZCwgaW5oaWJpdCA9ICVkXG4iLCBuZXdfbWluaW11bSwgbmV3X21heGltdW0s DQoJICAgICAgbmV3X3NsaWRlcl9zaXplLCBuZXdfc2xpZGVyX3Bvc2l0aW9uLGluaGliaXRfc2xp ZGVyX3NpemVfY2hhbmdlKTsNCiNlbmRpZg0KDQogIC8qIFRoZXNlIG1pZ2h0IGJlIG9wdGltaXpl ZCwgYnV0IHNpbmNlIGF0IGxlYXN0IG9uZSB3aWxsIGNoYW5nZSBhdCBlYWNoDQogICAgIGNhbGws IGl0J3MgcHJvYmFibHkgbm90IHdvcnRoIGl0LiAqLw0KICBTQ1JPTExCQVJfTVNXX0lORk8gKHNi KS5uTWluID0gbmV3X21pbmltdW07DQogIFNDUk9MTEJBUl9NU1dfSU5GTyAoc2IpLm5NYXggPSBu ZXdfbWF4aW11bTsNCiAgU0NST0xMQkFSX01TV19JTkZPIChzYikublBhZ2UgPSBuZXdfc2xpZGVy X3NpemUgKyAxOyAvKiArMSBmb3IgRElTQUJMRU5PU0NST0xMICovDQogIFNDUk9MTEJBUl9NU1df SU5GTyAoc2IpLm5Qb3MgPSBuZXdfc2xpZGVyX3Bvc2l0aW9uOw0KI2lmbmRlZiBWRVJUSUNBTF9T Q1JPTExCQVJfRFJBR19IQUNLDQogIFNDUk9MTEJBUl9NU1dfSU5GTyAoc2IpLmZNYXNrID0gKCh2 ZXJ0ICYmIHZlcnRpY2FsX2RyYWdfaW5fcHJvZ3Jlc3MpDQoJCQkJICAgPyBTSUZfUkFOR0UgfCBT SUZfUE9TDQoJCQkJICAgOiBTSUZfQUxMIHwgU0lGX0RJU0FCTEVOT1NDUk9MTCk7DQojZWxzZQ0K ICBTQ1JPTExCQVJfTVNXX0lORk8gKHNiKS5mTWFzayA9IFNJRl9BTEwgfCBTSUZfRElTQUJMRU5P U0NST0xMOw0KDQogIC8qIElnbm9yZSBYRW1hY3MnIHJlcXVlc3RzIHRvIHVwZGF0ZSB0aGUgdGh1 bWIgcG9zaXRpb24gYW5kIHNpemU7IHRoZXkgZG9uJ3QNCiAgICogYmVhciBhbnkgcmVsYXRpb24g dG8gcmVhbGl0eSBiZWNhdXNlIHdlJ3JlIHJlcG9ydGluZyBtYWRlLXVwIHBvc2l0aW9ucyAqLw0K ICBpZiAoISh2ZXJ0ICYmIHZlcnRpY2FsX2RyYWdfaW5fcHJvZ3Jlc3MpKQ0KI2VuZGlmDQogICAg U2V0U2Nyb2xsSW5mbyAoU0NST0xMQkFSX01TV19IQU5ETEUgKHNiKSwgU0JfQ1RMLCAmU0NST0xM QkFSX01TV19JTkZPIChzYiksDQoJCSAgIFRSVUUpOw0KDQogIFVQREFURV9QT1NfRklFTEQgKHNj cm9sbGJhcl94KTsNCiAgVVBEQVRFX1BPU19GSUVMRCAoc2Nyb2xsYmFyX3kpOw0KICBVUERBVEVf UE9TX0ZJRUxEIChzY3JvbGxiYXJfd2lkdGgpOw0KICBVUERBVEVfUE9TX0ZJRUxEIChzY3JvbGxi YXJfaGVpZ2h0KTsNCg0KICBpZiAocG9zX2NoYW5nZWQpDQogICAgew0KICAgICAgTW92ZVdpbmRv dyhTQ1JPTExCQVJfTVNXX0hBTkRMRSAoc2IpLA0KCQkgbmV3X3Njcm9sbGJhcl94LCBuZXdfc2Ny b2xsYmFyX3ksDQoJCSBuZXdfc2Nyb2xsYmFyX3dpZHRoLCBuZXdfc2Nyb2xsYmFyX2hlaWdodCwN CgkJIFRSVUUpOw0KICAgIH0NCn0NCg0Kc3RhdGljIHZvaWQNCm1zd2luZG93c191cGRhdGVfc2Ny b2xsYmFyX2luc3RhbmNlX3N0YXR1cyAoc3RydWN0IHdpbmRvdyAqdywNCgkJCQkJICAgIGludCBh Y3RpdmUsIGludCBzaXplLA0KCQkJCQkgICAgc3RydWN0IHNjcm9sbGJhcl9pbnN0YW5jZSAqc2Ip DQp7DQogIGlmIChTQ1JPTExCQVJfTVNXX1NJWkUgKHNiKSAhPSBzaXplKQ0KICAgIHsNCiAgICAg IFNDUk9MTEJBUl9NU1dfU0laRSAoc2IpID0gc2l6ZTsNCiAgICAgIFNob3dTY3JvbGxCYXIgKFND Uk9MTEJBUl9NU1dfSEFORExFIChzYiksIFNCX0NUTCwNCgkJICAgICBTQ1JPTExCQVJfTVNXX1NJ WkUgKHNiKSk7DQogICAgICBTQ1JPTExCQVJfTVNXX0lORk8oc2IpLmZNYXNrIHw9IFNJRl9ESVNB QkxFTk9TQ1JPTEw7DQogICAgICBTZXRTY3JvbGxJbmZvKFNDUk9MTEJBUl9NU1dfSEFORExFIChz YiksIFNCX0NUTCwgJlNDUk9MTEJBUl9NU1dfSU5GTyAoc2IpLCBUUlVFKTsNCiAgICB9DQp9DQoN CnZvaWQNCm1zd2luZG93c19oYW5kbGVfc2Nyb2xsYmFyX2V2ZW50IChIV05EIGh3bmQsIGludCBj b2RlLCBpbnQgcG9zKQ0Kew0KICBzdHJ1Y3QgZnJhbWUgKmY7DQogIExpc3BfT2JqZWN0IHdpbiwg ZnJhbWU7DQogIHN0cnVjdCBzY3JvbGxiYXJfaW5zdGFuY2UgKnNiOw0KICBsb25nIHN0eWxlcyA9 IEdldFdpbmRvd0xvbmcgKGh3bmQsIEdXTF9TVFlMRSk7DQogIGludCB2ZXJ0ID0gc3R5bGVzICYg U0JTX1ZFUlQ7DQoNCiAgaWYgKHN0eWxlcyA9PSAwKSB7DQogICAgbXN3aW5kb3dzX291dHB1dF9s YXN0X2Vycm9yKCJHZXRXaW5kb3dMb25nIik7DQogICAgcmV0dXJuOw0KICB9DQoNCiAgc2IgPSAo c3RydWN0IHNjcm9sbGJhcl9pbnN0YW5jZSAqKUdldFdpbmRvd0xvbmcgKGh3bmQsIEdXTF9VU0VS REFUQSk7DQogIGlmIChzYiAhPSBOVUxMKSB7DQogICB3aW4gPSByZWFsX3dpbmRvdyAoc2ItPm1p cnJvciwgMSk7DQogICBmcmFtZSA9IFhXSU5ET1cgKHdpbiktPmZyYW1lOw0KICAgZiA9IFhGUkFN RSAoZnJhbWUpOw0KICB9DQogIC8qIFNCX0xJTkVET1dOID09IFNCX0NIQVJMRUZUIGV0Yy4gVGhp cyBpcyB0aGUgd2F5IHRoZXkgd2lsbA0KICAgICBhbHdheXMgYmUgLSBhbnkgV2luZG93cyBpcyBi aW5hcnkgY29tcGF0aWJsZSBiYWNrd2FyZCB3aXRoDQogICAgIG9sZCBwcm9ncmFtcyAqLw0KDQog IHN3aXRjaCAoY29kZSkNCiAgICB7DQogICAgY2FzZSBTQl9MSU5FRE9XTjoNCiAgICAgIG1zd2lu ZG93c19lbnF1ZXVlX21pc2NfdXNlcl9ldmVudA0KCShmcmFtZSwgdmVydCA/IFFzY3JvbGxiYXJf bGluZV9kb3duIDogUXNjcm9sbGJhcl9jaGFyX3JpZ2h0LCB3aW4pOw0KICAgICAgYnJlYWs7DQoN CiAgICBjYXNlIFNCX0xJTkVVUDoNCiAgICAgIG1zd2luZG93c19lbnF1ZXVlX21pc2NfdXNlcl9l dmVudA0KCShmcmFtZSwgdmVydCA/IFFzY3JvbGxiYXJfbGluZV91cCA6IFFzY3JvbGxiYXJfY2hh cl9sZWZ0LCB3aW4pOw0KICAgICAgYnJlYWs7DQoNCiAgICBjYXNlIFNCX1BBR0VET1dOOg0KICAg ICAgbXN3aW5kb3dzX2VucXVldWVfbWlzY191c2VyX2V2ZW50DQoJKHdpbiwgdmVydCA/IFFzY3Jv bGxiYXJfcGFnZV9kb3duIDogUXNjcm9sbGJhcl9wYWdlX3JpZ2h0LA0KCSB2ZXJ0ID8gRmNvbnMg KHdpbiwgUW5pbCkgOiB3aW4pOw0KICAgICAgYnJlYWs7DQoNCiAgICBjYXNlIFNCX1BBR0VVUDoN CiAgICAgIG1zd2luZG93c19lbnF1ZXVlX21pc2NfdXNlcl9ldmVudA0KCShmcmFtZSwNCgkgdmVy dCA/IFFzY3JvbGxiYXJfcGFnZV91cCA6IFFzY3JvbGxiYXJfcGFnZV9sZWZ0LA0KCSB2ZXJ0ID8g RmNvbnMgKHdpbiwgUW5pbCkgOiB3aW4pOw0KICAgICAgYnJlYWs7DQoNCiAgICBjYXNlIFNCX0JP VFRPTToNCiAgICAgIG1zd2luZG93c19lbnF1ZXVlX21pc2NfdXNlcl9ldmVudA0KCShmcmFtZSwg dmVydCA/IFFzY3JvbGxiYXJfdG9fYm90dG9tIDogUXNjcm9sbGJhcl90b19yaWdodCwgd2luKTsN CiAgICAgIGJyZWFrOw0KDQogICAgY2FzZSBTQl9UT1A6DQogICAgICBtc3dpbmRvd3NfZW5xdWV1 ZV9taXNjX3VzZXJfZXZlbnQNCgkoZnJhbWUsIHZlcnQgPyBRc2Nyb2xsYmFyX3RvX3RvcCA6IFFz Y3JvbGxiYXJfdG9fbGVmdCwgd2luKTsNCiAgICAgIGJyZWFrOw0KDQogICAgY2FzZSBTQl9USFVN QlRSQUNLOg0KICAgIGNhc2UgU0JfVEhVTUJQT1NJVElPTjoNCiAgICAgIHsNCglpbnQgcG9zOw0K CVNDUk9MTElORk8gc2Nyb2xsaW5mbzsNCglzY3JvbGxpbmZvLmNiU2l6ZSA9IHNpemVvZihTQ1JP TExJTkZPKTsNCglzY3JvbGxpbmZvLmZNYXNrID0gU0lGX0FMTDsNCglHZXRTY3JvbGxJbmZvICho d25kLCBTQl9DVEwsICZzY3JvbGxpbmZvKTsNCgl2ZXJ0aWNhbF9kcmFnX2luX3Byb2dyZXNzID0g dmVydDsNCiNpZmRlZiBWRVJUSUNBTF9TQ1JPTExCQVJfRFJBR19IQUNLDQoJaWYgKHZlcnQgJiYg KHNjcm9sbGluZm8ublRyYWNrUG9zID4gc2Nyb2xsaW5mby5uUG9zKSkNCgkgIC8qIG5ldyBidWZm ZXIgcG9zaXRpb24gPQ0KCSAgICogIGJ1ZmZlciBwb3NpdGlvbiBhdCBzdGFydCBvZiBkcmFnICsN CgkgICAqICAgKCh0ZXh0IHJlbWFpbmluZyBpbiBidWZmZXIgYXQgc3RhcnQgb2YgZHJhZykgKg0K CSAgICogICAgKGFtb3VudCB0aGF0IHRoZSB0aHVtYiBoYXMgYmVlbiBtb3ZlZCkgLw0KCSAgICog ICAgKHNwYWNlIHRoYXQgcmVtYWluZWQgcGFzdCBlbmQgb2YgdGhlIHRodW1iIGF0IHN0YXJ0IG9m IGRyYWcpKSAqLw0KCSAgcG9zID0gKGludCkNCgkgICAgKHNjcm9sbGluZm8ublBvcw0KCSAgICAg KyAoKChkb3VibGUpDQoJCSAoc2Nyb2xsaW5mby5uTWF4IC0gc2Nyb2xsaW5mby5uUG9zKQ0KCQkg KiAoc2Nyb2xsaW5mby5uVHJhY2tQb3MgLSBzY3JvbGxpbmZvLm5Qb3MpKQ0KCQkvIChzY3JvbGxp bmZvLm5NYXggLSBzY3JvbGxpbmZvLm5QYWdlIC0gc2Nyb2xsaW5mby5uUG9zKSkpDQoJICAgIC0g MjsJLyogZW5zdXJlIHRoYXQgdGhlIGxhc3QgbGluZSBkb2Vzbid0IGRpc2FwcGVhciBvZmYgc2Ny ZWVuICovDQoJZWxzZQ0KI2VuZGlmDQoJICBwb3MgPSBzY3JvbGxpbmZvLm5UcmFja1BvczsNCglt c3dpbmRvd3NfZW5xdWV1ZV9taXNjX3VzZXJfZXZlbnQNCgkgIChmcmFtZSwNCgkgICB2ZXJ0ID8g UXNjcm9sbGJhcl92ZXJ0aWNhbF9kcmFnIDogUXNjcm9sbGJhcl9ob3Jpem9udGFsX2RyYWcsDQoJ ICAgRmNvbnMgKHdpbiwgbWFrZV9pbnQgKHBvcykpKTsNCiAgICAgIH0NCiAgICAgIGJyZWFrOw0K DQogICAgY2FzZSBTQl9FTkRTQ1JPTEw6DQojaWZkZWYgVkVSVElDQUxfU0NST0xMQkFSX0RSQUdf SEFDSw0KICAgICAgaWYgKHZlcnRpY2FsX2RyYWdfaW5fcHJvZ3Jlc3MgJiYgc2IpDQoJLyogVXNl ciBoYXMganVzdCBkcm9wcGVkIHRoZSB0aHVtYiAtIGZpbmFsbHkgdXBkYXRlIGl0ICovDQoJU2V0 U2Nyb2xsSW5mbyAoU0NST0xMQkFSX01TV19IQU5ETEUgKHNiKSwgU0JfQ1RMLA0KCQkgICAgICAg JlNDUk9MTEJBUl9NU1dfSU5GTyAoc2IpLCBUUlVFKTsNCiNlbmRpZg0KICAgICAgdmVydGljYWxf ZHJhZ19pbl9wcm9ncmVzcyA9IDA7DQogICAgICBicmVhazsNCiAgICB9DQp9DQoNCnN0YXRpYyBp bnQNCmNhbl9zY3JvbGwgKHN0cnVjdCBzY3JvbGxiYXJfaW5zdGFuY2UqIHNjcm9sbGJhcikNCnsN CiAgcmV0dXJuIHNjcm9sbGJhciAhPSBOVUxMDQoJJiYgSXNXaW5kb3dWaXNpYmxlIChTQ1JPTExC QVJfTVNXX0hBTkRMRSAoc2Nyb2xsYmFyKSkNCgkmJiBJc1dpbmRvd0VuYWJsZWQgKFNDUk9MTEJB Ul9NU1dfSEFORExFIChzY3JvbGxiYXIpKTsNCn0NCg0KaW50DQptc3dpbmRvd3NfaGFuZGxlX21v dXNld2hlZWxfZXZlbnQgKExpc3BfT2JqZWN0IGZyYW1lLCBpbnQga2V5cywgaW50IGRlbHRhLA0K CQkJCSAgIFBPSU5UUyB3aGVyZSkNCnsNCiAgaW50IGhhc1ZlcnRCYXIsIGhhc0hvcnpCYXI7CS8q IEluZGljYXRlcyBwcmVzZW5jZSBvZiBzY3JvbGwgYmFycyAqLw0KICB1bnNpZ25lZCB3aGVlbFNj cm9sbExpbmVzID0gMDsgLyogTnVtYmVyIG9mIGxpbmVzIHBlciB3aGVlbCBub3RjaCAqLw0KICBM aXNwX09iamVjdCB3aW47DQogIHN0cnVjdCB3aW5kb3dfbWlycm9yICptaXJyb3I7DQogIFBPSU5U IGRvbmRlX2VzdGE7DQoNCiAgZG9uZGVfZXN0YS54ID0gd2hlcmUueDsNCiAgZG9uZGVfZXN0YS55 ID0gd2hlcmUueTsNCg0KICBTY3JlZW5Ub0NsaWVudCAoRlJBTUVfTVNXSU5ET1dTX0hBTkRMRSAo WEZSQU1FIChmcmFtZSkpLCAmZG9uZGVfZXN0YSk7DQoNCiAgLyogRmluZCB0aGUgd2luZG93IHRv IHNjcm9sbCAqLw0KICB7DQogICAgaW50IG1lbmUsIF9tZW5lLCB0ZWtlbCwgdXBoYXJzaW47DQog ICAgQnVmcG9zIG1lbnMsIHNhbmE7DQogICAgQ2hhcmNvdW50IGluOw0KICAgIExpc3BfT2JqZWN0 IGNvcnBvcmUsIHNhbm87DQogICAgc3RydWN0IHdpbmRvdyAqbmVlZGxlX2luX2hheXN0YWNrOw0K DQogICAgcGl4ZWxfdG9fZ2x5cGhfdHJhbnNsYXRpb24gKFhGUkFNRSAoZnJhbWUpLCBkb25kZV9l c3RhLngsIGRvbmRlX2VzdGEueSwNCgkJCQkmbWVuZSwgJl9tZW5lLCAmdGVrZWwsICZ1cGhhcnNp biwNCgkJCQkmbmVlZGxlX2luX2hheXN0YWNrLA0KCQkJCSZtZW5zLCAmc2FuYSwgJmluLCAmY29y cG9yZSwgJnNhbm8pOw0KDQogICAgaWYgKG5lZWRsZV9pbl9oYXlzdGFjaykNCiAgICAgIHsNCglY U0VUV0lORE9XICh3aW4sIG5lZWRsZV9pbl9oYXlzdGFjayk7DQogICAgICB9DQogICAgZWxzZQ0K ICAgICAgew0KCXdpbiA9IEZSQU1FX1NFTEVDVEVEX1dJTkRPVyAoWEZSQU1FIChmcmFtZSkpOw0K CW5lZWRsZV9pbl9oYXlzdGFjayA9IFhXSU5ET1cgKHdpbik7DQogICAgICB9DQoNCiAgICBtaXJy b3IgPSBmaW5kX3dpbmRvd19taXJyb3IgKG5lZWRsZV9pbl9oYXlzdGFjayk7DQogIH0NCg0KICAv KiBDaGVjayB0aGF0IHRoZXJlIGlzIHNvbWV0aGluZyB0byBzY3JvbGwgKi8NCiAgaGFzVmVydEJh ciA9IGNhbl9zY3JvbGwgKG1pcnJvci0+c2Nyb2xsYmFyX3ZlcnRpY2FsX2luc3RhbmNlKTsNCiAg aGFzSG9yekJhciA9IGNhbl9zY3JvbGwgKG1pcnJvci0+c2Nyb2xsYmFyX2hvcml6b250YWxfaW5z dGFuY2UpOw0KICBpZiAoIWhhc1ZlcnRCYXIgJiYgIWhhc0hvcnpCYXIpDQogICAgcmV0dXJuIEZB TFNFOw0KDQogIC8qIE5vIHN1cHBvcnQgZm9yIHBhbm5pbmcgYW5kIHpvb21pbmcsIHNvIGlnbm9y ZSAqLw0KICBpZiAoa2V5cyAmIChNS19TSElGVCB8IE1LX0NPTlRST0wpKQ0KICAgIHJldHVybiBG QUxTRTsNCg0KICAvKiBHZXQgdGhlIG51bWJlciBvZiBsaW5lcyBwZXIgd2hlZWwgZGVsdGEgKi8N CiAgU3lzdGVtUGFyYW1ldGVyc0luZm8gKFNQSV9HRVRXSEVFTFNDUk9MTExJTkVTLCAwLCAmd2hl ZWxTY3JvbGxMaW5lcywgMCk7DQoNCiAgLyogQ2FsY3VsYXRlIHRoZSBhbW91bnQgdG8gc2Nyb2xs ICovDQogIGlmICh3aGVlbFNjcm9sbExpbmVzID09IFdIRUVMX1BBR0VTQ1JPTEwpDQogICAgew0K ICAgICAgLyogU2Nyb2xsIGJ5IGEgcGFnZSAqLw0KICAgICAgTGlzcF9PYmplY3QgZnVuY3Rpb247 DQogICAgICBpZiAoaGFzVmVydEJhcikNCglmdW5jdGlvbiA9IGRlbHRhID4gMCA/IFFzY3JvbGxi YXJfcGFnZV91cCA6IFFzY3JvbGxiYXJfcGFnZV9kb3duOw0KICAgICAgZWxzZQ0KCWZ1bmN0aW9u ID0gZGVsdGEgPiAwID8gUXNjcm9sbGJhcl9wYWdlX2xlZnQgOiBRc2Nyb2xsYmFyX3BhZ2Vfcmln aHQ7DQogICAgICBtc3dpbmRvd3NfZW5xdWV1ZV9taXNjX3VzZXJfZXZlbnQgKGZyYW1lLCBmdW5j dGlvbiwgRmNvbnMgKHdpbiwgUW5pbCkpOw0KICAgIH0NCiAgZWxzZSAvKiBTY3JvbGwgYnkgYSBu dW1iZXIgb2YgbGluZXMgKi8NCiAgICB7DQogICAgICAvKiBDYWxjIHRoZSBudW1iZXIgb2YgbGlu ZXMgdG8gc2Nyb2xsICovDQogICAgICBpbnQgdG9TY3JvbGwgPSBNdWxEaXYgKGRlbHRhLCB3aGVl bFNjcm9sbExpbmVzLCBXSEVFTF9ERUxUQSk7DQoNCiAgICAgIC8qIERvIHRoZSBzY3JvbGwgKi8N CiAgICAgIExpc3BfT2JqZWN0IGZ1bmN0aW9uOw0KICAgICAgaWYgKGhhc1ZlcnRCYXIpDQoJZnVu Y3Rpb24gPSBkZWx0YSA+IDAgPyBRc2Nyb2xsYmFyX2xpbmVfdXAgOiBRc2Nyb2xsYmFyX2xpbmVf ZG93bjsNCiAgICAgIGVsc2UNCglmdW5jdGlvbiA9IGRlbHRhID4gMCA/IFFzY3JvbGxiYXJfY2hh cl9sZWZ0IDogUXNjcm9sbGJhcl9jaGFyX3JpZ2h0Ow0KICAgICAgaWYgKHRvU2Nyb2xsIDwgMCkN Cgl0b1Njcm9sbCA9IC10b1Njcm9sbDsNCiAgICAgIHdoaWxlICh0b1Njcm9sbC0tKQ0KCW1zd2lu ZG93c19lbnF1ZXVlX21pc2NfdXNlcl9ldmVudCAoZnJhbWUsIGZ1bmN0aW9uLCB3aW4pOw0KICAg IH0NCg0KICByZXR1cm4gVFJVRTsNCn0NCg0KI2lmZGVmIE1FTU9SWV9VU0FHRV9TVEFUUw0KDQpz dGF0aWMgaW50DQptc3dpbmRvd3NfY29tcHV0ZV9zY3JvbGxiYXJfaW5zdGFuY2VfdXNhZ2UgKHN0 cnVjdCBkZXZpY2UgKmQsDQoJCQkJICAgIHN0cnVjdCBzY3JvbGxiYXJfaW5zdGFuY2UgKmluc3Qs DQoJCQkJICAgIHN0cnVjdCBvdmVyaGVhZF9zdGF0cyAqb3ZzdGF0cykNCnsNCiAgaW50IHRvdGFs ID0gMDsNCg0KICB3aGlsZSAoaW5zdCkNCiAgICB7DQogICAgICBzdHJ1Y3QgbXN3aW5kb3dzX3Nj cm9sbGJhcl9kYXRhICpkYXRhID0NCgkoc3RydWN0IG1zd2luZG93c19zY3JvbGxiYXJfZGF0YSAq KSBpbnN0LT5zY3JvbGxiYXJfZGF0YTsNCg0KICAgICAgdG90YWwgKz0gbWFsbG9jZWRfc3RvcmFn ZV9zaXplIChkYXRhLCBzaXplb2YgKCpkYXRhKSwgb3ZzdGF0cyk7DQogICAgICBpbnN0ID0gaW5z dC0+bmV4dDsNCiAgICB9DQoNCiAgcmV0dXJuIHRvdGFsOw0KfQ0KDQojZW5kaWYgLyogTUVNT1JZ X1VTQUdFX1NUQVRTICovDQoMDQovKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLw0KLyogICAgICAgICAgRGV2aWNl LXNwZWNpZmljIGdob3N0IHNwZWNpZmllcnMgaW5pdGlhbGl6YXRpb24gICAgICAgICAgICAgKi8N Ci8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKiovDQoNCkRFRlVOICgibXN3aW5kb3dzLWluaXQtc2Nyb2xsYmFyLW1l dHJpY3MiLCBGbXN3aW5kb3dzX2luaXRfc2Nyb2xsYmFyX21ldHJpY3MsIDEsIDEsIDAsIC8qDQoq Lw0KICAgICAgIChsb2NhbGUpKQ0Kew0KICBpZiAoREVWSUNFUCAobG9jYWxlKSkNCiAgICB7DQog ICAgICBhZGRfc3BlY190b19naG9zdF9zcGVjaWZpZXIgKFZzY3JvbGxiYXJfd2lkdGgsDQoJCQkJ ICAgbWFrZV9pbnQgKEdldFN5c3RlbU1ldHJpY3MgKFNNX0NYVlNDUk9MTCkpLA0KCQkJCSAgIGxv Y2FsZSwgUW1zd2luZG93cywgUW5pbCk7DQogICAgICBhZGRfc3BlY190b19naG9zdF9zcGVjaWZp ZXIgKFZzY3JvbGxiYXJfaGVpZ2h0LA0KCQkJCSAgIG1ha2VfaW50IChHZXRTeXN0ZW1NZXRyaWNz IChTTV9DWUhTQ1JPTEwpKSwNCgkJCQkgICBsb2NhbGUsIFFtc3dpbmRvd3MsIFFuaWwpOw0KICAg IH0NCiAgcmV0dXJuIFFuaWw7DQp9DQoNCgwNCi8qKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovDQovKiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpbml0aWFsaXphdGlvbiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAqLw0KLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKi8NCg0Kdm9pZA0KY29uc29sZV90eXBlX2NyZWF0ZV9z Y3JvbGxiYXJfbXN3aW5kb3dzICh2b2lkKQ0Kew0KICBDT05TT0xFX0hBU19NRVRIT0QgKG1zd2lu ZG93cywgY3JlYXRlX3Njcm9sbGJhcl9pbnN0YW5jZSk7DQogIENPTlNPTEVfSEFTX01FVEhPRCAo bXN3aW5kb3dzLCBmcmVlX3Njcm9sbGJhcl9pbnN0YW5jZSk7DQogIENPTlNPTEVfSEFTX01FVEhP RCAobXN3aW5kb3dzLCByZWxlYXNlX3Njcm9sbGJhcl9pbnN0YW5jZSk7DQogIENPTlNPTEVfSEFT X01FVEhPRCAobXN3aW5kb3dzLCB1cGRhdGVfc2Nyb2xsYmFyX2luc3RhbmNlX3ZhbHVlcyk7DQog IENPTlNPTEVfSEFTX01FVEhPRCAobXN3aW5kb3dzLCB1cGRhdGVfc2Nyb2xsYmFyX2luc3RhbmNl X3N0YXR1cyk7DQovKiAgQ09OU09MRV9IQVNfTUVUSE9EIChtc3dpbmRvd3MsIHNjcm9sbGJhcl93 aWR0aF9jaGFuZ2VkX2luX2ZyYW1lKTsgKi8NCiNpZmRlZiBNRU1PUllfVVNBR0VfU1RBVFMNCiAg Q09OU09MRV9IQVNfTUVUSE9EIChtc3dpbmRvd3MsIGNvbXB1dGVfc2Nyb2xsYmFyX2luc3RhbmNl X3VzYWdlKTsNCiNlbmRpZg0KfQ0KDQp2b2lkDQpzeW1zX29mX3Njcm9sbGJhcl9tc3dpbmRvd3Mo dm9pZCkNCnsNCiAgREVGU1VCUiAoRm1zd2luZG93c19pbml0X3Njcm9sbGJhcl9tZXRyaWNzKTsN Cn0NCg0Kdm9pZA0KdmFyc19vZl9zY3JvbGxiYXJfbXN3aW5kb3dzKHZvaWQpDQp7DQogIEZwcm92 aWRlIChpbnRlcm4gKCJtc3dpbmRvd3Mtc2Nyb2xsYmFycyIpKTsNCn0NCg0K ------_=_NextPart_001_01C0E077.B2771D28-- From gbsadler1@lcisp.com Sat May 19 11:52:20 2001 Received: from debian-home (ch-12-44-141-183.lcisp.com [12.44.141.183] (may be forged)) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA12040; Sat, 19 May 2001 11:52:17 -0400 Received: from gbsadler by debian-home with local (Exim 3.22 #1 (Debian)) id 15191V-0003nJ-00; Sat, 19 May 2001 10:52:09 -0500 Date: Sat, 19 May 2001 10:52:08 -0500 To: xemacs-beta@xemacs.org Cc: xemacs-nt@xemacs.org Subject: Re: patch for PR1504: scroll crash Message-ID: <20010519105208.A14569@debian-home.lcisp.com> Mail-Followup-To: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: Gordon Sadler Sender: Gordon Sadler --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, May 19, 2001 at 11:23:46AM -0400, Paul Krause wrote: > Please ignore the patch posted to xemacs-patches, it is incorrect. > > I appear to be patch challenged for the time being. The computer with > a working CVS and the computer where I can reproduce the bug are > incommunicado, and I made a cut-and-paste error attempting to prepare > the patch. The version I posted probably won't even compile. > > I have attached the entire contexts of the file to be patched to this > message. If someone with a non-bogus development environment would use > to prepare a correct patch I would be grateful. > > Original patch: > To: < xemacs-patches@xemacs.org > > Subject: patch for PR1504: scroll crash > From: "Paul Krause" < paulkrause1@mediaone.net > > > Date: Sat, 19 May 2001 00:57:55 -0400 > Cc: < xmeacs-nt@xemacs.org > > Message-ID: < 003601c0e020$67f10d40$6401a8c0@paulkrause > > > This is against CVS HEAD. -- Gordon Sadler --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="scrollbar-msw.c.diff" --- scrollbar-msw.c Sat Apr 28 02:48:46 2001 +++ scrollbar-msw.c.new Sat May 19 10:42:31 2001 @@ -114,7 +114,13 @@ int new_scrollbar_y) { int pos_changed = 0; - int vert = GetWindowLong (SCROLLBAR_MSW_HANDLE (sb), GWL_STYLE) & SBS_VERT; + long styles = GetWindowLong (SCROLLBAR_MSW_HANDLE (sb), GWL_STYLE); + int vert = styles & SBS_VERT; + + if (styles == 0) { + mswindows_output_last_error("GetWindowLong"); + return; + } #if 0 stderr_out ("[%d, %d], page = %d, pos = %d, inhibit = %d\n", new_minimum, new_maximum, @@ -176,15 +182,20 @@ struct frame *f; Lisp_Object win, frame; struct scrollbar_instance *sb; - SCROLLINFO scrollinfo; - int vert = GetWindowLong (hwnd, GWL_STYLE) & SBS_VERT; - int value; + long styles = GetWindowLong (hwnd, GWL_STYLE); + int vert = styles & SBS_VERT; + + if (styles == 0) { + mswindows_output_last_error("GetWindowLong"); + return; + } sb = (struct scrollbar_instance *)GetWindowLong (hwnd, GWL_USERDATA); + if (sb != NULL) { win = real_window (sb->mirror, 1); frame = XWINDOW (win)->frame; f = XFRAME (frame); - + } /* SB_LINEDOWN == SB_CHARLEFT etc. This is the way they will always be - any Windows is binary compatible backward with old programs */ @@ -226,6 +237,9 @@ case SB_THUMBTRACK: case SB_THUMBPOSITION: + { + int pos; + SCROLLINFO scrollinfo; scrollinfo.cbSize = sizeof(SCROLLINFO); scrollinfo.fMask = SIF_ALL; GetScrollInfo (hwnd, SB_CTL, &scrollinfo); @@ -237,7 +251,7 @@ * ((text remaining in buffer at start of drag) * * (amount that the thumb has been moved) / * (space that remained past end of the thumb at start of drag)) */ - value = (int) + pos = (int) (scrollinfo.nPos + (((double) (scrollinfo.nMax - scrollinfo.nPos) @@ -246,16 +260,17 @@ - 2; /* ensure that the last line doesn't disappear off screen */ else #endif - value = scrollinfo.nTrackPos; + pos = scrollinfo.nTrackPos; mswindows_enqueue_misc_user_event (frame, vert ? Qscrollbar_vertical_drag : Qscrollbar_horizontal_drag, - Fcons (win, make_int (value))); + Fcons (win, make_int (pos))); + } break; case SB_ENDSCROLL: #ifdef VERTICAL_SCROLLBAR_DRAG_HACK - if (vertical_drag_in_progress) + if (vertical_drag_in_progress && sb) /* User has just dropped the thumb - finally update it */ SetScrollInfo (SCROLLBAR_MSW_HANDLE (sb), SB_CTL, &SCROLLBAR_MSW_INFO (sb), TRUE); --fdj2RfSjLxBAspz7-- From Aki.Vehtari@hut.fi Sat May 19 14:19:17 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA16779 for ; Sat, 19 May 2001 14:19:13 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4JIJC602198 for ; Sat, 19 May 2001 21:19:12 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4JIJCY13496; Sat, 19 May 2001 21:19:12 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: [BUG] term goes in eternal loop on XEmacs 21.4.* on *-dec-osf* References: From: Aki Vehtari In-Reply-To: Date: 19 May 2001 21:19:11 +0300 Message-ID: Lines: 133 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii C-g causes term to go in eternal loop. In X only way to stop it is to kill XEmacs. In tty 3 additional C-g's cause suspend and after that abort and core dump. Tested on XEmacs 21.4.* (ev56|ev67)-dec-osf(4.0f|5.0) How to reproduce, Lisp and C backtraces and Installation description: ---Clip--- xemacs -nw -vanilla M-x term C-g C-g C-g C-g zsh: 1805 suspended src/xemacs -nw -vanilla biton 21:16 /proj/ave/xemacs/build/alpha-dec-osf4.0 % fg [1] + continued src/xemacs -nw -vanilla Auto-save? (y or n) n Abort (and dump core)? (y or n) y Fatal error: assertion failed, file /proj/ave/xemacs/xemacs-21.4.3/src/signal.c, line 426, abort() Fatal error (6). Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes@xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /proj/ave/xemacs/build/alpha-dec-osf4.0/src/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: #(1) # (unwind-protect ...) # bind (count) term-handle-deferred-scroll() # bind (kind) term-erase-in-display(0) # bind (char proc) term-handle-ansi-escape(# ?J) # (unwind-protect ...) # (unwind-protect ...) # bind (str-length selected win temp old-point save-marker save-point count funny char i previous-buffer str proc) term-emulate-terminal(# "/alpha-dec-osfbiton /proj/ave/xemacs/build/alpha-dec-osf4.0 %") # (condition-case ... . error) # bind (inhibit-quit) # (condition-case ... . error) # (catch top-level ...) zsh: 1805 abort (core dumped) src/xemacs -nw -vanilla (gdb) where #0 0x3ff800edea8 in ?? () #1 0x120099f68 in fatal_error_signal (sig=0) at /proj/ave/xemacs/xemacs-21.4.3/src/emacs.c:535 #2 0x120099f68 in fatal_error_signal (sig=Cannot access memory at address 0x8. ) at /proj/ave/xemacs/xemacs-21.4.3/src/emacs.c:535 Cannot access memory at address 0x20. uname -a: OSF1 biton.lce.hut.fi V4.0 1229 alpha alpha /proj/ave/xemacs/xemacs-21.4.3/configure '--prefix=/proj/ave/xemacs/' '--srcdir=/proj/ave/xemacs/xemacs-21.4.3' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--cppflags=-DREGEX_MALLOC' '--debug=yes' '--cflags=-g' XEmacs 21.4.3 "Academic Rigor" configured for `alphaev67-dec-osf4.0f'. Compilation / Installation: Source code location: /proj/ave/xemacs/xemacs-21.4.3 Installation prefix: /proj/ave/xemacs/ Additional header files: /usr/local/include Additional libraries: /usr/local/lib Runtime library search path: /usr/local/lib:/usr/dt/lib Operating system description file: `s/decosf4-0.h' Machine description file: `m/alpha.h' Compiler: cc -g Relocating allocator for buffers: yes GNU version of malloc: yes Window System: Compiling in support for the X window system: - X Windows headers location: /usr/dt/include - X Windows libraries location: /usr/dt/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Using Motif native widgets. TTY: Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Sound: Databases: Compiling in support for Berkeley database. Compiling in support for DBM. Internationalization: Mail: Compiling in support for "flock" mail spool file locking method. Other Features: Compiling in support for ToolTalk. Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. From Aki.Vehtari@hut.fi Sat May 19 14:50:52 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA17805 for ; Sat, 19 May 2001 14:50:50 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4JIon603115 for ; Sat, 19 May 2001 21:50:49 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4JIom013515; Sat, 19 May 2001 21:50:48 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> <004301c0de6a$c4184b40$1300a8c0@bp.aventail.com> From: Aki Vehtari In-Reply-To: <004301c0de6a$c4184b40$1300a8c0@bp.aventail.com> Date: 19 May 2001 21:50:48 +0300 Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii William M Perry writes: > I'm not sure if you can raise the stack size once your > program has started. I know that you can do it for threads > on digital unix very simply. We could put code like this > where appropriate. > static int __check_stack_requirements(int necessary) > { > #ifdef RLIMIT_STACK > struct rlimit rl; > if (getrlimit(RLIMIT_STACK,&rl) == 0) > { > if (rl.rlim_cur >= necessary) > /* Everything will work just fine... */ > return (0); > } > if (rl.rlim_max < necessary) > { > /* Maximum stack size is still too small... > ** Should we just fail to start? > */ > return (-1); > } How can you know how much is necessary? In my case the stack overflow occurred when opening BibTeX-file with long abstract fields. It's not possible to know beforehand how long abstracts there might be. And please no failing, I'd prefer just a warning like with REGEXP_MALLOC: itimer "itimer-<1>" signaled: (error "Stack overflow in regexp matcher") Aki From Aki.Vehtari@hut.fi Sat May 19 15:05:20 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA18281 for ; Sat, 19 May 2001 15:05:19 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4JJ5E603367 for ; Sat, 19 May 2001 22:05:14 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4JJ5E213541; Sat, 19 May 2001 22:05:14 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: Re: [BUG] term freezes on XEmacs 21.4.* on *-dec-osf* References: From: Aki Vehtari In-Reply-To: Date: 19 May 2001 22:05:14 +0300 Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Aki Vehtari writes: > When larger text is inserted to term (or matlab-shell) it freezes > on XEmacs 21.4.* (ev56|ev6|ev67)-dec-osf(4.0d|4.0f|5.0) > On XEmacs 21.1.* term (or matlab-shell) does not freeze like this. In fact, this problem is much more severe with matlab-shell as it can take any input total of about 246 characters and then freezes. I use matlab-shell every day, but this bug prevents me upgrading to XEmacs 21.4... :-( I don't know how to debug this, as it does not produce error, freezing or crash. Process just does not respond to anything, but otherwise XEmacs keeps running ok. Aki From andyp@bea.com Sat May 19 16:07:33 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA20508 for ; Sat, 19 May 2001 16:07:32 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA00364; Sat, 19 May 2001 13:07:39 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001245wss.beasys.com [192.168.6.76]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id NAA03850; Sat, 19 May 2001 13:07:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 19 May 2001 13:05:08 -0700 To: Simon Josefsson , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: fyi mail-lib status In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:05 PM 5/19/01 +0200, Simon Josefsson wrote: >pop3.el Heavy modifications. (Rename to xpop3.el?) We forked from the FSF because the author didn't want to make reasonable changes. I don't see why we should rename it. abdy From hniksic@arsdigita.com Sat May 19 16:18:53 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA20979 for ; Sat, 19 May 2001 16:18:53 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 151DBc-0004rI-00 for ; Sat, 19 May 2001 22:18:52 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 19 May 2001 22:18:52 +0200 In-Reply-To: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> (Andy Piper's message of "Sat, 19 May 2001 13:05:08 -0700") Message-ID: Lines: 9 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Andy Piper writes: > At 12:05 PM 5/19/01 +0200, Simon Josefsson wrote: > >pop3.el Heavy modifications. (Rename to xpop3.el?) > > We forked from the FSF because the author didn't want to make > reasonable changes. Note that the FSF *also* forked from the author's version. From Adrian.Aichner@t-online.de Sat May 19 17:05:24 2001 Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA22446 for ; Sat, 19 May 2001 17:05:24 -0400 Received: from fwd03.sul.t-online.de by mailout04.sul.t-online.com with smtp id 151Duo-0001An-07; Sat, 19 May 2001 23:05:34 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.63]) by fwd03.sul.t-online.com with esmtp id 151Dv0-1dTs36C; Sat, 19 May 2001 23:05:46 +0200 To: Andy Piper Cc: Simon Josefsson , xemacs-beta@xemacs.org Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: <8zjt6oe4.fsf@rapier.ecf.teradyne.com> Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Andy" == Andy Piper writes: Andy> At 12:05 PM 5/19/01 +0200, Simon Josefsson wrote: >> pop3.el Heavy modifications. (Rename to xpop3.el?) Andy> We forked from the FSF because the author didn't want to make Andy> reasonable changes. I don't see why we should rename it. gnus also includes pop3.el. The xemacs.mak I contributed to gnus allows use of XEmacs mail-lib's pop3.el by means of variable USE_XEMACS_MAIL_LIB. Renaming our pop3.el would break that integration needlessly. Best regards, Adrian Andy> abdy -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From simon@josefsson.org Sat May 19 17:59:43 2001 Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA24381 for ; Sat, 19 May 2001 17:59:42 -0400 Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f4JLxnq01231; Sat, 19 May 2001 23:59:50 +0200 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Andy Piper , xemacs-beta@xemacs.org Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> From: Simon Josefsson In-Reply-To: <8zjt6oe4.fsf@rapier.ecf.teradyne.com> (Adrian.Aichner@t-online.de's message of "19 May 2001 23:05:07 +0200") Date: 19 May 2001 23:59:51 +0200 Message-ID: Lines: 19 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian.Aichner@t-online.de (Adrian Aichner) writes: > >> pop3.el Heavy modifications. (Rename to xpop3.el?) > > Andy> We forked from the FSF because the author didn't want to make > Andy> reasonable changes. I don't see why we should rename it. > > gnus also includes pop3.el. ... > Renaming our pop3.el would break that integration needlessly. Yes, it was only a thought, only renaming it would be bad. But I felt it wasn't perfect to have two (different) files with the same name. (Which one will be used?) Also, what about epop3? At least it shares some of the same function names as mail-lib's pop3.el, and looks like it also share some of the same features as mail-lib pop3 (UIDL etc). Also, there has actually been a release of it recently (well, within the last 10 months). From Adrian.Aichner@t-online.de Sat May 19 18:22:01 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA25151 for ; Sat, 19 May 2001 18:22:01 -0400 Received: from fwd07.sul.t-online.de by mailout06.sul.t-online.com with smtp id 151F71-0002bM-02; Sun, 20 May 2001 00:22:15 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.63]) by fwd07.sul.t-online.com with esmtp id 151F6t-0CbDweC; Sun, 20 May 2001 00:22:07 +0200 To: Simon Josefsson Cc: Adrian.Aichner@t-online.de (Adrian Aichner), Andy Piper , xemacs-beta@xemacs.org Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: <66exyo78.fsf@rapier.ecf.teradyne.com> Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Simon" == Simon Josefsson writes: Simon> Adrian.Aichner@t-online.de (Adrian Aichner) writes: >> >> pop3.el Heavy modifications. (Rename to xpop3.el?) >> Andy> We forked from the FSF because the author didn't want to make Andy> reasonable changes. I don't see why we should rename it. >> >> gnus also includes pop3.el. Simon> ... >> Renaming our pop3.el would break that integration needlessly. Simon> Yes, it was only a thought, only renaming it would be bad. Simon> But I felt it wasn't perfect to have two (different) files Simon> with the same name. (Which one will be used?) Simon> Also, what about epop3? At least it shares some of the Simon> same function names as mail-lib's pop3.el, and looks like Simon> it also share some of the same features as mail-lib pop3 Simon> (UIDL etc). Also, there has actually been a release of it Simon> recently (well, within the last 10 months). Simon, I think Andy is our resident expert on pop3. Right, Andy? -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From misiek@pld.ORG.PL Sat May 19 18:35:12 2001 Received: from arm.t19.ds.pwr.wroc.pl (arm.t19.ds.pwr.wroc.pl [156.17.211.119]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA25697 for ; Sat, 19 May 2001 18:35:11 -0400 Received: from misiek by arm.t19.ds.pwr.wroc.pl with local (Exim 3.22 #1) id 151ELW-0001eu-00 for xemacs-beta@xemacs.org; Sat, 19 May 2001 23:33:10 +0200 To: xemacs-beta@xemacs.org Subject: selection using mouse in xemacs 21.4.3 (gtk) X-URL: http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ Organization: Polish(ed) Linux Distribution Team From: Arkadiusz Miskiewicz Date: 19 May 2001 23:33:08 +0200 Message-ID: <874ruht46j.fsf@arm.t19.ds.pwr.wroc.pl> Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Sender: Arkadiusz Miskiewicz Hi, I just tried xemacs 21.4.3 version with gtk and mule enabled. In previous version - 21.1.14 + athena there was possibility to copy and paste under X Window using mouse (left to copy; middle to paste). In 21.4.3 + gtk this doesn't work while info page (Using X Selections) still says that's possible. I don't know if this is generic problem with all gtk versions, with all 21.4.x beta series or just my local emacs problem. Any suggestions/patches how to enable/fix such copying in X Window? ps. I'm not subscribed to please cc: me. -- Arkadiusz Mi¶kiewicz, AM2-6BONE [ PLD GNU/Linux IPv6 ] http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ [ enabled ] From ben@666.com Sat May 19 19:57:09 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA29081 for ; Sat, 19 May 2001 19:57:04 -0400 Received: (qmail 7578 invoked by alias); 19 May 2001 23:46:09 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 85710 invoked by uid 0); 19 May 2001 23:34:21 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 19 May 2001 23:34:21 -0000 Message-ID: <3B070357.29392447@666.com> Date: Sat, 19 May 2001 16:35:51 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: Re: Minor build fixes for 21.4.3 References: <4.3.2.7.2.20010517121830.00b0a920@san-francisco.beasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit please do apply to 21.5, looks good. Andy Piper wrote: > > I didn't deliberately do this just after Stephen released. These are needed > for correct compilation under cygwin 1.3.1. Should be applied to 21.5 as > well [I'm beginning to love perforce - the way you can do integs across > versions easily]. > > andy > > 2001-05-17 Andy Piper > > * sysfile.h: don't assume that file attributes are boolean > > 2001-05-17 Andy Piper > > * win32.h: > * win32.h (NOCOMATTRIBUTE): sync with latest cygwin version. > > -------------------------------------------------------------------------------- > Name: min.patch > min.patch Type: Plain Text (text/plain) > Encoding: base64 -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From wmperry@aventail.com Sat May 19 20:44:32 2001 Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA30918 for ; Sat, 19 May 2001 20:44:31 -0400 Received: from slow.bp.aventail.com ([24.12.70.142]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010520004430.TQMU553.femail18.sdc1.sfba.home.com@slow.bp.aventail.com>; Sat, 19 May 2001 17:44:30 -0700 Received: from sigh (sigh.bp.aventail.com [192.168.0.19]) by slow.bp.aventail.com (8.9.3/8.9.3) with SMTP id TAA25823; Sat, 19 May 2001 19:38:15 -0500 Message-ID: <001701c0e0ef$ef5b0860$1300a8c0@bp.aventail.com> From: "William M. Perry" To: , "Arkadiusz Miskiewicz" References: <874ruht46j.fsf@arm.t19.ds.pwr.wroc.pl> Subject: Re: selection using mouse in xemacs 21.4.3 (gtk) Date: Sun, 20 May 2001 00:44:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 > I just tried xemacs 21.4.3 version with gtk and mule enabled. > In previous version - 21.1.14 + athena there was possibility to copy > and paste under X Window using mouse (left to copy; middle to > paste). In 21.4.3 + gtk this doesn't work while info page (Using X > Selections) still says that's possible. > I don't know if this is generic problem with all gtk versions, > with all 21.4.x beta series or just my local emacs problem. > > Any suggestions/patches how to enable/fix such copying in X Window? Known bug - we should probably document it in etc/PROBLEMS. It happens in the 21.5 series as well - I just haven't been able to track it down. I imagine it is something stupid on my part when I did the 21.4 GTK merge. The mouse and selection handling changed drastically from 21.2, and I probably just missed something. I will try to take a look at this tonight - the wife is going out, and liam is getting ready for bed. -bp From ben@666.com Sat May 19 21:58:08 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id VAA01071 for ; Sat, 19 May 2001 21:58:06 -0400 Received: (qmail 10355 invoked by alias); 20 May 2001 01:58:04 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 10312 invoked by uid 0); 20 May 2001 01:58:03 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 20 May 2001 01:58:03 -0000 Message-ID: <3B072505.3B282E7B@666.com> Date: Sat, 19 May 2001 18:59:33 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael Sperber [Mr. Preprocessor]" CC: Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit mike, first off, there's a doc problem: `efs-auto-save' is a variable declared in Lisp. -- loaded from "efs" Value: t Documentation: *If 1, allows efs files to be auto-saved. If 0, suppresses auto-saving of efs files. Don't use any other value. also, when i load up /ben@gwyn.tux.org:/etc/mail/xemacs, then hit `f' on aliases-xemacs, make a change, and save, i get these messages: CWD'ing to aliases-xemacs... CWD'ing to aliases-xemacs...8k (42.1 KB/s) CWD'ing to aliases-xemacs...9k (26.5 KB/s) CWD'ing to aliases-xemacs...10k (24.9 KB/s) CWD'ing to aliases-xemacs...11k (21.5 KB/s) CWD'ing to aliases-xemacs...13k (24.0 KB/s) CWD'ing to aliases-xemacs...14k (15.5 KB/s) CWD'ing to aliases-xemacs...22k (8.4 KB/s) CWD'ing to aliases-xemacs...25k (5.8 KB/s) CWD'ing to aliases-xemacs...26k (5.8 KB/s) CWD'ing to aliases-xemacs...done Listing aliases-xemacs... Listing aliases-xemacs...done why is it claiming to be CWD'ing to a file? [it saves fine, though] third, efs has problems with ftp.microsoft.com: /ftp.microsoft.com:/ use f to go to kbhelp, hit f on ~ftpsvc~.ckm, you get a buffer named "® PÔï". start over, use f to go to misc; f works on the file cbcp.txt, but most other .txt files e.g. disclaim.txt give you the error File not found and directory write-protected and the culprit: open ftp.microsoft.com Connected to ftp.microsoft.com. 220 CPMSFTFTPA05 Microsoft FTP Service (Version 5.0). quote user "anonymous" 331 Anonymous access allowed, send identity (e-mail name) as password. quote pass Turtle Power! 230-This is FTP.MICROSOFT.COM Please see the dirmap.txt 230-file for more information. 230 Anonymous user logged in. hash Hash mark printing on (1024 bytes/hash mark). quote pwd 257 "/" is current directory. quote syst 215 Windows_NT version 5.0 quote cwd / 250 CWD command successful. ls "-al" C:/DOCUME~1/BENWIN~1/LOCALS~1/Temp/efsaQAymx 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. # 226 Transfer complete. quote site idle 500 'SITE idle': command not understood quote cwd /misc/ 250 CWD command successful. ls "-al" C:/DOCUME~1/BENWIN~1/LOCALS~1/Temp/efsaQAymx 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. ### 226 Transfer complete. quote rnfr /misc/disclaim.txt 550 /misc/disclaim.txt: Access is denied. type image 200 Type set to I. get /misc/cbcp.txt C:/DOCUME~1/BENWIN~1/LOCALS~1/Temp/efsaQAymx.txt 200 PORT command successful. 150 Opening BINARY mode data connection for /misc/cbcp.txt(15749 bytes). ############### 226 Transfer complete. 15749 bytes received in 0.35 seconds (44997 bytes/s) quote cwd /kbhelp/ 250 CWD command successful. ls "-al" C:/DOCUME~1/BENWIN~1/LOCALS~1/Temp/efsbQAymx 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. # 226 Transfer complete. "Michael Sperber [Mr. Preprocessor]" wrote: > > Steve Youngs has just released EFS package version 1.25. This is an > experimental prerelease of EFS available as > > /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/efs-1.25-pkg.tar.gz > > In order to turn this into an official package release, I urgently > need your help in testing it. I've tested EFS on a number of servers, > but I only have access to Unix machines for client testing. So I > especially need some reports from Windows users, connecting to both > Unix and Windows ftp servers. This is especially as some subtle but > possibly crucial aspects of the EFS<->client interactions have > changed. > > I'm slowly working towards a testing suite, but it is not yet done and > the urgency of the XEmacs/Cygwin situation has prompted me to try to > release earlier. > > Let me emphasize that, if I cannot get some testing done by the > community, the release will be significantly delayed, as we cannot > risk putting out a faulty EFS to the general user community, given its > current prominent role in the XEmacs package system. > > I appreciate your help. > > -- > Cheers =8-} Mike > Friede, Völkerverständigung und überhaupt blabla -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From martin@m17n.org Sun May 20 00:51:58 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA08830 for ; Sun, 20 May 2001 00:51:53 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4K4q6p14358; Sun, 20 May 2001 13:52:06 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id NAA12332; Sun, 20 May 2001 13:51:45 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4K4phT20656; Sun, 20 May 2001 13:51:43 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15111.19807.227840.71806@gargle.gargle.HOWL> Date: Sun, 20 May 2001 13:51:43 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Isaac Hollander Cc: xemacs-beta@xemacs.org Subject: Re: 21.4.2 mwheel.el woes In-Reply-To: <200105170314.XAA27100@johnson.mail.mindspring.net> References: <200105150045.UAA27344@smtp10.atl.mindspring.net> <867kzj4e2b.fsf@hel.bp.aventail.com> <200105150109.VAA25324@smtp10.atl.mindspring.net> <3B00A94B.BC0695FE@666.com> <200105152221.SAA08921@barry.mail.mindspring.net> <3B0304A1.2F991A93@666.com> <200105170314.XAA27100@johnson.mail.mindspring.net> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "I" == Isaac Hollander writes: I> #ifdef SIGUSR1 I> handle_signal_if_fatal (SIGUSR1); /* POSIX */ I> #endif I> I assume the /* POSIX */ comment means that SIGUSR1 is a POSIX signal as I> opposed to an ANSI signal, not that the signal is handled with POSIX I> sementics. The comment simply means it's defined by the Posix standard. This has nothing to do with sigaction. I> So there's a possibility that in between the 2 calls to signal, another I> signal could arrive, and since the signal is reset to default behavior, I> the unignored SIGUSR1 causes a crash. I> Would using the POSIX signal functions (sigaction and friends) help here? My guess is that XEmacs is already using sigaction, even if it doesn't look like it. Try `make signal.i' and look at the preprocessor output. From martin@m17n.org Sun May 20 01:19:52 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA10679 for ; Sun, 20 May 2001 01:19:51 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4K5K5p14502; Sun, 20 May 2001 14:20:05 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id OAA12405; Sun, 20 May 2001 14:19:43 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4K5Jh520790; Sun, 20 May 2001 14:19:43 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15111.21486.950587.886157@gargle.gargle.HOWL> Date: Sun, 20 May 2001 14:19:42 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC In-Reply-To: References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> <15107.15547.488315.295310@turnbull.sk.tsukuba.ac.jp> <9995-Thu17May2001095512+0100-starksb@ebi.ac.uk> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> People don't read PROBLEMS. People prefer programs that work, and I Hrvoje> can understand that sentiment. It should be really easy to increase Hrvoje> the stack size programatically. Agreed. The stack size should be automatically increased. Doing it portably requires some autoconfing, etc. OSF aka Digital Unix aka Tru64 has a low stack size (2MB), but MacOS X has an insanely low stack size (512kb), especially considering there are no backward compatibility considerations. From martin@m17n.org Sun May 20 02:11:25 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA13189; Sun, 20 May 2001 02:11:24 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4K6Bhp14644; Sun, 20 May 2001 15:11:43 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id PAA12515; Sun, 20 May 2001 15:11:21 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4K6BLT20930; Sun, 20 May 2001 15:11:21 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15111.24585.586600.484683@gargle.gargle.HOWL> Date: Sun, 20 May 2001 15:11:21 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Yoshiki Hayashi , XEmacs Patches Cc: xemacs-beta@xemacs.org Subject: Re: [BUG] Too agressive byte code optimizer In-Reply-To: <87zocb7xal.fsf@u.sanpo.t.u-tokyo.ac.jp> References: <87zocb7xal.fsf@u.sanpo.t.u-tokyo.ac.jp> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Y" == Yoshiki Hayashi writes: Y> When following form is eval'ed, it signals an error: Y> Wrong type argument: number-char-or-marker-p, a Y> (= 'a) Y> However, if it's byte-compiled, it returns t. Y> (disassemble (byte-compile (lambda () (= 'a)))) Y> shows: Y> byte code: Y> args: nil Y> 0 constant t Y> 1 return Y> Martin? `byte-compile-delete-errors' is a variable declared in Lisp. -- loaded from "bytecomp" Value: t Documentation: *If non-nil, the optimizer may delete forms that may signal an error. This includes variable references and calls to functions such as `car'. There is already this code in byte-plus that optimizes (+ x) ==> x (case elt (0 (when (not byte-compile-delete-errors) (byte-compile-constant 0) (byte-compile-out 'byte-plus 0))) (+1 (byte-compile-out 'byte-add1 0)) (-1 (byte-compile-out 'byte-sub1 0)) (= x) should work the same way. You can also argue that if the argument (or arguments) is/are CONSTANT, then there should be compile-time evaluation. I haven't implemented that in this patch. Index: lisp/ChangeLog =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/ChangeLog,v retrieving revision 1.292 diff -u -w -U0 -r1.292 ChangeLog --- lisp/ChangeLog 2001/05/20 01:17:07 1.292 +++ lisp/ChangeLog 2001/05/20 06:01:49 @@ -0,0 +1,5 @@ +2001-05-20 Martin Buchholz + + * bytecomp.el (byte-compile-arithcompare): + Only optimize (= x) ==> t if byte-compile-delete-errors is nil. + Index: lisp/bytecomp.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/bytecomp.el,v retrieving revision 1.12 diff -u -w -r1.12 bytecomp.el --- lisp/bytecomp.el 2001/05/04 22:41:59 1.12 +++ lisp/bytecomp.el 2001/05/20 06:02:18 @@ -3205,7 +3205,9 @@ (defun byte-compile-arithcompare (form) (case (length (cdr form)) (0 (byte-compile-subr-wrong-args form "1 or more")) - (1 (byte-compile-constant t)) + (1 (if byte-compile-delete-errors + (byte-compile-constant t) + (byte-compile-normal-call form))) (2 (byte-compile-two-args form)) (t (byte-compile-normal-call form)))) From ben@666.com Sun May 20 03:18:34 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id DAA15352 for ; Sun, 20 May 2001 03:18:33 -0400 Received: (qmail 53376 invoked by alias); 20 May 2001 07:18:31 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 53360 invoked by uid 0); 20 May 2001 07:18:31 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 20 May 2001 07:18:31 -0000 Message-ID: <3B077021.BE3E5B11@666.com> Date: Sun, 20 May 2001 00:20:01 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krause CC: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: patch for PR1504: scroll crash References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit paul, i tried to rewrite your patch to fix what you intended. i just committed it; please take a look at my posting to xemacs-patches [or just build the latest cvs sources]. Paul Krause wrote: > > Please ignore the patch posted to xemacs-patches, it is incorrect. > > I appear to be patch challenged for the time being. The computer with > a working CVS and the computer where I can reproduce the bug are > incommunicado, and I made a cut-and-paste error attempting to prepare > the patch. The version I posted probably won't even compile. > > I have attached the entire contexts of the file to be patched to this > message. If someone with a non-bogus development environment would use > to prepare a correct patch I would be grateful. > > Original patch: > To: < xemacs-patches@xemacs.org > > Subject: patch for PR1504: scroll crash > From: "Paul Krause" < paulkrause1@mediaone.net > > > Date: Sat, 19 May 2001 00:57:55 -0400 > Cc: < xmeacs-nt@xemacs.org > > Message-ID: < 003601c0e020$67f10d40$6401a8c0@paulkrause > > > > > -------------------------------------------------------------------------------- > Name: scrollbar-msw.c > scrollbar-msw.c Type: C Source file (application/x-unknown-content-type-cfile) > Encoding: base64 > Description: scrollbar-msw.c -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From youngs@xemacs.org Sun May 20 04:28:10 2001 Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [203.2.75.228]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA22996 for ; Sun, 20 May 2001 04:28:08 -0400 Received: from slackware.mynet.pc (wdcax13-145.dialup.optusnet.com.au [198.142.220.145]) by mail004.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4K8S0U13205 for ; Sun, 20 May 2001 18:28:00 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4K8MsAL031167; Sun, 20 May 2001 18:22:54 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 20 May 2001 18:22:52 +1000 In-Reply-To: <8zjt6oe4.fsf@rapier.ecf.teradyne.com> (Adrian.Aichner@t-online.de's message of "19 May 2001 23:05:07 +0200") Message-ID: Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "APA" == Adrian Aichner writes: >>>>>>"Andy" == Andy Piper writes: Andy> At 12:05 PM 5/19/01 +0200, Simon Josefsson wrote: >>>pop3.el Heavy modifications. (Rename to xpop3.el?) Andy> We forked from the FSF because the author didn't want to make Andy> reasonable changes. I don't see why we should rename it. APA> gnus also includes pop3.el. APA> The xemacs.mak I contributed to gnus allows use of XEmacs mail-lib's APA> pop3.el by means of variable USE_XEMACS_MAIL_LIB. The mail-lib's pop3.el _is_ the Gnus one. Simon synced it a while back. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From paulkrause1@mediaone.net Sun May 20 04:28:40 2001 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA23012; Sun, 20 May 2001 04:28:40 -0400 Received: from paulkrause (h002078ca16a1.ne.mediaone.net [24.128.196.78]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f4K8SQ827049; Sun, 20 May 2001 04:28:27 -0400 (EDT) Message-ID: <007901c0e107$cc502900$6401a8c0@paulkrause> Reply-To: "Paul Krause" From: "Paul Krause" To: "Ben Wing" Cc: , References: <3B077021.BE3E5B11@666.com> Subject: Re: patch for PR1504: scroll crash Date: Sun, 20 May 2001 04:35:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Ben Wing" > paul, i tried to rewrite your patch to fix what you intended. i just committed > it; please take a look at my posting to xemacs-patches [or just build the latest > cvs sources]. Thanks, that looks like it will work. And it does. Cross off one PR! -paul From alexm@hsys.msk.ru Sun May 20 05:09:03 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA24620 for ; Sun, 20 May 2001 05:09:02 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp129-170.dialup.mtu-net.ru [62.118.129.170]) by mtu.ru (Postfix) with ESMTP id AFA447349 for ; Sun, 20 May 2001 13:08:52 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 25707 invoked by uid 1000); 20 May 2001 09:03:54 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Ben Wing To: Ben Wing Cc: xemacs-beta@xemacs.org Subject: Re: Help test EFS References: <3B072505.3B282E7B@666.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 20 May 2001 13:03:53 +0400 In-Reply-To: Ben Wing's message of "Sat, 19 May 2001 18:59:33 -0700" Message-ID: <87lmnsqtmu.fsf@tyranny.hsys.msk.ru> Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "BW" == Ben Wing writes: BW> other .txt files e.g. disclaim.txt give you the error BW> File not found and directory write-protected Arrrgh!!! Please fix it to show WHICH file is not found. I'm getting this error every time I load info for the first time and it's very annoying. --alexm From Adrian.Aichner@t-online.de Sun May 20 05:20:33 2001 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA25019; Sun, 20 May 2001 05:20:32 -0400 Received: from fwd01.sul.t-online.de by mailout03.sul.t-online.com with smtp id 151POM-0003mo-0I; Sun, 20 May 2001 11:20:50 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.50]) by fwd01.sul.t-online.com with esmtp id 151POV-0g4kz2C; Sun, 20 May 2001 11:20:59 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "SY" == Steve Youngs writes: SY> |--==> "APA" == Adrian Aichner writes: >>>>>>> "Andy" == Andy Piper writes: Andy> At 12:05 PM 5/19/01 +0200, Simon Josefsson wrote: >>>> pop3.el Heavy modifications. (Rename to xpop3.el?) Andy> We forked from the FSF because the author didn't want to make Andy> reasonable changes. I don't see why we should rename it. APA> gnus also includes pop3.el. APA> The xemacs.mak I contributed to gnus allows use of XEmacs mail-lib's APA> pop3.el by means of variable USE_XEMACS_MAIL_LIB. SY> The mail-lib's pop3.el _is_ the Gnus one. Simon synced it a SY> while back. Oh, I missed that. Anyway, mail-lib's pop3.el will be needed for users who don't have gnus. gnus may have incompatible changes in the future. I guess my gnus/xemacs.mak logic is still applicable. Do you disagree? Adrian SY> -- SY> |---------------------| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |---------------------------------------| -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From karlheg@hegbloom.net Sun May 20 05:26:19 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA25199; Sun, 20 May 2001 05:26:18 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4K9QCW5002014; Sun, 20 May 2001 02:26:12 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4K9QCOr002011; Sun, 20 May 2001 02:26:12 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: Ben Wing Cc: Didier Verna , Hrvoje Niksic , XEmacs Beta List Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <3B00AC75.4A38896D@666.com> <3B010EFE.FB0B99E@666.com> X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Date: 20 May 2001 02:26:12 -0700 Message-ID: <87lmnstlqj.fsf@bittersweet.intra.hegbloom.net> Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii re: Reading the init file before mapping the first frame... I run XEmacs from a shell script that starts it with -unmapped -f gnuserv-start, and then only after XEmacs is all the way up does it use gnuclient to bring up the first frame. It works a lot better this way. On my laptop, I've got the color scheme and faces set up to give me a light on black color scheme and smaller frames for the old 800x600 laptop's screen. Without the -unmapped start up, though, the initial frame is standard grey and standard size, and only when I use `C-x 5 2' do I get light on black with the smaller frame size. From simon@josefsson.org Sun May 20 05:36:37 2001 Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA25548; Sun, 20 May 2001 05:36:35 -0400 Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f4K9abq08286; Sun, 20 May 2001 11:36:37 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> From: Simon Josefsson In-Reply-To: (Steve Youngs's message of "20 May 2001 18:22:52 +1000") Mail-Copies-To: nobody Date: 20 May 2001 11:36:45 +0200 Message-ID: Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Steve Youngs writes: > Andy> We forked from the FSF because the author didn't want to make > Andy> reasonable changes. I don't see why we should rename it. > > APA> gnus also includes pop3.el. > > APA> The xemacs.mak I contributed to gnus allows use of XEmacs mail-lib's > APA> pop3.el by means of variable USE_XEMACS_MAIL_LIB. > > The mail-lib's pop3.el _is_ the Gnus one. Simon synced it a while back. No, pop3.el in mail-lib is not the same as in Gnus -- the one in mail-lib got oodles of useful stuff not in the original pop3.el file. Oh, I just now noticed the pop3.el shipped with Gnus is not in the XEmacs gnus package. I guess the mail-lib pop3.el is backwards compatible then. From Adrian.Aichner@t-online.de Sun May 20 06:00:10 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA26604; Sun, 20 May 2001 06:00:09 -0400 Received: from fwd01.sul.t-online.de by mailout02.sul.t-online.com with smtp id 151Q0O-0006Ia-02; Sun, 20 May 2001 12:00:08 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.50]) by fwd01.sul.t-online.com with esmtp id 151Q0c-2KP9NIC; Sun, 20 May 2001 12:00:22 +0200 To: XEmacs Patches Cc: XEmacs Beta List Subject: [PATCH] Properly make mouse-track-click-hook local in compile.el From: Adrian.Aichner@t-online.de (Adrian Aichner) Date: 20 May 2001 11:59:47 +0200 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net I would like to commit this later today, now that Ben has fixed mouse.el for 21.5. In 21.1 mouse-track-insert between buffers will not work. My workaround to make the hook global in compile.el is not the correct solution for this problem. 21.1 mouse.el should be synced with 21.5 instead. Best regards, Adrian packages Patch (cvs -f -z3 diff -u xemacs-packages/xemacs-base): ? xemacs-packages/xemacs-base/bindist-1.err cvs server: Diffing xemacs-packages/xemacs-base Index: xemacs-packages/xemacs-base/compile.el =================================================================== RCS file: /usr/CVSroot/XEmacs/packages/xemacs-packages/xemacs-base/compile.el,v retrieving revision 1.22 diff -u -r1.22 compile.el --- xemacs-packages/xemacs-base/compile.el 2001/05/14 09:38:04 1.22 +++ xemacs-packages/xemacs-base/compile.el 2001/05/20 09:51:43 @@ -949,8 +949,8 @@ ;; XEmacs change: highlight lines, install menubar. (require 'mode-motion) (setq mode-motion-hook 'compilation-mode-motion-hook) - (add-hook 'mouse-track-click-hook 'compile-mouse-maybe-goto-error) - ) + (make-local-hook 'mouse-track-click-hook) + (add-hook 'mouse-track-click-hook 'compile-mouse-maybe-goto-error t t)) ;;;###autoload (defvar compilation-shell-minor-mode nil cvs server: Diffing xemacs-packages/xemacs-base/etc -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From Dr.Volker.Zell@oracle.com Sun May 20 09:39:16 2001 Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA00655; Sun, 20 May 2001 09:39:15 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4KDZav24109; Sun, 20 May 2001 06:35:36 -0700 (PDT) Received: from vzell.de.oracle.com (shivapppd16.de.oracle.com [140.84.22.207]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4KDcbj07088; Sun, 20 May 2001 06:38:40 -0700 (PDT) X-Mailer: 21.4 (patch 3) "Academic Rigor" XEmacs Lucid (via feedmail 8 I) To: Steve Youngs Cc: xemacs-beta@xemacs.org, warner@lothar.com Subject: Re: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems References: X-Face: I-*}xvwusAv%MlABo'jVNP7TDXf5bb*L[q,r{DnsR1GoL07^Wf)sAu%>!LjXAFlZZN+`OQu }?#du]C)[*%ERKR#+l#sX'EoNbSO~|.x@ogoS5|"-u? Date: 20 May 2001 15:39:12 +0200 In-Reply-To: Message-ID: Lines: 52 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Volker" == Volker Zell writes: Volker> Hi Volker> I think there is a bug in the regular expression in mc-gpg.el Volker> which is used in mailcrypt-3.5.5 together with gnupg-1.0.5. Volker> This is what Brian Warner gets whith his version of gpg: Volker> ;31:warner@zs2-pc4% gpg --list-secret-keys --with-colons --no-greeting Volker> ;/home/warner/.gnupg/secring.gpg Volker> ;------------------------------- Volker> ;sec::1024:17:1FE9CBFDC63B6750:1998-08-04:0:::Brian Warner (temporary GPG key) : Volker> ;ssb::1024:20:C68E8DE9F759FBDE:1998-08-04:0::: Volker> ;sec::768:17:16BD446D567E33CF:1998-08-04:0:::signature (sample signature key) : Volker> ;sec::768:16:D514CB72B37D9AF4:1998-08-04:0:::crypt (crypt) : Volker> ;sec::1024:17:4DBDD3258230A3E0:1998-08-04:0:::dummyy : Volker> ;ssb::1024:20:549B0E6CBBBB43D1:1998-08-04:0::: Volker> And this is his regexp for matching: Volker> (key-regexp Volker> "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):$" Volker> ) Volker> I'm using gpg-1.05 compiled under cygwin (passing all tests) with (see subject) and I get: Volker> [712]> gpg --list-secret-keys --no-greeting --batch --with-colons Volker> /users/vzell/.gnupg/secring.gpg Volker> ------------------------------- Volker> sec:u:1024:17:0A8F8157EBCFE3E8:2001-05-18::::Dr. Volker Zell (Ciko) ::: Volker> ssb::1024:16:2179761C5E488513:2001-05-18::::::: Volker> vzell@VZELL /tmp Volker> [713]> gpg --list-secret-keys --no-greeting --batch --with-colons "Dr. Volker Zell (Ciko) " Volker> sec:u:1024:17:0A8F8157EBCFE3E8:2001-05-18::::Dr. Volker Zell (Ciko) ::scESC: Volker> ssb::1024:16:2179761C5E488513:2001-05-18::::::e: Volker> As you can see I get two more : at the end of each line. Therefore I have to use the following Volker> regexp. But then everything works. At least for me. Volker> (key-regexp Volker> "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\)[^:]*:[^:]*:[^:]*:$" Volker> ) Ooops, that shoud be: "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:$" Ciao Volker From Adrian.Aichner@t-online.de Sun May 20 13:55:15 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA09912 for ; Sun, 20 May 2001 13:55:13 -0400 Received: from fwd00.sul.t-online.de by mailout02.sul.t-online.com with smtp id 151XQ9-0007XJ-01; Sun, 20 May 2001 19:55:13 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.45.7]) by fwd00.sul.t-online.com with esmtp id 151XQ2-1SxKzYC; Sun, 20 May 2001 19:55:06 +0200 To: xemacs-beta@xemacs.org Subject: Re: [Success, 1% lisp-tests fail] XEmacs 21.5-b0 "alfalfa", i586-pc-win32 References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 548 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "APA" == Adrian Aichner writes: >>>>> "APA" == Adrian Aichner writes: APA> Here are the offenders, as tested with APA> M-x test-emacs-test-file RET lisp-tests.el: APA> Testing Interpreted Lisp APA> FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02") APA> FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02") APA> FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06") APA> FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06") APA> FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02") APA> FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02") APA> FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06") APA> FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06") APA> These test fails because my system prints 3 digits for the exponent: APA> (format "%e" 100) APA> "1.000000e+002" MSDN actually documents that exponents are always printed with three digits. What's the preferable way to fix these tests? 1. (cond ((equal system-type 'windows-nt) (Assert (string= (format "%e" 100) "1.000000e+002"))) (t (Assert (string= (format "%e" 100) "1.000000e+02")))) 2. (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100) 0)) 3. Any better ideas? Adrian APA> (format "%E" 100) APA> "1.000000E+002" APA> (format "%g" 1e-006) APA> "1e-006" APA> (format "%G" 1e-006) APA> "1E-006" APA> (format "%#e" 100) APA> "1.000000e+002" APA> (format "%#E" 100) APA> "1.000000E+002" APA> (format "%#g" 1e-006) APA> "1.00000e-006" APA> (format "%#G" 1e-006) APA> "1.00000E-006" APA> Testing Compiled Lisp APA> FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02") APA> FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02") APA> FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06") APA> FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06") APA> FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02") APA> FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02") APA> FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06") APA> FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06") APA> SUMMARY: APA> 3588 passes APA> 16 assertion failures APA> 0 errors that should have been generated, but weren't APA> 0 wrong-error failures APA> 0 missing-message failures APA> 0 other failures >>> XEmacs Build Report generated by emacs-version >>> 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>> with system-configuration >>> i386-pc-win32 >>> follows: >>> Contents of c:/Hacking/xemacs/xemacs-21.2/Installation: >>> (Output from most recent run of ./configure) APA> OS: Windows_NT APA> XEmacs 21.5-b0 \"alfalfa\" configured for `i586-pc-win32'. APA> Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-21.2\\nt\". APA> Using compiler \"cl -nologo -W3 -Od -Zi -MDd\". APA> Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b0\". APA> Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". APA> Compiling in support for Microsoft Windows native GUI. APA> -------------------------------------------------------------------- APA> WARNING: Compiling without GTK support. APA> WARNING: As of xemacs-21.2-b44 APA> WARNING: gtk-xemacs is not supported on MSWindows (mingw or msvc). APA> WARNING: Yes, we know that gtk has been ported to native MSWindows APA> WARNING: but XEmacs is not yet ready to use that port. APA> -------------------------------------------------------------------- APA> Compiling in support for XPM images. APA> Compiling in support for GIF images. APA> Compiling in support for PNG images. APA> Compiling in support for TIFF images. APA> Compiling in support for JPEG images. APA> Compiling in support for X-Face message headers. APA> Compiling in support for toolbars. APA> Compiling in support for dialogs. APA> Compiling in support for widgets. APA> Compiling in support for native sounds. APA> Compiling in fast dired implementation. APA> Using minimal tagbits. APA> Using indexed lrecord implementation. APA> Using portable dumper. APA> Using system malloc. APA> Using DLL version of C runtime library APA> Compiling in extra debug checks. XEmacs will be slow! >>> Contents of c:\Hacking\xemacs\xemacs-21.2\nt\xemacs-21.2-make-install.err >>> keeping lines matching >>> "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( APA> \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" >>> and then deleting lines matching >>> "confl.*with.*auto-inlining\|^Formatting:" APA> cd c:\Hacking\xemacs\xemacs-21.2\nt\ APA> nmake /f xemacs.mak INSTALL_DIR="c:\Program Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)" JPEG_DIR="c:\Hacking\libs4xemacs\jpeg-6b" MAKEINFO="c:\Hacking\texinfo-4.0\makeinfo\makeinfo.exe" PNG_DIR="c:\Hacking\libs4xemacs\libpng-1.0.2" TIFF_DIR="c:\Hacking\libs4xemacs\tiff-v3.4" USE_PORTABLE_DUMPER="1" XPM_DIR="c:\Hacking\libs4xemacs\xpm-3.4k" ZLIB_DIR="c:\Hacking\libs4xemacs\zlib" install APA> Compilation started at Fri Apr 27 13:55:35 2001 APA> WARNING: Compiling without dependency information. APA> Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b0\". APA> WARNING: Compiling without GTK support. APA> WARNING: As of xemacs-21.2-b44 APA> WARNING: gtk-xemacs is not supported on MSWindows (mingw or msvc). APA> WARNING: Yes, we know that gtk has been ported to native MSWindows APA> WARNING: but XEmacs is not yet ready to use that port. APA> 1 file(s) copied. APA> 1 file(s) copied. APA> 1 file(s) copied. APA> c:\Hacking\xemacs\xemacs-21.2\nt\..\nt\minitar.c(28) : warning C4716: 'Usage' : must return a value APA> c:\Hacking\xemacs\xemacs-21.2\nt\..\src\dumper.c(993) : warning C4090: 'function' : different 'const' qualifiers APA> c:\Hacking\xemacs\xemacs-21.2\nt\..\src\dumper.c(993) : warning C4022: 'dump_add_opaque' : pointer mismatch for actual parameter 1 APA> WARNING: Compiling without dependency information. APA> Using load-path (c:\Hacking\xemacs\xemacs-21.2\lisp) APA> Using module-load-path (c:\Hacking\xemacs\xemacs-21.2\modules) APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\code-cmds.el: APA> ** the function coding-system-category is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\coding.el: APA> ** The following functions are not known to be defined: APA> set-console-tty-input-coding-system, APA> set-console-tty-output-coding-system APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\toolbar-items.el: APA> ** The following functions are not known to be defined: APA> pending-delete-pre-hook, x-init-specifier-from-resources APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\dragdrop.el: APA> ** The following functions are not known to be defined: APA> mime/viewer-mode, gtk-start-drag-internal APA> While compiling make-dialog-box in file c:\Hacking\xemacs\xemacs-21.2\lisp\dialog.el: APA> ** variable cl-title bound but not referenced APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\scrollbar.el: APA> ** the function x-init-scrollbar-from-resources is not known to be defined. APA> While compiling mouse-consolidated-yank in file c:\Hacking\xemacs\xemacs-21.2\lisp\mouse.el: APA> ** reference to free variable gpm-minor-mode APA> While compiling the end of the data: APA> ** the function x-store-cutbuffer is not known to be defined. APA> While compiling find-space-insertable-point in file c:\Hacking\xemacs\xemacs-21.2\lisp\fill.el: APA> ** reference to free variable space-insertable APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> kinsoku-process-extend, kinsoku-process APA> While compiling isearch-help-or-delete-char in file c:\Hacking\xemacs\xemacs-21.2\lisp\isearch-mode.el: APA> ** reference to free variable tty-erase-char APA> While compiling the end of the data: APA> ** the function x-keysym-on-keyboard-sans-modifiers-p is not known to be defined. APA> While compiling read-library-internal in file c:\Hacking\xemacs\xemacs-21.2\lisp\lib-complete.el: APA> ** reference to free variable read-library-internal-search-path APA> While compiling read-library-name: APA> ** variable read-library-internal-search-path bound but not referenced APA> While compiling set-visited-file-name in file c:\Hacking\xemacs\xemacs-21.2\lisp\files.el: APA> ** reference to free variable vc-mode APA> While compiling save-some-buffers-1: APA> ** assignment to free variable view-exit-action APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> vc-after-save, dired-get-filename, dired-expunge-deletions, APA> ange-ftp-ftp-path APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\help.el: APA> ** the function compiled-function-annotation is not known to be defined. APA> While compiling command-line-early in file c:\Hacking\xemacs\xemacs-21.2\lisp\startup.el: APA> ** init-file-user is an obsolete variable; use load-user-init-file-p instead. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\modeline.el: APA> ** the function vc-toggle-read-only is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\minibuf.el: APA> ** The following functions are not known to be defined: APA> ange-ftp-ftp-path, user-name-all-completions, APA> user-name-completion-1, tty-color-list APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\simple.el: APA> ** The following functions are not known to be defined: APA> x-keysym-on-keyboard-sans-modifiers-p, kinsoku-process APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\frame.el: APA> ** the function console-tty-controlling-process is not known to be defined. APA> While compiling set-face-stipple in file c:\Hacking\xemacs\xemacs-21.2\lisp\faces.el: APA> ** reference to free variable x-bitmap-file-path APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> x-init-face-from-resources, x-init-device-faces, APA> gtk-init-device-faces, x-init-frame-faces, gtk-init-frame-faces, APA> x-init-global-faces, gtk-init-global-faces APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\console.el: APA> ** the function console-tty-controlling-process is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\syntax.el: APA> ** The following functions are not known to be defined: APA> charset-name, char-charset APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\custom.el: APA> ** the function custom-theme-reset-internal-face is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\cl-extra.el: APA> ** The following functions are not known to be defined: APA> overlay-lists, overlay-start, overlay-end, overlays-at, APA> next-overlay-change APA> Using load-path (c:\Hacking\xemacs\xemacs-21.2\lisp) APA> Using module-load-path (c:\Hacking\xemacs\xemacs-21.2\modules) APA> Note: Strange doc (not fboundp) for function user-name-completion-1 @ 616405 APA> Note: Strange doc (not fboundp) for function user-name-all-completions @ 616729 APA> While compiling toplevel forms in file c:\Hacking\xemacs\xemacs-21.2\lisp\apropos.el: APA> ** reference to free variable font-lock-keyword-face APA> ** reference to free variable font-lock-string-face APA> ** reference to free variable font-lock-comment-face APA> ** reference to free variable font-lock-variable-name-face APA> While compiling popup-builtin-open-dialog in file c:\Hacking\xemacs\xemacs-21.2\lisp\dialog-gtk.el: APA> ** variable filename bound but not referenced APA> While compiling popup-builtin-color-dialog: APA> ** variable initial-color bound but not referenced APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> gtk-signal-connect, gtk-main-quit, gtk-window-set-transient-for, APA> gtk-widget-show-all, gtk-main, gtk-color-selection-dialog-new, APA> gtk-color-selection-dialog-ok-button, gtk-widget-hide-all, APA> gtk-color-selection-get-color, APA> gtk-color-selection-dialog-colorsel, APA> gtk-color-selection-dialog-cancel-button, gtk-widget-show-now, APA> gtk-widget-grab-focus, gtk-widget-destroy, gtk-dialog-new, APA> gtk-window-set-title, gtk-container-set-border-width, APA> gtk-box-set-spacing, gtk-dialog-vbox, gtk-container-add, APA> gtk-label-new, gtk-button-new-with-label, APA> gtk-widget-set-sensitive, gtk-widget-show, gtk-dialog-action-area APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\font-lock.el: APA> ** The following functions are not known to be defined: APA> fast-lock-after-fontify-buffer, lazy-lock-after-fontify-buffer APA> While compiling toplevel forms in file c:\Hacking\xemacs\xemacs-21.2\lisp\font.el: APA> ** reference to free variable global-face-data APA> While compiling font-properties-from-style: APA> ** variable style bound but not referenced APA> While compiling toplevel forms: APA> ** reference to free variable x-font-regexp APA> ** variable weight bound but not referenced APA> ** variable slant bound but not referenced APA> While compiling x-font-create-object: APA> ** reference to free variable x-font-regexp-foundry-and-family APA> ** variable style bound but not referenced APA> While compiling x-font-create-name: APA> ** variable style bound but not referenced APA> While compiling ns-font-create-name: APA> ** variable registry bound but not referenced APA> ** variable encoding bound but not referenced APA> While compiling mswindows-font-create-name: APA> ** variable style bound but not referenced APA> While compiling font-update-device-fonts: APA> ** variable font bound but not referenced APA> While compiling font-update-one-face: APA> ** variable font bound but not referenced APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> x-list-fonts, mswindows-list-fonts, ns-list-fonts, internal-facep, APA> fontsetp, get-font-info, get-fontset-info, APA> mswindows-define-rgb-color, cancel-function-timers APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gdk.el: APA> ** The following functions are not known to be defined: APA> gtk-import-function-internal, gtk-call-function APA> While compiling build-ui::radio-group in file c:\Hacking\xemacs\xemacs-21.2\lisp\generic-widgets.el: APA> ** variable build-ui::radio-group bound but not referenced APA> While compiling build-ui::button: APA> ** reference to free variable plist APA> ** reference to free variable build-ui::radio-group APA> ** assignment to free variable build-ui::radio-group APA> ** variable label bound but not referenced APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> gtk-label-new, gtk-widget-show-all, gtk-signal-connect, APA> gtk-window-new, gtk-container-add, gtk-vbox-new, gtk-hbox-new, APA> gtk-box-pack-start, gtk-notebook-new, APA> gtk-notebook-set-homogeneous-tabs, gtk-notebook-set-scrollable, APA> gtk-notebook-set-show-tabs, gtk-notebook-set-tab-pos, APA> gtk-notebook-append-page, gtk-text-new, gtk-text-set-editable, APA> gtk-text-set-word-wrap, gtk-text-set-line-wrap, APA> gtk-widget-set-style, gtk-text-insert, gtk-label-set-line-wrap, APA> gtk-label-set-justify, gtk-radio-button-new, APA> gtk-radio-button-group, gtk-check-button-new, APA> gtk-toggle-button-new, gtk-button-new, gtk-progress-bar-new, APA> gtk-progress-bar-set-orientation, gtk-progress-bar-set-bar-style APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\glade.el: APA> ** The following functions are not known to be defined: APA> gtk-import-function-internal, gtk-call-function APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gnome-widgets.el: APA> ** The following functions are not known to be defined: APA> gtk-import-function-internal, gtk-call-function, APA> gtk-button-new-with-label APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gnome.el: APA> ** The following functions are not known to be defined: APA> gtk-type-from-name, gtk-call-function, APA> gtk-import-function-internal APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gpm.el: APA> ** The following functions are not known to be defined: APA> gpm-enable, console-tty-terminal-type APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-extra.el: APA> ** The following functions are not known to be defined: APA> gtk-import-function-internal, gtk-call-function APA> While compiling gtk-choose-font in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-faces.el: APA> ** variable locale bound but not referenced APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> gtk-init-pointers, gtk-font-selection-dialog-new, APA> gtk-widget-set-sensitive, gtk-font-selection-dialog-apply-button, APA> gtk-signal-connect, gtk-main-quit, APA> gtk-font-selection-dialog-ok-button, APA> gtk-font-selection-dialog-get-font-name, gtk-widget-destroy, APA> font-menu-set-font, gtk-font-selection-dialog-cancel-button, APA> gtk-widget-show-all, gtk-main APA> While compiling gtk-file-dialog-fill-file-list in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-file-dialog.el: APA> ** variable remotep bound but not referenced APA> While compiling gtk-file-dialog-fill-directory-list: APA> ** variable remotep bound but not referenced APA> ** variable selected-dir bound but not referenced APA> While compiling gtk-file-dialog-new: APA> ** variable item bound but not referenced APA> ** variable initializing-gtk-file-dialog bound but not referenced APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> gtk-clist-clear, gtk-clist-freeze, gtk-clist-append, APA> gtk-clist-thaw, gtk-combo-set-popdown-strings, gtk-dialog-new, APA> gtk-dialog-vbox, gtk-dialog-action-area, gtk-window-set-title, APA> gtk-button-new-with-label, gtk-container-add, gtk-signal-connect, APA> gtk-entry-get-text, gtk-widget-destroy, gtk-combo-new, APA> gtk-combo-disable-activate, gtk-box-pack-start, gtk-combo-entry, APA> gtk-hbox-new, gtk-clist-new-with-titles, gtk-scrolled-window-new, APA> gtk-widget-set-usize, gtk-clist-get-text, gtk-entry-set-text, APA> gtk-button-clicked, gtk-option-menu-new, gtk-menu-new, APA> gtk-label-new, gtk-menu-item-new-with-label, gtk-menu-append, APA> gtk-widget-show, gtk-option-menu-set-menu, gtk-box-pack-end, APA> gtk-entry-new, gtk-widget-set-sensitive, gtk-widget-realize APA> While compiling gtk-reset-device-font-menus in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-font-menu.el: APA> ** reference to free variable gtk-font-regexp APA> ** reference to free variable gtk-font-regexp-foundry-and-family APA> ** reference to free variable gtk-font-regexp-spacing APA> While compiling the end of the data: APA> ** the function charset-registry is not known to be defined. APA> While compiling gtk-init-handle-geometry in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-init.el: APA> ** assignment to free variable gtk-initial-geometry APA> While compiling init-gtk-win: APA> ** assignment to free variable gtk-initial-argv-list APA> ** assignment to free variable gtk-initial-geometry APA> While compiling the end of the data: APA> ** the function gtk-keysym-on-keyboard-p is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-package.el: APA> ** The following functions are not known to be defined: APA> gtk-window-new, gtk-hbox-new, gtk-container-add, APA> gtk-widget-show-all APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-password-dialog.el: APA> ** The following functions are not known to be defined: APA> gtk-dialog-new, gtk-dialog-vbox, gtk-dialog-action-area, APA> gtk-window-set-title, gtk-button-new-with-label, APA> gtk-container-add, gtk-signal-connect, gtk-entry-get-text, APA> gtk-widget-destroy, gtk-container-set-border-width, gtk-label-new, APA> gtk-misc-set-alignment, gtk-entry-new, gtk-widget-set-sensitive, APA> gtk-entry-set-text, gtk-entry-select-region APA> While compiling import-widget-accessors in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-widget-accessors.el: APA> ** variable c-mode-common-hook bound but not referenced APA> ** variable c-mode-hook bound but not referenced APA> While compiling the end of the data: APA> ** the function gtk-fundamental-type is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk-widgets.el: APA> ** The following functions are not known to be defined: APA> gtk-import-function-internal, gtk-call-function, APA> gtk-import-variable-internal, gtk-ctree-recurse APA> While compiling gtk-describe-enumerations in file c:\Hacking\xemacs\xemacs-21.2\lisp\gtk.el: APA> ** reference to free variable gtk-enumeration-info APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> gtk-import-function-internal, gtk-call-function, gtk-type-name APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\ldap.el: APA> ** The following functions are not known to be defined: ldapp, APA> ldap-open, ldap-close, ldap-add, ldap-modify, ldap-delete APA> While compiling lm-report-bug in file c:\Hacking\xemacs\xemacs-21.2\lisp\lisp-mnt.el: APA> ** reference to free variable report-emacs-bug-beta-address APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\msw-font-menu.el: APA> ** the function charset-registry is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\multicast.el: APA> ** the function open-multicast-group-internal is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\mwheel.el: APA> ** The following functions are not known to be defined: APA> event-basic-type, posn-window, event-start, mwheel-event-window, APA> mwheel-event-button APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\package-get.el: APA> ** the function mc-pgp-verify-region is not known to be defined. APA> While compiling load-sound-file in file c:\Hacking\xemacs\xemacs-21.2\lisp\sound.el: APA> ** assignment to free variable file APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\symbols.el: APA> ** the function set-magic-variable-handler is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\tty-init.el: APA> ** The following functions are not known to be defined: APA> register-tty-color, init-mule-tty-win APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\wid-browse.el: APA> ** the function pp-to-string is not known to be defined. APA> While compiling gtk-widget-instantiate-internal in file c:\Hacking\xemacs\xemacs-21.2\lisp\widgets-gtk.el: APA> ** assignment to free variable x APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> gtk-button-new-with-label, gtk-signal-connect, APA> gtk-radio-button-new-with-label, gtk-radio-button-group, APA> gtk-toggle-button-set-active, gtk-check-button-new-with-label, APA> gtk-widget-show-all, gtk-notebook-new, gtk-notebook-append-page, APA> gtk-vbox-new, gtk-label-new, gtk-adjustment-new, APA> gtk-progress-bar-new-with-adjustment, gtk-adjustment-set-value, APA> gtk-entry-new, gtk-entry-set-text, gtk-widget-set-style, APA> gtk-widget-get-style APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-faces.el: APA> ** The following functions are not known to be defined: APA> x-get-resource-and-maybe-bogosity-check, x-get-resource, APA> x-init-pointer-shape APA> While compiling x-reset-device-font-menus in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-font-menu.el: APA> ** reference to free variable x-font-regexp APA> ** reference to free variable x-font-regexp-foundry-and-family APA> ** reference to free variable x-font-regexp-spacing APA> While compiling the end of the data: APA> ** the function charset-registry is not known to be defined. APA> While compiling init-x-win in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-init.el: APA> ** assignment to free variable x-initial-argv-list APA> ** reference to free variable x-initial-argv-list APA> While compiling the end of the data: APA> ** The following functions are not known to be defined: APA> x-keysym-on-keyboard-p, x-server-vendor, APA> x-init-specifier-from-resources, init-mule-x-win APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-misc.el: APA> ** the function x-get-resource is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-mouse.el: APA> ** The following functions are not known to be defined: APA> x-store-cutbuffer, x-get-resource APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-scrollbar.el: APA> ** The following functions are not known to be defined: APA> x-init-specifier-from-resources, x-get-resource APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-select.el: APA> ** The following functions are not known to be defined: APA> x-get-cutbuffer-internal, x-rotate-cutbuffers-internal, APA> x-store-cutbuffer-internal APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-win-sun.el: APA> ** the function x-keysym-on-keyboard-sans-modifiers-p is not known to be defined. APA> While compiling the end of the data in file c:\Hacking\xemacs\xemacs-21.2\lisp\x-win-xfree86.el: APA> ** The following functions are not known to be defined: APA> x-keysym-on-keyboard-p, x-keysym-on-keyboard-sans-modifiers-p APA> Installing in c:\Program Files\XEmacs\XEmacs-21.5-b0 ... APA> 1 File(s) copied APA> 1 File(s) copied APA> 10 File(s) copied APA> 1 file(s) copied. APA> 1 file(s) copied. APA> 1 file(s) copied. APA> 401 File(s) copied APA> 132 File(s) copied APA> 466 File(s) copied APA> 1 File(s) copied APA> 1 File(s) copied APA> 1 File(s) copied APA> Compilation finished at Fri Apr 27 14:09:13 >>> Contents of c:\Hacking\xemacs\xemacs-21.2\nt\xemacs-21.2-make-check-temacs.err >>> keeping lines matching >>> "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( APA> \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" >>> and then deleting lines matching >>> "confl.*with.*auto-inlining\|^Formatting:" APA> cd c:\Hacking\xemacs\xemacs-21.2\nt\ APA> nmake /f xemacs.mak INSTALL_DIR="c:\Program Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)" HAVE_XPM="1" HAVE_PNG="1" HAVE_TIFF="1" HAVE_JPEG="1" HAVE_XFACE="1" DEBUG_XEMACS="1" USE_PORTABLE_DUMPER="1" GUNG_HO="1" MAKEINFO="c:\Hacking\texinfo-4.0\makeinfo\makeinfo.exe" ZLIB_DIR="c:\Hacking\libs4xemacs\zlib" XPM_DIR="c:\Hacking\libs4xemacs\xpm-3.4k" TIFF_DIR="c:\Hacking\libs4xemacs\tiff-v3.4" PNG_DIR="c:\Hacking\libs4xemacs\libpng-1.0.2" JPEG_DIR="c:\Hacking\libs4xemacs\jpeg-6b" COMPFACE_DIR="c:\Hacking\libs4xemacs\compface" check-temacs APA> Compilation started at Fri Apr 27 16:35:52 2001 APA> WARNING: Compiling without dependency information. APA> Using load-path (c:\Hacking\xemacs\xemacs-21.2\lisp) APA> Using module-load-path (c:\Hacking\xemacs\xemacs-21.2\modules) APA> Note: Strange doc (not fboundp) for function user-name-completion-1 @ 616405 APA> Note: Strange doc (not fboundp) for function user-name-all-completions @ 616729 APA> base64-tests.el: 1232 of 1232 (100%) tests successful. APA> byte-compiler-tests.el: 104 of 104 (100%) tests successful. APA> c-tests.el: 2 of 2 (100%) tests successful. APA> case-tests.el: 1118 of 1118 (100%) tests successful. APA> ccl-tests.el: No tests run APA> database-tests.el: No tests run APA> extent-tests.el: 194 of 194 (100%) tests successful. APA> hash-table-tests.el: 9866 of 9866 (100%) tests successful. APA> lisp-tests.el: 3588 of 3604 (99%) tests successful. APA> md5-tests.el: 56 of 56 (100%) tests successful. APA> mule-tests.el: 2 of 2 (100%) tests successful. APA> regexp-tests.el: 118 of 118 (100%) tests successful. APA> symbol-tests.el: 264 of 264 (100%) tests successful. APA> syntax-tests.el: 64 of 64 (100%) tests successful. APA> Compilation finished at Fri Apr 27 16:37:07 >>> Contents of c:\Hacking\xemacs\xemacs-21.2\nt\xemacs-21.2-make-check.err >>> keeping lines matching >>> "^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\( APA> \s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+" >>> and then deleting lines matching >>> "confl.*with.*auto-inlining\|^Formatting:" APA> cd c:\Hacking\xemacs\xemacs-21.2\nt\ APA> nmake /f xemacs.mak INSTALL_DIR="c:\Program Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)" HAVE_XPM="1" HAVE_PNG="1" HAVE_TIFF="1" HAVE_JPEG="1" HAVE_XFACE="1" DEBUG_XEMACS="1" USE_PORTABLE_DUMPER="1" GUNG_HO="1" MAKEINFO="c:\Hacking\texinfo-4.0\makeinfo\makeinfo.exe" ZLIB_DIR="c:\Hacking\libs4xemacs\zlib" XPM_DIR="c:\Hacking\libs4xemacs\xpm-3.4k" TIFF_DIR="c:\Hacking\libs4xemacs\tiff-v3.4" PNG_DIR="c:\Hacking\libs4xemacs\libpng-1.0.2" JPEG_DIR="c:\Hacking\libs4xemacs\jpeg-6b" COMPFACE_DIR="c:\Hacking\libs4xemacs\compface" check APA> Compilation started at Fri Apr 27 16:37:28 2001 APA> WARNING: Compiling without dependency information. APA> base64-tests.el: 1232 of 1232 (100%) tests successful. APA> byte-compiler-tests.el: 104 of 104 (100%) tests successful. APA> c-tests.el: 2 of 2 (100%) tests successful. APA> case-tests.el: 1118 of 1118 (100%) tests successful. APA> ccl-tests.el: No tests run APA> database-tests.el: No tests run APA> extent-tests.el: 194 of 194 (100%) tests successful. APA> hash-table-tests.el: 9866 of 9866 (100%) tests successful. APA> lisp-tests.el: 3588 of 3604 (99%) tests successful. APA> md5-tests.el: 56 of 56 (100%) tests successful. APA> mule-tests.el: 2 of 2 (100%) tests successful. APA> regexp-tests.el: 118 of 118 (100%) tests successful. APA> symbol-tests.el: 264 of 264 (100%) tests successful. APA> syntax-tests.el: 64 of 64 (100%) tests successful. APA> Compilation finished at Fri Apr 27 16:38:20 APA> -- APA> Adrian Aichner APA> mailto:adrian@xemacs.org APA> http://www.xemacs.org/ APA> -- APA> Adrian Aichner APA> mailto:adrian@xemacs.org APA> http://www.xemacs.org/ -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From warner@luther.lothar.com Sun May 20 14:41:16 2001 Received: from luther.lothar.com (adsl-64-164-209-218.dsl.snfc21.pacbell.net [64.164.209.218]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id OAA11793 for ; Sun, 20 May 2001 14:41:15 -0400 Received: (qmail 7731 invoked by uid 1000); 20 May 2001 18:41:03 -0000 Date: 20 May 2001 18:41:03 -0000 Message-ID: <20010520184103.7730.qmail@luther.lothar.com> From: Brian Warner To: Dr.Volker.Zell@oracle.com CC: youngs@xemacs.org, xemacs-beta@xemacs.org In-reply-to: (Dr.Volker.Zell@oracle.com) Subject: Re: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems References: User-Agent: EMIKO/1.13.9 (Euglena tripteris) FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by EMIKO 1.13.9 - "Euglena tripteris") Content-Type: text/plain; charset=US-ASCII > Volker> I think there is a bug in the regular expression in mc-gpg.el > Volker> which is used in mailcrypt-3.5.5 together with gnupg-1.0.5. > Ooops, that shoud be: > > "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:$" Actually I went for a conservative route and removed that last field and '$' altogether. We don't really need those fields for mailcrypt (the new ones are "Signature class" and "Key capabilities") yet, so it is safer to ignore them. The benefit is that is new fields are added in the future, the expression should continue to work. I've checked in this change to the mailcrypt CVS repository (http://mailcrypt.sourceforge.net has a pointer) and will be releasing mailcrypt-3.5.6 just as soon as I can figure out Len's release procedure (in particular I don't know how to upload anything to sunsite.. any pointers would be appreciated). The Debian folks already made a mailcrypt package revision from the CVS repository.. you're more than welcome to do the same. thanks, -Brian Index: mc-gpg.el =================================================================== RCS file: /cvsroot/mailcrypt/mailcrypt/mc-gpg.el,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- mc-gpg.el 1999/10/07 05:23:46 1.14 +++ mc-gpg.el 2001/05/06 22:55:26 1.15 @@ -3,7 +3,7 @@ ;; Patrick LoPresti ;; 1998 Brian Warner -;; $Id: mc-gpg.el,v 1.14 1999/10/07 05:23:46 budney Exp $ +;; $Id: mc-gpg.el,v 1.15 2001/05/06 22:55:26 warner Exp $ ;;{{{ Licensing ;; This file is intended to be used with GNU Emacs. @@ -319,7 +319,7 @@ (if (string= str "***** CONVENTIONAL *****") nil (let ((result (cdr-safe (assoc str mc-gpg-key-cache))) (key-regexp - "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):$" + "^\\(sec\\|pub\\):[^:]*:[^:]*:[^:]*:\\([^:]*\\):[^:]*:[^:]*:[^:]*:[^:]*:\\([^:]*\\):" ) (obuf (current-buffer)) buffer) From Adrian.Aichner@t-online.de Sun May 20 16:10:48 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA15208 for ; Sun, 20 May 2001 16:10:47 -0400 Received: from fwd00.sul.t-online.de by mailout02.sul.t-online.com with smtp id 151ZXH-00057k-0D; Sun, 20 May 2001 22:10:43 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.45.7]) by fwd00.sul.t-online.com with esmtp id 151ZXH-0rzdOiC; Sun, 20 May 2001 22:10:43 +0200 To: garrett@cs.colostate.edu Cc: XEmacs Beta List Subject: [comp.emacs.xemacs] Re: xemacs 21.4.3 will not configure unde suse linux 7.1 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 69 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Sender: 520002458184-0001@t-dialin.net --=-=-= Hello Deon, please report problems about Beta and Gamma versions of XEmacs to xemacs-beta@xemacs.org. I have copied the list now. Best regards, Adrian --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Path: news.t-online.com!newsmm00.sul.t-online.com!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed.news.qwest.net!news.uswest.net.POSTED!garrett From: garrett@cs.colostate.edu (Deon Garrett) Newsgroups: comp.emacs.xemacs Subject: Re: xemacs 21.4.3 will not configure unde suse linux 7.1 References: <9e5hvk$1607j$1@ID-65805.news.dfncis.de> Reply-To: garrett@cs.colostate.edu Message-ID: User-Agent: slrn/0.9.5.7 (UNIX) Lines: 34 Date: Sun, 20 May 2001 20:00:23 GMT NNTP-Posting-Host: 63.228.81.79 X-Trace: news.uswest.net 990388823 63.228.81.79 (Sun, 20 May 2001 15:00:23 CDT) NNTP-Posting-Date: Sun, 20 May 2001 15:00:23 CDT Xref: news.t-online.com comp.emacs.xemacs:53750 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I had the same problem on a Mandrake system. Check the output of ./configure for some lines like: Checking for MS-Windows... Checking for main in -lgdi32... Using MS-Windows Apparently, the libgdi32.so file that WINE installed was enough to convince configure that I'm running windows. I just renamed the libgdi32.so file temporarily and everything worked fine. -- Deon Garrett On 19 May 2001 19:53:30 +0200, Norbert Koch wrote: >"Denny Reeh" writes: > >Hi! > >> ./configure i686-pc-linux-gnu >> not finished, because of an error: >> >> *** PANIC *** The C compiler can no longer build working executables. >[...] >> What shall i do?? > >Have you tried (g)make distclean and run configure again? This helped >me out of this situation. > >norbert. >-- >Are we on STRIKE yet? --=-=-= -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-115 D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com --=-=-=-- From dave@arsdigita.com Sun May 20 16:41:59 2001 Received: from washington.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA16477 for ; Sun, 20 May 2001 16:41:57 -0400 Received: (from dave@localhost) by washington.arsdigita.de (8.9.3/8.9.3/Debian 8.9.3-21) id WAA22987; Sun, 20 May 2001 22:41:56 +0200 Date: Sun, 20 May 2001 22:41:56 +0200 From: Drazen Kacar To: xemacs-beta@xemacs.org Subject: XEmacs-GTK doesn't show scrollbar Message-ID: <20010520224156.A22841@washington> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Face: 'UIE}WabGB0+U>p-#(hp<_+AD2{H],=qR*jHfm$/e]l0(kU3oOYc5lqG6gg>[\h^IOc{'siD6#!T&loIShgmYHz3#+*D38:|`~\BE,(W~Ol9BDfDwk'lKJ;Z{sY8E9(ME.E]'wvNO`$n#,;9Z`tOFcW/nHZq!BOSrM>V?C<5DTw=<${c{M2V+|)0jSUl&!+8%8nIBF(u:E>SZWM^e X-Attribution: Dave --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Solaris 8 1/01 with recent patches, Sun's 6.1 compiler, GTK+ 1.2.10, XEmacs 21.4.3. XEmacs configured like this: CC=cc CFLAGS=-g ./configure --site-prefixes=/usr/local --site-runtime-libraries=/usr/local/lib --dynamic=yes --with-gtk --with-dragndrop --with-database=berkdb,gnudbm --with-ldap --infodir=/usr/local/info --infopath=/usr/local/info --with-mule XEmacs 21.4.3 "Academic Rigor" configured for `sparc-sun-solaris2.8'. Compilation / Installation: Source code location: /home/dave/work/xemacs-21.4.3 Installation prefix: /usr/local Additional prefixes: /usr/local Runtime library search path: /usr/local/lib Operating system description file: `s/sol2.h' Machine description file: `m/sparc.h' Compiler: cc -g Relocating allocator for buffers: yes GNU version of malloc: yes Window System: Using GTK menubars. Using GTK scrollbars. Using GTK dialog boxes. Using GTK native widgets. Compiling in support for Drag'n'Drop (EXPERIMENTAL). - Drag'n'Drop prototype: GTK. TTY: Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for GNU DBM. Compiling in support for LDAP. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Problems: 1. There are some C++ comments in the source. Attached patch takes care of that. 2. Linking temacs fails because compiler invocation lacks -lX11. 3. Does it really have to use Imlib? 4. When XEmacs is run, a place for scrollbar is reserved, but the scrollbar is not shown. Buffer tabs are also not shown. There is only an empty gray area instead. Screenshot attached. It uses GTKStep theme, but the same thing happens with default theme, as well. -- .-. .-. Sarcasm is just one more service we offer. (_ \ / _) | dave@arsdigita.com | --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xemacs.patch" --- src/glyphs-gtk.c.orig Sun May 20 21:56:51 2001 +++ src/glyphs-gtk.c Sun May 20 21:57:22 2001 @@ -1576,6 +1576,8 @@ type = resource_symbol_to_type (resource_type); +#if 0 + // if (dest_mask & IMAGE_POINTER_MASK && type == IMAGE_POINTER_MASK) // iitype = IMAGE_POINTER; // else if (dest_mask & IMAGE_COLOR_PIXMAP_MASK) @@ -1583,6 +1585,8 @@ // else // incompatible_image_types (instantiator, dest_mask, // IMAGE_COLOR_PIXMAP_MASK | IMAGE_POINTER_MASK); + +#endif /* mess with the keyword info we were provided with */ gtk_initialize_pixmap_image_instance (ii, 1, type); --XsQoSWH+UP9D9v3l Content-Type: image/png Content-Disposition: attachment; filename="xemacs-bug.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAy8AAAIhCAMAAABwjnXGAAABMlBMVEUAAAAAAIsJCQsTFUwW GiUjJ4goKCktNUs2Osw4ODhAMDhCSdBDMztHNz9ISElIVXhKOkJOPkZRQUlSVtdUVFRVRU1Y SFBYWFlcTFRfT1diZttjU1tmVl5oaGlqWmJrW2NsaGhtXWVvX2dwdN9xYWlyYmp0ZGx2Zm54 aHB4eHl5aXF7a3N9bXV/b3eAcHiCcnqEdHyGiuuHd3+IiImLe4OOfoaQgIiSgoqVhY2YmJmY nOqZiZGalJScjJSgkJijk5umqvWnl5+oqKioqKmqmqKyIiK2uvm5ubm7q7O+vr6/r7e/v7/C srrGtr7HyM/JucHLxcbNAADNvcXQwMjUxMzWxs7Xx8/Z2dvby9Peztbi0trl1d3l4OHp2eHs 3OTw4Ojz4+v35+/66vL8/Pz+7vb////xq+EdAABlGUlEQVR42u29i4PjOJMfhla726uMLdu3 X6J4HCV7mYtj2edHH8+5cLxJJstsM18mYTYPh3lsnmf+//9C8EYVUABBiWpJ3fWbaYkigcKD 9SMKQAEU/4bAvxb/hsH40KA58K/F//dfpfjn5FkG4+Pgn2eY8f/+lyn+KXmWwfg4+KcZZvw/ /0WKf0KeZTA+Dv5Jhhn/93+e4h+RZxmMj4N/lGHG//WfpfiH5FkG4+PgH2aY8X/+K4XJQ/36 M3uWcXlM9mtyH2kIGER9hhtVJ5txAv7MM+Nfge8/E//Hf6oQ+KJ+/ak9y7g0XJWbL1P7aRj4 LT/pYFnZjFPwp4EZ4OtPxf/+VwqBL+rXv2/PMpbD1OGkvv/KVOdEf/ng+sv8n/4KhJncmRA2 /P1VVRrTtWvjfuE5YO/FZM/+b/9SYfqXFvrg37NnGYsxTfrPfoHD9IIJr2vcX5wKQdXR5EKH SIU0wm1lLEXggGlH3Nn/9S8Vpr+00Af/wJ5lLMY06T/7pf/+0p/RR9NsLFqGC6dlTMvTYCwC 4MAUKvQfiP/lLxSmv7DQB3/fnmUshtFl+fUX4M+dcSFmYuGvEFMH+wt/YmEajEUAHJhCdf59 8T//C4XpX1jog3/XnmUsxjT5L/sHvlyQiYw0TWkM9xcLXZ4GYxkCB8zDzJ39n/6ZwvTPLPTB v2PPMhZjmvSf/QKH6QUcSX1OJkAIOrlDGMrFnU2DcQY8B+w9mOzZ//HPFaY/t9AH/7Y9y1gO pfTqE/5Nf67/qx/hC8XxMaMwMKwL9efmgTefBuMMOA5M/uaYs//9P1YI48nq15/YswzGR8Wf eGb8Y/D9J+K/+49T/D3yLIPxcfD3Msz4b/+jFH+XPMtgfBz83Qwz/pv/MMXfJs8yGB8HfzvD jP/6P0jxt8izDMbHwd/KMOM/+bcI0GcZjI+DDDMYDEY9/tohHDEYDBKSL79YhCMGg0FC8cXw 5A/MFwajjD/o9uUPijLMFwZjBn9w9tgfmC8Mxhz+wPYYg1ENtscYjHqQ9pgdaFZH+n8WIoS0 J7LhxXyQbBLZa7MZE8uiubgnxKLST8+6D8aNQUTf6Q8D0h6r0X9aoA0vCkEX8cUoVy58Wc4J NPslo9NiLhadBCFlmRjGW2ERX2J7bC5S/prIxxHz4upKUZe1E/lCp7hYyUVWCvPlJrGML79E 9hiMYe5yhY2iwpjwpCEEVAiIDDokZuQLE8OJtqkV7LXQorkQIjRXc7aaCCnawAJJEPBSVkxo l1ytODs3yCmbnIy3AeZLUBQRqX6dPZazR0R0LMRsWIH/inyJ6Og/otQyz2ys+rlkcykKkFic 6V9AdZbkCHyIy4qKw83OlYH4AhUlUmfaHov6+6Q1DgLix+gvmbuP1CUJPkfHQvQyX3BQWKJZ vvhTgkq1KCd0+Am+ENGZL9eFyKhyrPpV9lieL/HhSXwRvqHIi89GL4yRERkLSRbj/FLNl7Ic VPtZvjBXro/EGCnxZc4ey47NLuJLpGhWpLERT+ZLQd1KfMlFW8qXOTmC5gsofLEIjLcC4gvS TXh1dnwMRiqk8styvoCz5t+M/CxfsupW5ksmGvmcKfGFljPDl6R8zJgrI73vv1zbHstoXA1f kLZdsv+ylC9z/aASX7j/ckNY1R7LciB+/osiX/xTFIssRIDzlfgDpraEbFDzRTZFN1ZMxMwp PJl2EJAwPn0GMK4IqCxIUSLtrLLHfsnOv8CeTZh/yVr18JEvYvZkCuLFRx+XmX/BGQMxUaYB 0TPzL7heRMSOSA7Pv1wdiC9z8y/6gP0tY7ASM2IdYH/+PJgvDJIv7M9PgvnCoPnyC9tjBJgv DLbHGIzTwfYYg1EPtscYjHpovvzBIBwxGAwSV9yIlsG4Q/xStW0sB+JAvMP2X4tJ/FLTbanq 23AgDvTOYfjyfQ6qb8OBbjyQtBUun9xvHxp/+IB8SbXq+nmqC1TMuGTLRDIGSYqN8cV5urbG 3hhf0pq8pB7QiZ0gKSeIkCR+/3295IpqZ06nuUpaBSrzRMbLksRPP6n/lRn/yf4T2eQyVXBt jb01vkwWc3dvqUaRN0aQiaFAJAvS5DKCiDz9rv8jqdnSQXEwT4p0AD+V+RI3DBFfvBiU+aV8 URQQgAAzt4X5sjZffi7cPXfJVrf9Qjfm55+BTqlfpEYpC0ImKbIapUXP2+WCzHWkUT//7DNl jvO6adOWYbyOxhwG+J2UJELmK/nys8gFColmS6ebF6qBKT/Gfs5WAd16Xltjb5cvubunDeXw rer8dL64ZiHzwMeEdMlTfNECpqJG/WzU3+rJHF90EA0jEnBYK6e9plR0hi/Cfc/xpdzmzbYv 2h4r8yXcX4nff1d1ktS4g7ov5g9m/Noae7N8ydw9XY+Tq0+jeBV8Efn2xab3nQrkG7KgNN5u odqXKdxcki8IJb4EtvycJicCXxRhaL74tkWYH7m+NTLtTufLd926/DTTGYR0UXz5Hrcvjif6 4aP/qQ/LKuZLni9Y9QBfJsAorHinty9aGiXJty/uG1j5afuyGl9MOqYRIlpPyBdJmAxfrH57 vnxPnwYZZDg8Oz72kzMOs33Peb78UTHE/Pn/jjDMl+V8cSHAA/gMvkBDOjzK0/6LQN9FPTif L0IAC4konbXHXL7p/os3JB1fgr4HvkwksnxJkIy0/S50rtEIIFFPhg8pX4Skyx+pXAnmy7l8 MfoN+wGL+QJNES2IYB7iysxzkxiYXc4XgToU5NPAtC/C9/Nm+OIzlPJFxMrpOoe5/n6RL6A2 c31PSxZdVQRf/qj5gls73cjoBob5cg5fvD12Kl/woKwUSLZUIWcl492YDemocsqXdIgbUwHo XDbjqH35OdPfT1HRvigaknwR83zRU0u/y/i/l9sXa2aJBe2LIQzz5QS+2DonntML+ZIObf58 bvsSlK7AlylhFcwTZAscp8iMj5kxaiktyxeRHJ7El9n+vul0/a5bENTA5Nph2h4zDYz5J+yn a2CYL2fxxbYv9GAqepDTfPn996iBofoKS/ovxKhyiS9pnmw337Ila9ZE7YuU9dNPOb6kdIn5 AgdwC/bYPF90hifDl99z9eTqR1D9fd28/NEabJOvU2ORMV9O48t3M2Di2CJyfKE7C0W+JP39 +vEx2L5MeMog5ouIWQX54tuWaL49Oz6mUvuJrKeIL2k9Levvz7cvwrcvpeeKIwxpj8EezCRC YObLuXyJyLIGX86dfyFGlQvtSwjlB1NdTlK2QEkTsMc0W37K918ozwS6fTmbL5X9F9+8UOPJ oYEBOfI9fubLOXwpz56dYI+Jn1K+1M7vkzr3Pd++zPGl4Lmp4lm+WLbk+/siZC/Ll7XaFzzc mOOLqyiRm6+EDczkG2LBfDmZL9/1pMOMo5JxFdFTzrX9feoxXek/lmT+lPbFdfbF71SCTtIU +KLpUhwfA3SnvH1C+7IKX8TvbqI13774B4vIzVe6Bsb9Nz4YzJdz+DLvADnPl8hmA3RZ7p+M tUGcxpdpcp39UnI/2UbFNi4//yzyfPHNC53xVdsXYeZ6fp+Z3wctMcUXOERmmxbbh+H+y8l8 yWApXxBhIF1OXW6zqL8PWOX5Yh73M8kZwgjbuGT9YYADzNvwxfpbzviP+Z58ji+miQGDyc5L kPlSXC+WHbutU2CxlC/lxR9r8CXp5JB8mU/uJxf9J+tvmRkiFOnR5fhSuf5lmoSf2SX5ot2q /+gnXixXfub5fZov1bo5GyjunVCBSG6ellykf6ImEMGXmuTET4guuYYxFCrLlwzIjBPVdML6 F8hLmi/fI544fGe+vLf1++fzpS45YU2ylOqF9iXbGazz5597rtSuf4nwM7Ve7OcEIdC1NZb5 sl6gueYs1RgUaKpP7icwR1mR8Typ1rOA7fqXmTyVqPA9DZVKurbGMl/uMtBPP60laa1Apvcy x5fvNF3qk7u2xt4rX0R6fLIeJLP4WUkrDAoskFTZpxIzGS8NWOUEZVuqgiTMFlG4LTNGW6ky r62xt8WXmrmOdJiGujGVkujbmCzgShg1I4kKFKsTFQh3NPJ8QbJSvuSTokr3nXhixFSgRZHJ xZHQ8AKdI1xPZAAX6Noae1N8MVUlwpJzchTYqoiwiiJIBxVzg4yYnB4IK8gmmet1gASzGxx9 d0vkhUAp4kBhyxY9u5dKQhXgVxPnSie81FiB/X+BUv1ODX0J4ZZhigJffA2lVYBLD1I1l5Az Hs5WqHP0XAkFEGjnAeYLzZfAh+8ZKjg1zweym2+Bas/xJQjJtC/iOxCV5UtQ3UyeBCgfzlTC F0JQWjpQTSRfBBCCPpP2JVws8OV7kiPIlzg74DDiSxTge8qX5B9M7toae7N8EbN8+V4I9B3J yM7oYS24MF/CozfK1GK+xNVE2mOh9L41M0mSfIkErcQXQfBF1PEFPA65fangy/fv3+f5kg30 Pbp7pB4IrOUlvqSCUnsMShJ0IFgwSjeX8+U7EoXbl6QNEjlJ9LN8AV/iRgWIS9oXbGsRfPnu jFX/xXwh+QL7Efn2JVi/31G3I206/D0rdQNm+RIylOMLDIEnBxO+oO4ZEQhY74X+S1RNmf6L +B76LyJsRpZpX7yWFvlC7VEL68c3K75piPv7oQoAGTKdwe9JFVxbY2+LL0GxMG5/QgRlXqwh aS6QqAgkqiStHUjUS6KedcXkrq2xN8GXitf2cSAOVBfoXUPxRTAYjDpIvjDOxcT4MBBli+3a qshg3BSYLwxGPZgvDEY9mC8MRj2YLwxGPZgvDEY9mC8MRj2YLwxGPZgvDEY9mC8MRj2YLwxG PZgvDEY9mC8MRj2YLwxGPZgvDEY9mC8MRj2YLwxGPZgvDEY9mC8MRj2YLwxGPZgvDEY9mC8M Rj2YLwxGPcT5WzIxGO8XjifMFwZjHswXBqMezBcGox7MFwajHswXBqMezBcGox7MFwajHswX BqMezBcGox7MFwajHvfFlzH6xodT/iwd6rTEl6bNeEe4L75UI9LZcdCf4wDPq59jOKGuDUuE TkyNj4d75MtIti8j/BqxLvdR4BGLcXEAe0YoaiKSq0+c8Y5wX3xRCi3bhHGAp7SWj/Z7cBcH oPy+3RiBnHAxiEBiB5fa6H6HsCBqSNyHnXrmyzvFffFFwT75x0FiDD/Dl/7us3ElBksm86Gg g+sPK3ccTfsDG47RhB2UAAmfok/UfZfNOsYd4/74ohDZYyO2sPSjfsjEs70UxBfT3vQTarYA X7zcYcTtC80X1LQx3hXuiy+j1UrQeli+2N66MYs8K5L47gpoX5ywYYJxPF9G3VaNNomekqcF DmHEYJyYMO8Vd8UX+zgfQOuhlHlQWjz0utMw6i9lLPWJSSav9eqs/NY9DBtFhlQKLz9G3+9Q v3rDkn7wJ8JPA5VwbxIfzW/1ox91aMZ7xF3xhcG4Mj4IX97CPhpPvvgGRWQDcR28I76M6U84 nzLrE1ASXBdjLJxYluYp6j0WTzFhVsFd82XM/xyJEJV6P04n8wMRlJrbrJI7Vp0izkYVcGL6 zKwC7povU0KIMXNtnLKXZmSSsjJi8/o75mXUFKv2WjbkovSZMHncM1/GBU2BC14b2rvIZH1c 6tsLkNkluQWx6PQXlX9p+gwS98yXiXLYythIpa5FSbQ5gnoZc2isSj/IqU0V+q+NkZQxCbJW +owy7povo9eeMRsATL+3rZvvDAQYuxB6iNzM7PS//6Q4511xSFZiLo0+x2XVHYmjKcMEnPA6 6TPyuGu+TMgNJa9e49SZ+UQiGJxYHAIrgh9Mq466SPGgp0xG94huTo09OMYxfPMGbLMRixwz ZFqc/iL79kPijvmC9Mefg/c83HrdimivANlSqNn4cbCrX/rJroqRrYt2lLGtjIvba+nWuxI8 qaH2Jd2czOMeNUjlRhE/CNBniJ12rtZIn1HAHfPF3Hv79EWa7I/8WRPKeK2MQy/p07fyXy85 0vWDakK6YWh7fbEfYHxrr3U42WAHRZ1uOv0oZLWy0gPEuPc0XjB9Row75UvG8hrx49M/gntz udc/h7ZtVW9GnTWOZJINw2SDdW03QEqYOLaZAQ/06Ec5fX891tic1uKeUbyyDfhzYiGrpc/I 4E75kiIZNIIne/Oj1xrUme5MY/lirtsv4ywJ4rulX/2C9JOcwIGuWFMpmwkdU+YZEXO19Bkl 3DlfxswxOKstFsOU3pBGcWX0fGn1ckg1TtZ12u4aei9ttD390UTFne4penpnev24zzClsXOj BSNUb3jWS5gZPjsnfQaNO+ZLzX12CtaqlqKRkLZW27RjMzWN7LJMzSj/NVqZ5DVJmKFRp2BP W/dcOjASbZdZOsymP6JD3FXHfKe66baPErofY+izZMfmTkqfiVOBO+aLgbnJrw7f0JfFYJc8 jkMIpv7pYIPTExRFX/pm5GBhGi8aX1++fv2G8mEP4755MIliW3GcYkNqDEyIBha8nif9kjXT Z5Rw33zx9/f1hx9++PRDFl9s2OEzedGozOsPJ6FzGj2SWUO97wmq7IjarAlZWyjyCC2zqAM/ BSEnpY85yZjDffPFPx+Hsk4/7axGUHx52htRMzJyojda40CvHAz04h7DmDzmiYbCkcN/R+FG RzTEH5i+ywMmUC79dNyAUcC988U9P7885TX66elxZ5Xk2w9JOHnRdggKMvJ43KPZSvsdjQGj 7WhAoKC/YAhrRNfjf6HnPqLrIf0R0aaY/uiNMrbJ6nD3fHHKsds+PlJkedxstrtd457EzW63 A4bb05O83Dgd3O2eN0+EWSdlaDw+PiWUejyOrjdO7cKE2GGOQt99nGAz4HUaDAeP8Xm/CQcM A3v/UZNRTB9fYKpU4P75Mvkb3x9/TDV9141gQEsHfAGXn492TzH/jP6aWlyPx15t1zd0TStp iSmzaZ1ob4mN4OHuM5haSCHniU02BcoBtoxRK4CnMQNnR9B0lNIHjQszpRLvgi8G6sZ/Sayl vh+GflAbwwx2N8rBM2KzOfQGg97CT+tUMiawee6NABvyuHuCZOr6Tp6FjYx9hKOH/ZjOySMb C5lkrvVJmoG0CYlHvGDPCc7ekOkjQ44pU4O75QvuMdhzw2vUwmz2bds0rUHXa8K8fnaqvmnk xcZe662Sv0Z8edrIICpQo/7r0E0w6eTVo5LRj2FyA3UpRkiYcYzznY7won4PbEjGMRlSG+Oq cFQY4xGIXPpglIwpU4G75YsHVL2he8HK/rhXOEgcj1KpVSPy+s1p+vNOXdof1PWjZpNSn5gv j1LGwcgAcIR5fN4rKccubF0WTCk/ToUf7fHIMOyQ48Fi31bAaRfcdo1JdYxp+lMu/RGlxZjF /fMFMmZoo97H4/Pz9nm73e72jhKuCZKti76mr6rL+73ej2+Mp2E2VoT80MRR2O0+f3Im3bPE 9tD0A+5pgPFgP0kSxoltUK+w2gM0KswU9V7giBkImVpyk2+I3AhEPn3GMrwHvjhIMnQtbh0k KzbPm2fFF9u+vH5xnfjt80b/e37e7Q7HvVlS1sd8edIjY1rGVjdEB0Wt3e6L44u6ut0f97tD 6POPvRR42DvqTPu9/DvATno8JBDWC0StARpuA72XkdD3aOQZMYZIlLv5y/F++KLUZ0gMMq3O Sp8b2boourw4Y2y/2268tksStGogreuG2KKzQ8mqdWlUI9U0yoDbv3wKbJLCGuW3qUcTlNem VP+xU17QY9/pzf5309h4De6GzqxKG7teZ703/tGD+WmY0OtNa9XqNnl2VNI6MGoddW0mcORb o2DOjSgWbIcYC/Fu+GK1Y3hN+bKRhGjNIJYdG3uSpw6yfbFsUj32g1LWsTu+fiH5oknVSbr0 vWyqJHWaL+Gqtsdao8Fd1xl/TUWb8di27VHl67gPHYnu2B/6dpBX+15enI5dd5D2mJTdHL32 NzJi3yimqKDDUZbg2PtiEuMGkx9cGKGlBoaXx2LtIXGMDO6bLyP+oZQiGg5+NOrcmhHf12+2 Vdg1Q2MII62xZ9XytEadu2SEzeK5aRtps0nKSQ40+9Y0ZI5MMoHWPMZbySmtmp2mSde1B9U+ HNWkaK9sucM07cHSm87sLdBISnSd5NHYKKNPNyedXkxwlC2fkSYDxe1J4IsbF4CdFP8LNDDE 0DEgCxNmBvfLFzySFPrC2J7SHZjdsdUOyq+vppe+2Y1Sv/db0y05HBWZOvNg7snui2HEsVeT m73iQDuYlmrzaK4eu0HZY1LDpQ1l1LpTBJFhO2XnNX0HeiiHSa+0MSsFlO0mbTQX1hVMmmOt ypQRq7+mJoxswcmbMGCMHc9AQ4Taj5GsS6ZKDe6XLxZgVNb8+5a0D5IvuhfhW5fncWyPzU73 9SUPdDehNar3je6+PO+PutdxlKH2vdo5Q48LSLvu2SWgWoBWNwFHnSfVNox7Y0Kp0eZ9mDKx fBkUD6QwKVQZYoceLqeRUWQLIzOqDiV9ZIB2CJOik++IwLnNaBIT9u0znXvXDQqTPYwS7p4v cBBo0nbJj7HCK3VWQ8XfbOuykXrXHyRXNrJx2e1kt2Bs9rJLIh/kh7j7Yq2xrezQH1s1yDWq wE3v+LLfmquNnufpp2G/71olSf5UmWoOqtdxkEaYGi4znJS/ZJdEnhoOinuyvdn3jez0SFOu d2o9HJrpMMoOTLvfDzJUJ3tAA5yBCWPCo++nuNkW0LigSZYwWkDUoDtklPAO+OIf29aExxr/ ZI0pN/HytHmUj+6hO+630hY7tp3TMju7/ymO7c0xb/sYnVN8edwdd2r6RRIIDESFsSs4ETOB Ma2kBHDIKzlv7DVIjgn+B4Ne4ziCsiQGGcWJdC6IUcA98wX2fMM0+JgaZNu97O/befvNo3qP WNfst9vt3kwzQk2PInu+qMYlJKb+qf7L5ijlqOlK1UlBj3anxIgfY8yYAcxojqnShrnOfrvv wMkRvHjQNSTOlgP+AGPUooRqcifAFCj3YWpwt3wBJrz56fViwE3Eo54eeXV02aghrq457LZm lNl7E+v/r5nuy05PdvonuP7+8vTDpmsPki/SpOvHEWsf7nZ7xY+m573PyjRCZQ7jxWCpgNd6 T48RNDXBA3sErRAYYIYu1LAa/bQQs6UCd8oXaJKDO26UIjXIdp1vXQJdpDHWO91zihs7j4Hu i3Zgfv36+duri7F/fpR2nSJe0/sxWzSsO/k1BGhNZHiWh6UAcE4Fa3Rggzeo3GwKmFcJgwDe 9NMLFbCzTMhdSD88euZ272DcK18I+AdkvIJF6vuL4cGT6erb1uXQdGCDcaO1udFkQ61Rd29U Z99p6dA3h+3u0A5wAxe1p+zrODi56tfr168vXwfU/zC7b6gtMyJTDE29a7Ey4LeXl5dvkH1S 6gD3fg7NjeHWYHbl+Pr1Fa3Th7MzaisPtWfHqxP7Ko+vfRtvHO+HL2FkdYxtqib0XULrouji VdM1CF9pvqjxYj0ircy1DZhJGftmv1PTO05Ph8Eo6udPL25bWUkK22p9GYJ1pYa3v3xy56P5 Ejj6K+W92PifvqpLmmVSz18+f3kZUVNl0tME+/bihP/w48trKGbglEz+xxDCNJ7yuKuq6w+L 98QXb/PjEeWnLey76NZlp+iiFpCFmLopyIwmP1tzbFDNy9MGptm3h728GnZZ+vzZpv54MC3Q 69fQn/rUh4G4bzCtr6GbAR28dCPwAvpjP+Iu1u6AbTvzIxDU4Qsc0hjT5H/49Pnlm84oKh0j wTviS7A3olbCaphvXfZbQ5dotz3VfSGdYZ71+Joycb5o+sE4sgNzOLRfLUngSMNGL4R+jXpE g+0sIRZINKHPA4ekhzjcboR5fDzYjIPekCRosixb8gzaY1OSfHi47K59E28b74ovk21kol6I pctG06WFxtjYuGFa7ctV6L4oPdf2im43xuG40zP3o+zAHJv+JVW8x2etvN+wXn56Up43UqeT GM2+R1ORmjCv36KG4tMPLczjRmWi3zeg/KHhUFt9+IWgn8C4gvfStoE2YKOQx/217+Bt433x xQ3NEtuMPW7UYjHZPd8rY0z33yf9MiRjNenn+2u82syPJuulAGYuc6PcYSSMM5e079qu/5qm tzno1iV+jD8dh+MwvKYZfNyqjDe77SGMS78Ctinuqu/PgGlPGzN80Pryg4bjcbOVhQzECEPW YzARHze7VtqZjW+RHpsR9Z4YGO+LL26G70uqjpu97K907dH0XcziY7Ovsjo46tiZ0eTnbdON vfc+k21N33Xd0Q4Rq80wXvfJZk6bbmhfv6VWz3PXN69Ee/R00Aai9mMb1YxqP8JgG5n/vpXl +gzy+Kg8q2UvrDGWVteBdkvvjDOADtlWPS9kproxODE8bRo1RNG1vZO6aeXv3s3iMmK8B75E k20jsbWrfNg2Usfb4367k3Rp9WYxk17XpZskbdEc49bA8WXX9r7b/bhtd10rjbDD4AycQY2S 7Q+IBE+bvqPo8sOmaSm6yI5DpydPWyO07VpMF9nGyWR/xF2k3WGvqNvorOzab4Hwki7NcQ9z 8KhmVWVfqwV0lU2Qfojsj0e3vlqy/9i0yv4c7OQN0wbgPfBFIUxrqB/RFL/aZ2wntcAaY03n 9z/qbDS1+qUfKGeY7W7fdK+hD/0ozalDczxovoQRXPmcRiR9fG6/aWV92jyiVmuzN1afFI4y +fR8UEtAR9u+HI7AOJRhj8fn9ng8RpxU+WiaVmdFNgyBLmqFT9Ns4Xjf01Y1bTJgFx4Lm07t kHM87PZ7t+5UEvV4bNTCgsHVLCPgzvkSpvjCuJL6nS6C2clnqOnqHw1ddLjOdnjUU72NlyK/ 6J35X15evgCNl3ZWp1bwH49gjlK73SO+bHZf9UCWtAO7bygrXzWNpH01dF/Qhe3+0HaqWyQz 06ARgcfN4XCQbcl2h3IoZe/U5jSNXgnQwV6RKu5Bcg4ncGzVxoNdIOKmPx73e1Uru8Z6ox7U GUlds4fhxH6YGHfOlwDgZiL/p1P8av39bmeNMb/Zpeopj6Z5GMfXdBw2wdNmUK76knXHAYxm TS1eCf0km5HPmqiy24Qu7HUqGzX6gNbaPKqVnoe2b3QXBnVxnjbPqg3YPj9im08t31Gxjpov cORait9KixE1R09q9cIBJ7tpdspfVMrYH77Ydkl18PZNO7pXqjFbIO6dL5EjmbOQXlOfS70n kjKuetDf0XxR41LqYVrzQovH7e5ZWXXPajGAn1RXk/xfsfYbV4DNbtvj9sWeb4dodlQvnNZP +t1ODSSDAmx2R7WXzfNm02C+mO0H5KNgu0P7pimrqpH02mO+qI2hdn0HJjMfVexHtSJhezSD 5ZutOiUbmLHvY29qxv3zBRHGuwyOqc+l3ihMWildDzdTblpLsKObXpmB2hJTd4LaPngD6+QH mKS0ugxdmg7Ptbx81blRqzob1J7ZiVHjuTlAvj9umoNaZbN5fH6BXSE/2n1QfnBodGDb6vZo +4ITUJt2ILPtByVWSZAdFmM+6iZru2t6JgmJu+eLwQi+9XFqkOltlYxbfvBu7NvBe8CnO8M8 PsY78qvNYZUFI3W0H0GKkWvz005pn3ak6XokVxFBml4HNdr1Lc6hWwmK9tiUpt1+Z3bm2H6j +KI4ML5+gzHUOOCzbDgO0SNjozcW/IzPqt1t1Li0yqZuxbQ7NvOFxDvhiwFwJEkNMqkKe+jB PwG/eM2Y3M4wj2Bu5elRa6J2wAQb8Y+Rb4C2uiTf1LLMHsr98kXnZZvw6MnzpR/RxItUYZWi aR1QqSxdlHMbbpBkx36v9hWQ7cRnHFoF7iAZP/ntDUY9RrI5qF0NlP8P84XEe+ALWuFhf70S +1z6bZVCcLjHMe0MozcvA9slq2630VHkgz+iIblvX+26G0lQ1H15MXJVQ4d3bvIbmSm+wM6L 7IGbjdKUFr8S+dOrCdDA8Ub1r9TeNzL5H5F8ww30XDCNoPY8VVGPe7WtwaEdmC8k3gNfJtSL MQ7t39KpR2O4wEhgRZfsM9BLK7V137htZqXWqhbHL9gPayihxn56/cGug1a0AHJ//GT7EYem /ZqaY3bnp2gcwNJFXosG1JyzjuySfEMX9rY9UsbX/km9X83voqb4ggq61e4+5sGhdlkz60U7 5guNO+ULaFLcCbjnY+qg9bixeuEX6PoljzZexhlG71B2OLjpPL/9hfcYsYkSVpcaH+5aZP74 SdDjsUvHusxGZmjc4cn0KIyw/kuaP01dPHIgW0A/eCBztt9uAV8ku/C0rF5O7VZC6PWiuhfF fCFxp3wh4a2j19Sf0W2r5NeUTXClr45E7gyjetm73W5//BxZNcGsS7svL26fQDX7/pqK1ZsE EuaYbSzwheew5ezr5zR/yshEDHu0DNPGoDY/1eYegS/Jjup6Mw83CKK2MVS9K+YLjXvnS7J4 d6JaF/04Nm753od5DGNb2hihd4bRe/tLHMF2ybq7Prh1krbBglbXj+bpr1xvjl/xSN2jta32 zbfktGksoubFXzn2aO9N2CEhGaYzqRa5Ke+2LWBd4o76bBsi3cAoj1Tu7mdx73wJNlnYXIWi i91WyTjCqL1aQSOjTw30PuO6O9w0h/YlcEh2iJve79xiSBpZXY9GYw/HI17HaIfBttvdt3R0 bKPHmal2x4xVICYBAwtPHG2C/aY9dsahbw873wdSj4yogflkzmro9XR2+1xGirvmS3JPtX7Y DvYuWpWsO/yml34YrBU2WCnj1OZ8+ZUDTdc13yxfzPav5gEM1nbF+/zZAa3DocEXjP4/Pj8f 0HnQL4qUH/RShley+9L2iZ+Aadwa6yan1pTud/q1Ts5Ei54Nn/wGN6M0yJS75bD0VnwU3C9f RvJwcnR5fCa2VTrofZSng9aMVs3tK68P+TQdjpmllRu91UXT6EElPfut+eI9NqdB7czfDl+J 2M+SL9gcc1KfnxuKFsq4Qs3LE2xeRjzpHwbUsGO0jxGMrL5ttPOcdugkZqd+0OLtpjV927rV QYwE98sXD7RphafLpkvfBGPn4Xq9IZJsNtQ+x2rfYtm7faF3hlEKqV52cTCzebvtVk/n7Z1T jdoN+SitNWx1/eDMtv0BX3DK/IzNMbCvxisxyuymSL4SkpQ59kKKOujei12ho5z07RvWdF1F pf20NTuyT3YBHNMlhzvmC1gCGL48XVrK53KvR8iMU/Jxd1AOk9qTfxqzr0kyVo2ZtNi0+71+ W+VeKVejXCOPUyebl2gw2kXe7I+U2aXm/dF50Ca8kjxS49ekOaa66ihtYNl1frdZvS1O15k3 rJmqil2x7YjfCAYMGQTumC8Jwop3RZfESvfzJvrVFapRUWvVlVEm/zI7wzzbnn076imVfm+m 846DcwqQAjp5Fbdlj87q2uP3z4be+1fqvDbHPlHhjYsYmvUPREJphy06unHwLgiaMWrlctiz P7LIng9NB/eGZdC4a77AReZmJNmtsT8quyL1uTT7ug6KMEf1zgjVzKiOTHZnmN3ODDK109dP ameYo9n+9Ti8Dm7uRsbuxhcqsuwvfaNspc1zZnRsf/xGdmu0HTmQ5tgx6joBJ8wxjBnaRW1h 99m0C/OsXuDJTJnDXfNFA7jChNftqcXn7UvyJhjtzy67HDLwsNu36qUrw37X77qsM4x8gsvW Ra1jPOzUOLB6mfLzdvft5dMXa+1Lk2z3SvVSNsocQ4PDQctJM02NjpF9Ee2fQptjR7r7YobO /aIgv2dmcIOIlqD+8LRze+YwCngPfHF6MQS6qGGe44EYIdNTC70bDZ5cG5UbTbZ+lSbgpKfK 1RoandLeOZHEy9NCs9CRvfft7is9Oib5Qo2OmUnGb+kVY459TmWZkUC1hfMY6sgeuIHw2Fx9 3Ps+PyOL++fL5JTCv+FlpzYIU8u60neLWxdlv3Os0x16ZxgzjAuX6avtkq1jytPG7CiuolNz 9ZvYHAODw6+Z0bGeHhrWTpikr+Uxx5fGrzdI3jHmT0dvxvV+yow83gFfrEvK4Pbgf7YzDrvt kTDItJNIWPhi4pb2GQe6ZnaTtVaT2WDPeENT6q/SIn3EpDKT53OTlWb3ZmLpi6bFSHb3tYeL W9wAxrucfWZ8X3D1bKxHAKOAO+eLX93ofSz1+8PUrsZq24Zkmxj94A3vIHLeY5nui9ZH55mp Q/bN8XA03aTHxr86iXrEa5uIsKEe1RoX0kxTNhTRHqlR5mgwGfsmp3yxk5XgjTGurl7VXv3+ tRZ40cOG/fjnced8mfwjFL0/THlMSbocklfzWcMevAnM7FZPL61UmorGZNXu/sdvOvST2hdW v48o3nksNAuvhPqrtTPEqNnOTD0Sw2ba6Bpo9xm1GpPii5pNGWyX6xUMEivD8YtbxTBFj4mw DI6Rxf3zxaiF1bRH8/6wVu3VtT+20Sjxo1+a7veqMIe5fcYPZldyv1eTIoydH3x6NL6Manya HNRS5tXn5Pxjct54LL++HCKHfTQ0/BptPKYpttPNH8mXpu/tagVp4n01taRKoMTsXflHbEg+ maaM+VLCe+BL8LF83LR2U3H9dso+mrV/9F0S17aYr9gcC0/23r9Syb000tt9B8WeXk2Zv2Ym U3Dv3fFlH01K6tNq3mWPt27xPv5qiOJbOgD3+Pry0sTOxs5xzbYTdmOmHyfXDGsvBb8GAi/7 fwJLhBgZvAu+TIgupnXZHZXOJCNkfsgLdHynjC+/X6UfFmKGPVfVhnt92yiXLLpXf2ioIa1H 5fOSdF+0e4zaaTblizS6mlfFyB9xFL1j049D/Hpbm3HnPmny9rhz87mqoI+uvz9ii8y/ef3a d/OW8R74AnwsTeuy28nWpemHZNo+kAC4SuV2hlHKA9+zCkcV9Ksk1KvK1BJ5qveuJ1M+E+fj SUm9EFPx4UltjU/wZWemJL/gKBs95fm4H6NhYT9ho+0vw27l7jCFVTpPreu2jWgg/clacsyX At4BXxxdnpSJpN5fpN8fZlxxh3QRzM5u2Re2qsgtrdxpvhhNU68zUq+F9BvF7OzgcrJcKzOZ Es53yXoVPX252Q0kX5TP8if30id/wW43qzxGkwVpz25/F1szm61rT8yDYaffX2PXu7wgsbrL du0besu4L74Qj74wk6cmXtS0vurqm/eHyX9Jy2ENsrA7THZppZt9saTq1Kskg6BW2n17zcuq yRQwOtbH7Y7eyF/bkmM6arw9aLp8/oLS2OohNkMEPHfkujy6dXkxwW053djA89B3nX3FC5h5 8k0TNzB53BdfLIIjin65qdPIoet790Ik2a+QQbrXtCdvfC7VouS+HTUhYnMMLKZX3aHOWG6v 8L2Qap/LVvsqH+jlWsqK+kKdjwlm6SIbR8VilF29mZ6Z7XmCHHvcbM2M6UZ7SOIOzCe7y4zv ailf7Un508kmxWa17drWLLSEFiuY6WTkcId8UeNS8quTjckA9rZ4UtuattoY2zet/Cfve5e8 WfLZbec4jce2OXbHMXkLn+9oq7e8TlK3lNt/9BbVx+fj9rjTO8zmzbHMjDwm2GfDh81zp/dN Rhn5/EV19fVleOHHF0uXg3nBK24ef5Q1II0qaTvaN1Q0ekZKr36xWVXb/auhaDSUHrpLbJDl cZd8UZ/q7VdDB1+IuuvVXuB2D/7jXi1wGZNXeX3aPqrRgP2+mXq1cEW9sy5eOxUcV+Tzu1Gm nbTEYt8RvaG3pgU1x6h6EF+p84qDESlMkgc1PNF3kd+nffuebFDQWTNhulVRxr7vo3fKvnx9 ff1mM6ydTyfZq2vU8LqtjU8H5dWjHxo+l8kYOoPCHfLFMEZ3v+G77X/40h2P6t0/auJFvZ+i mwguSG3aWxNd8kW9ljLdTeaT3q5LTaAMkpFK9+Ig8qGtFlo+5/Zz0ZMstDnWDWP63gz19rxe vRazefmBwOZxSOLIFkmZVKrhaMlINtRekUK2u4cDWLn8abczHmbBFkVbq137Bt8u7pIvugcj Nf0r1uMfv35rDV0G9fqi8JDF+PHl26vqtvTySS+DEO+Y/PTl5VXj68vXL5+JAE+b407vUHzo enI0WY2C/Uie7xM/R7Nhv3qlpnotJpHa46afkjjmnRi64Wja9P22Lp872RLrQZD94Qh2Gv+y NwuQPYOCU/WR+y8F3BdfzDzIYAZLv1Kabrc66Q6vlJ4DzkzDoSU3KquBooo22KLXJMF9kQhf S7OMaxrT8Ti90ZFqBZq0VI+qBzIli6uV81jft81BbX9EE+ZRG2O9psteDTSE8v74tf0mnxZf fEi/7axal8zI4b74AhH74Fs8Wx/bmZeFPTXzYUp8MS9k2be0y1e8qzdYr6InS2O6qAtd1yij KRmh2OiRs2GIHS7V5sydnjFVdtnhhwQyUGucT5vDXo+w41U+nz//GLKw3bldMXmVZQn3y5eM tm/ceOgMX3bjbJh85I3bAF8qF9Ztb3YN1OS+6Rwgn69H269pWk0XqftNpPTStuvUu8RxHL3H v4pyNCNdx6coj7LJ6LWDqGxdzGs7TcdJvQMKB5XijrI/5sa7ubtfwB3zZeo2FLyr4aaIrZ6+ 2ZwDOzJNyNY24S49bx7eqp+tX1sWXjShtsKUMO9z6t07zZ7MSy0lJfRLv588hXSUnQyvHQzM K/y6beCBFnzsFFr9BuS9fin0oKj7eDzuAGVUyIPsBtkdYxXTr31fbxn3zBcNZ3HstmGCwy8o NIvBlEvZNlJc+1JxtwOEXr8cXvuwMY6R7kXK2m9fdgNa85riZy/F7EGkA7SHXdguydqESrDT xI3fPcBcOKIcqZcAGJtJDREPe/UmwHBtb7EFZ+1G6Ae1OMYuZTs865ehPboiNppmamNLGUo3 Ql91o2OzZIPujnp93c50yA5sjhVx53yx+2nrF6JunGXTuY2DLZv0LOYjVs/9Uc1wOycqLWL7 vEFhZBD9UNZc6TRZ9nqDSy/k0PWD84xvQ3y/LHPymujbI7//l44REtOv9LZrPxXJ9iC/+tXO 6nLb7kEm1X7IejDQjoJ0Dbq61XzaqVcu+1BDqzZmMll61K+/NXuS2R387fb9dFX/DwrXvt9X x53zxejJce8f+s/afOmcTabZ0hz3ERf0XuDHpnX6qUTsnp+TII1UUQn1nNYP6u0zCOQdBcwW xeEdK7Ldcc3IMLi98Y2Lv8+Xyre/YluLxotTb5UAuXlU1FDvMO5bEOdZs97FSQiz0RNEW02q bgDLk/vOPF3U9uOyV6PQHM1+5KUdL5gvCnfOFzV13R707vN6hFeP8R7sg1rrcWeahedN0LON 2atedRe07aYdjYGd5cKoTcdkF0H2qQ/2Sa1Tefba6jaVUJM5Tlef4TJ4xaODFfxs+9Ju+zzV iGyB7h+U37RbZ6AWJTw/gqs7basNHYyz3R/s655NrN7swx8RZq8HEabBr5GTRN2aS/qaeh4c zEtsdRZyWyoxXxTunC96SzA9q7/Vz1Jlhez2B7f1nNmGTKu6uvSsv56NfaPIYPrKJszW4dnK Ml0K/V/TZbfz17f2sd371yWZNZ0aO+vQad/XFc7rDtHkLUV96dlQc7t3+x3bfTUUYTwBdUug jcyhdW2lbV2CepvdBVRq9slhLTZJiSG0apPK0lGXRJVIdYD0gMBWk6cvzFUyXxTuny9K2w9W rQ/qnx5iHaxWDnpWQ/lLGbU3oUxA/aIT077oMAdzem8D6gGr49E0MOa6ibjf6atN61+HqZSw MSmo1Fu3CZNpuw5Wnltj4F4EqOYRd5a6TQt2xbd5Mi2auq4eAIMrreGtiTN6cZPbh990suxD YX9s/IZr4B2VOp+Hgy+qHjnwu/eT6yaYLxr3zhfTQ9FGhf2TUKs7en1RXQ2Xldey/WxsON3b PegwJrI0mlrl7960x9ZHPOyPe3lwsLF1v6brezcOp4XsbeJSKtT8w96kf9zLCMNwHBo3RKBH GY6alI0eWbBx2s4UKzBQXR6bo2KMbTCdersMKMP0aF5GoaLtDA+ORxjIbQujX25hqqNRjwMz kq2zUNrdkvmicPd8mexgr8JgoFSkCZrsTvZqMxf1D4Q3w2OqZ6B+qnNb/S1PaHeTfmgbGaPd t1sVsTFimkEHgXt7KVPJZKAdhjCcPWnhyjWsHw7KeNqNuz5sTNMbrvd9GNGT6A2f2l6PNDTq us5ob0urTsOXGtnGrLfjbpL8itGKER1kC6gv/USRZVDPCRuym3vrC/NF4f754ndumUY3PKze hmSspEEvjNT6JpuDXr+3cuw6raq9fmerfGKP7u1H5qVjVkhjT+gYx2Fvf5ihrTGYOJIe+gVM SvkVbWQnQGquZJV5n8RkbCb7vrtpPx39a8jt7JBdGxxeTi4FqkQaqfedVG3ZsemsJFNcReCu VU2oyb46qUpn2hc94XR0jwPMATfIPYx2Zsk9OwZks5FgvijcPV/QWxv87R70JLXihPyURkkn mdJKJZI2Sy8f17L1keqoCdNLlWycJPM6GLO97GCY12nJrX7J0jR1JmQHMiBbIClQHkjxrW4W 9DvMGvlPE7I3oezGXkclCGzPCt4w4csjm4VOv1hGEbtrukYXw75t01p/x17xUodVvgSDKUWv 3Gn0dfcIIGvLjSy7LT/Aph55MF8U7p4vKfSjWB91je4L2D/dLejHVtkhrdG+3oTsvP7Y+KOT EL6NTlvfXUQYK9cJsxHa6LcM594uOwVqgxQDa0LOlBofVQLahtMfjTKgBtl+9irgaAtriyht QV02kCqoFb/LDUgeDJzNvCiJ+aLwXvgSdEFDq0tv1b4zx6YbPTW6PzE6XVZfw4Rjm4BGgfpg PU36xUkaDUjXyg38GE2IAfJFdfJ7mNmCcvYmrE1ZM0PvyRk4MBrxgy2nT1i5LBirrZ8KINOf 84Jhvii8F75EG2uP9hmt9bsxfeW20z+7zgRR/YpetxhDQ2iL6V37lsTx0f00HQ3NHmXrdSY5 laoVH7Uvsj9tRuxQQ+YHrpoB9B5sLDtXY5hh+y8+m63hi8r+GErR2Uy7bFKsgJYfPJ4D80Xh 3fAFwj30W2l7dXoAVbci6kXIk+5wqH5LK5/OSt/lxbGZglXidMf2M9zqKffV+auOL1aueqtf q060jRQtj3r1pkw1mNXq9msATIm71rrb5C718ker4qiOl8ye7P5P/TDqUSwXwZ7VyWoeKsew 1hTZsJWuloSp6DKPj83iPfBlJH7Bnu4AvyAlxqKEwWgQ7sA4wcDpvWj6JLmEDUy5JFQ4SqcJ WWianmphRnyl5rVizBeF98AXAvD2t41+LMunNe7UJxGK46n53kbTVlgzZVEjbRyNSZj1qmak znN/fw7vgi9n62s2XPTCobFSTDmFMRumpjkhAle1OeWUGXV4F3w5F8SjdSwEXSfBSsERXyvS ryBFzPuRSVSJd86XJVqQKM38nMS6GZgKjdkbZIBJU4F3zpdp0bO8HGiN5/CYPztWRWCNvi7e P18opMZXzYDVRdIvWU8LZxRXrBFGBh+TLyRmu9bjSc1LdQyKHYsGAM4vPrNmDswXADxroefJ h956CiiQa9uBmwo+bQObmZqhz4QDyGyM3/VJ5hCGpLU6rdhMlgowX3IPVrMn+WBcg5HuE/Gn KdfVGMxk+9iN5Jz7BBuSsSSoXIDocMEeYoXOEyMB8yWnLGZFwGgWanoXATwS69fFqy+3xUbi e6y/+qmbcvBabrw8zXKYYXRrvWCaKog9a/0VsBfPgCWeUX4GBeaLQToaZpV/RGoPn9tqmZne JsAu9zJ8US/2GqHn/uDamflnvhIY5Kl1bEPc+I1mdZsOq9+5578GkChz4FJgvmQQKRzyQbMh RvOmM6fSflBgjGycauNoRMZhj3/rdZD+rE3BJaS37YCJMl8uA+ZLBpmxXKD7A1jAWOTLkhEy wJch+o3OEnxBiTJfLgPmSw40YaxxZT30/SnKkdPo71je7n6I0qjmS7g2YidqKvOMtcB8ySHT wFgW6GP74qbRdvwH0023W0kOkYVEJwL5olg42B6/3UBALzkeQCizs9ngE3cti+2+MF8uDObL uwLT5cJgvjAY9WC+MBj1YL4wGPVgvjAY9WC+MBj1YL4wGPVgvjAY9WC+MBj1YL4wGPVgvjAY 9WC+MBj1YL4wGPX4uHx5eHi4uOAH+vql06WOJuIUYzE+MF8uFOMhhHxYyJeHOV0u6XxIlzqC qTJfTgfzZeUYQFEfyBgPJTkP5UQKOh/SpfiC8sJ8OR3Ml0sKfyCvnM6X2dznGplpYr6sgo/O F20COTvImTn2nA+ALqJwud5ADV9KNlWQ/IAPowSyApgvl8FH5wttxxhdfoAXwhdURRCFkD0V GFHmC5T8kKj+lNN5kFvmy0Xw4fkSsyJSzIc0RsSwDCkm8lImArycZOOBEJwZeYs+mS+rg/kC bCBve0HlAoOz8KvAl1KvHKRB5SnKwDK+JPljvqwO5ovvYz9QF+GvSr485MSUzxKSl/EFtWrJ eDLzZRUwX8KYVGKV4XNU/wWFzcfAfZVs/wUKpTotRZ3HBGa+XAbMF6TVfiCKGh6DJ8N3ZF6F cDjGFCeS8sVH03lK8kJLTtOl5vdRDObL6WC+3GYGLpm7q5f8jvEx+fLAYC+yk/Ax+XLzYH2+ UTBfGIx6MF8YjHowXxiMejBfGIx6MF8YjHowXxiMejBfGIx6MF8YjHowXxiMejBfGIx6MF8Y jHowXxiMejBfGIx6MF8YjHowXxiMejBfGIx6MF8YjHos5ouQMJ8OJ6X7JsRMMlfMLbomCldP LfN59QITvWQOrgdXqLXKdolKWt6+mFwY0pyeqbe434JIR8yEz4cTlVLOK7eovHSLfBFnXIVB RH2MczJ0Ek6wxzBVbvhJJyrP1Vx7K77URr3FWl+LL6uV8Wb44pli2xoBTvpWVZ92R5hW4Cdl 0lFnJig4fKEfLis4VUTrMl+gGJAXIwGchaFIoy9OVyAzNiqHrzyYQgjov1G28nUFayOpNXQO xYhTA0XAFSPodKmyhbgZ2x0VeIpvZUFeVXlvgy+RDoSiCdT2iKBQIU6QAb+Ja4JKU6CrAgsQ cUAyjSJfRBou5J24KiiRIEbuA5fSEoZINwmX2io5mxMqfe5cdDdEmm4cBZctb+sSuc+29iBc 1h6j7+9seW+DL+G5CMrgH5GJrUbnes5Gpe+FiG6DSG+IyKRR1b4k4WLVyWp1mtE8S6JwApSL yj4WMs9YQUTJlKOQKyLNOQpQUiZRqPmMPFGWR4J8eN4CX3yrAk0WRxdsA8Ux6Lolm9f0nPtE FYMMvlviSywvzd4sX4ChIgSOAb4IM4fki8BiqCrPl5d44FPmlSCvFp6MIdxZfIlu/k3xJfRc BPyJejDuI45G1m1aLvqGuk+SL7Ssy/NlElOhYFTTUs2XNPP59iVTVUmt5asX5CWfJtVMkkXH 92OufcmVrZYvFNFvhS/UYDJBl3mbjNLl/KkpZ4kLSjmoNJL+vihWPBG3ki+RspV7Mu5A0Loi cAQRX89UFqqhfOL5PMe1JuhwZSmk8pbTzdUBbMfr+ILkrYllfKEmK/3omECtPjoQqZg4XJxK UrPJWAmqxTS1aIQpHqTJjNWINJwb7aKu5syDCaULS0mMj0XmbFQQVxt4lAoVkyxJWms+uWSI iRiJimuNyD2VLpHaTE4FlZogrua0KegLLJuv+3VxL/4wq2dsiUBx0qUbwG3n7h7xUfmySJ44 4cpN4Mazd4e4E75Qbfn1U75ers7PO+Mk3AlfGIybAPOFwajHunyB7X+tqPoka4yLe7JAiNGi ykLhQSw6grDjRiX3rcsXcS7dt87SuXWwdvtSxxeROa4Wfm6glWKeV12V04CUF0ExDvaGrZmp vWRdiWKMS90tcVq0WVyOL+eHOi3a/fAllVKvU0W+uM874MulcnAzfEl9p0Xq6Y7shDD7iObi BBUukTcVpeBZuKhCEnnILZS4Sju6CTALhidZ8cRl6p2fqzwkK3J+o2fjUk+JAl/iS+WZVSyZ vqt43neheZeWMq4PlBd4Ec89ZnUonmOdu3oOFvuPgRpwh5QfPH6uxD7glD1GSY7SxVIiFwgx Lw94zpPlyJQ371mFSwsJU6i+pK6AFMr0In1f1uALVRjqrsLbK/DvCtTZY9QNENQtjIuVnBNi /urpOGn9S/QpkrPgKDqd5Qupj0SSFEsovYjlBTetCu1Pcle4U2n+xJRVJ3Q1039ZhS/Ap6jM F7LaUVnJ23sRvpDXRBoMV1NWN/JXT8dy/+RgO1AZyfCFjEuEq+AL8KyagHLEHl0zfMFS8nzB nviCODfhHJT5Mnmf6onSlfX4kmh6zh4jq/3t+UKu60jrhGQErHtSLrz6tnxJHucL+CKoUCe2 L+4sUQcL2pdikkTqSbYJ9bk+X2hNz2WJfGZcgS9EkEXtSxQ/e/V6fAGP96lwH7OmE2GVUNUB rqa3VUw18kT4KWgNEaV086kRH5Av1JoBMBiQ8mCeLxX9/aifl9fXKOPRvaT7L1S9lJWGYnvd VapVoLRkycdb91+CXQyGLNJBC9IrG9rUhaEy0uMc+GeDljtpzcmhNzACNiVSIh/wxCYgUiv5 t0dppPXnbx5RQ2TJoxLh4anCoF5cp4Kq0nTlQXpXYylpycvqkugBdZUcPcN6hfNC1H3N0bmE OX3+pfSEuy2slb/Fcm69YopZvn7mr5+DFMyXy4m59Xop5/n6ub9+DlKczBeqvbtNrJO/Wy/l Orilu3r9HBBg/2QGox7MFwajHmvxZVHTORtYOH90N6jmP3AgwuUIyfDHxaQI37MLYO3VCGcb Kxewds6SSA8MrmFKr1jC1dqXGm2oDBz80aPh//zcCCm4Mj0x1YU7F1XCRX00URkuG+22+CIm 8mYyX2YDe3KIaNJNZMJlclFZmLeyQT8AX85BaT71dnDKfn2R57czn9yRP0OZT9m5MKriavkC ckV59mOv8SmbHhkulAjlOV2OMMVi6BpCKRCLGiIptZ7pmXBJrmbuQua+JesmotyniyqKtZbW FWVcB18Mah1GdI/ydhucVz3fvDvFn5/0l4hMJ8o1HRABx51ywXydzdhjOBuCEjShIHR6RDiQ uMgkSYijYhC6AkILKgdEKcI5Uaq2Uq7KdyG9byAaFQ62AkTuiVqjckW2L4h1cQ7wPSp2UZPy no4z+EJkP65fOt9k3DgJ+/Qo8gU8KSl5CV/onKV8IUtE3JqZkhZLGStKkuckGl3PaTGydRor Fpm/TGnElAuX5nim1jIFJO0xAQ5wimSJaIg03slYly8iUmE63+ihSwxyodoSFRqyjC/5IhER gYcTCEYZSyhKIVdJ9rEpRUvB4Vbny/x9S8qL64iq51ytkbnK8MUfCJiFOPjMMNrt8oUqLHUq a8zgarwBvpDBSrmnHn417QuR0+yD/DLtS76OqHUTuWcclZooxirzxeYP2hmk3hc099p8odZZ Eb72+fLPNNVelkC/ClXkc1DRf6HFiEy42o+stKiGqOxDKWJGSl4e9RCL7lvNXSjxJU/juHUs pkblajFfMrnPPsIyOViKk/a78G7nYGAk8ZIvuJlHccVEB3SfPt00kMC5ikdt8msLsBSfXBqO yLNIr8Z5F1OuhnC6SRrwcMrlhZIXX6Xu2/xdyEwRiimNSw2PJeOGdK0RuaLscnBj/AAZVS+o JilV8hmgq2YJ2B+G8Y5wcf1lvjDeDy6vvswXBqMezBcGox7MFwajHpfjS0lU/SiFqPfsXy/v 68ibX7VwxtWLZOhsoevc81vGunyprbtabTjDs/9M5GcFTquN5dcvoF0XUdi17/lt43J8WSOk J0eNp/Ld8eXNcXG+XCH5N8Zyf/5kVsz7dlMTVu76BCfgYd0lUmBq4GiOL84X4AzP7zRp7NpF T05G6cIpU2rVApzem6as5PJV0l8e3qKZOohqnPZ0hzPT6TwkUUrinuOTaQpBI+i5zpsz4pbv 1+cKDnwZsG93VDuhTsqeE1lPcnskSnxB95Fy3Krz/KZzD45y/hwwXXhyovJC1QGhTDXpkssm 5usguW8ik0aUCJUujEvf83xbLTIfWY24Ok7yt4xrgHyCiCQCpSuZU7A6RYVnPzLdSN+mhSZb hi+5ygDpopNJ3YhiGlPd1UydosqIqEIc0fVEZVeULhB3lZI+5W9wtppuiyoap/MFWipxzaRV GFdMYp5kqxPc/RJfYFCBJKNM1TbwxD3O+p5F6YYaCoUmPc5EXnL56ll8gUYzdWfSNHBWqvkS xSjzhVwj8Z74QjYWi/mSa3Ko1Ob4gvU2b3+daI8RP1HjU+BLnA2qwFl7LJvuOe1LJLWSL4K6 UOSLSKKnieDQZP5uByf3X/J8iVsQ9CGImi3wxV0X6BdNgRxfSCt5bjKCzn0FT6kVuGReSDUs 5gBfE7mrEXdh0xLXwTSXRp4v5DMpCVjBF2p1yHuyx5DLe2jhp3DSn8Mt7QRHXBK/9ZwneZiq nPHsP9vzm5CXiRtnD6cLffiBL3tsJeI6ENkcFP3gCR91mJd4fEyAPE8oCaJaiTsDypGWMltr iR2YZDa6M8W1BdfFafYYI493VUNi8YV3DubL2nhXNcR8ibB4vvLmWsgbw/upoVJJ3k8pF4L9 kxmMejBfGIx6LOfLCZS60cb7SrlaqTZqpLxVxRe83+ZiFs7dotqswZfZTk9FmLWwKJ2r3A40 gXXxop6eynk1uQZfaqW85W1cwx6r4ctb4T74skri74Iva+ThlvkC5/vCXFzitw58sfEsFhCT m30Mk1foA7rO51KjJ8VI7/eQg3K4eSnFGHHJwcwqmOuc0Owfrr9cDeH6EwKsOwUxBIwR3TfC 75++q15E5UqBaUaHhUiKS02xkrkvvvfh8ibc6fZY5BHhr4n4MnqiUt4Zgkoh/hDEEZFarn2n vDgoN8Y4XIWUYowkp2n7IiYqHOFDH+WFcjopphbllPb7J+5qSLZ6pUCRL1C8SCRT9hitV3Go t7D8z+BLXHRMD5HGiCIIKixRX7koZGq5ApDqJGbDFS6I9FyuHCg1ii8iLYGg4ibnqGJRqWVy L0gpeb4QMTL3cpYvSWkFEZcOmZWXvavrYV2+0L7YAl6OKiTnVUSr4ml8Eak8mqdEulEhIo0T uEi5cpT5MukdPaIc4EoTubxEORBJjDq+UOVYzhciXRqgQHV8KQu+X75QhcDVEPOlnMwqfMmb K2I2XFwIqn3JxQgXavkiisGovOAaJ0q1oH3J3iR4cbZ9KWSbKEMdX6h6odK6J75Qqp0tdflR hi/4br5/fKKrVJVV8CBILofDl10rUCx5rhz5+hNT2kiVSgTrBWa6oF5E7oGOztxLkKxISkTm BdocUwwi3Pl8Ser5MjjBfwwM6MDBmQkeRa7dke8+FSNOxB9GXvITPT42J28i8pwQhgqHLk9E Dry0JAY1bkP6vPu7HHm/Z0tEeOdPSEfJVRU49yIalErKQYyPLVopAOiZub8+HJCMNCzRnOz4 Z1zPl8K9+MPUmHBvn5d7xBvn/r4rKwHz5Zy83CPeNvf3XVcp7oQvZevkWnm5R9x37q+OO+EL g3ETYL4wGPU4ZXzM/zg7dTzUdrKp8FZe66tm6LbsojXu5VppVIW7Uu0tbl8EeXgqyOmYU8Vc AiJzvEaGTs/1+uVNxqQvkKk1+HLtcZ9z+LIG8LzXbfNl7Wi3xJcVJL+JAt8vX8CIFfC19x+1 e6vDWWkw2132Gk89i4kZq4xnWpRn6qpPjZrwE4L2nEdSUJRcDJHN1XJfezrdMAno5VFrJKKJ X28jp67zyZ2GkqP683mKCh6vhyBmRXP3CN0P6p5fHGvYYzn/kLpCQPUO9VTndRHqMU2XDBeu iuJVnBrOaSQ+oSSKKwoxRJquCAIW+tqT6XopkbzYs4iwx8REJETcaZQGqr84SkZfCOIn4dJr 9D2/PFbhC/ER2o1agQJUq4hv3IzJhi+Qt3oiroqipBxfSB4Q4imWoBg0/0AFUOQvZjymPJQi aCk5vmSfBelDURDpUrWT6EvmRqV6lV6bl3IZnMaX6HlBfFQXIF0lBO8tcjN31wkzK3xUeqbR rVSaWpkvhGEEGygkMI1RxxcsZYYvUQ6uxRcRVTSRxop8OWNkdTEuxpfK9oV+EMM7QCoIVYuU tSLoYKRUMjWKL75s2aYuUbY38bWncnA6X6g7uKh9IQRSd2ul9uWNsD5fkrWpJepT1gbFlxmD hOJLkRHVV8kWk/Sch2Ku4GufVmKBL3n/+/ITj7jTsCWkarfEF5CXVClqSll+hFwCp/nzC9gK Ul7ycHyswBdqvhJ6jXs/7gkOB9Ce9iKKkRkeK3jsU6mRPuqAObfiax/neUJSEk98LyqZK6by TNRzEBnSiMYmQylxeRMplIbl7lF1bVwI7A9zS7it6n+j3NxWoWfAfLkl3FT1v1VmbqrQc2C+ 3BBuydf+bfJySyWuAvOFwajHbfGF6cq4bR1YPD42X15x8tUZ4dm4Z7fplQIWGw81we/MIKku et3dKs4kLUrubYq1tH2pyJY4+eosW3M/z66sKgF1k2Mz2lCZ9umVuP4T+hR5aV3Rd2stvtzo /MuH58taoeYivAe+5M7MmRFvlskTsJwvhO9+5J/tvpf55OM5PfudSp5AoJJvd8gfTK0sOTPF CdPLXT1jBQDhB48nR6kpO+JqMpGMs4Cd9jPlmPGhr10PkdYVfbdAIGo2mEKVboDyZvX0NAtu MV+gs4X7QOeQvoK/nCcGkA2+xZSVnIRPwk04jcj/Iis553+Rne/Olw3HiDKUqD+WEpeNSJm6 ShUBxEX3I1/KGR/62XDlukoKTPq+zJkgNbpBlZfS3aU4yR6bUcW0IsjbWqjRjIqV7bEyVSok Z23p4n0UU15K8gSgylFRQ1m+kDGoq/HJUpVk6zlJTWSkVNhjFF/yOSxll9SNKNNFjViCy/Ml +APBq1RzGBkWs3VSyxfK94zOs6CbsLwOeCuLyhXFF8Kqgw0UIZA0n9DF2POLvooEZkt5Lb4U /daoGj+LL6fPk75R+0JVsSBl0w/s8/iCrs5IzjZGuQzX8GVavAKAuN1T7iqZo2xWyqW8Gl+K camoZ/FlJpk8zuMLtY4pecgVYxBlJA0cIDmTF6oCBXEhLzmnK9nnXlZe+vQkHgb+mihJyfNl 0UeZgFQOcqm5B/TCupqpIZKEor7GC02wv5plzgIs9+efKN994lziER+u5oYnYASRSS3KjaBy lU2tLJketCuNj3l5USlFiFCwO7xSpH7w4AikkZY8CiemYl7icGkpYb1kUnPlWVpXxN2C9ic1 PEbZ7HW6EY/pRXp68vDYbfnDXDd1xgJc8FadaTFdFjfFl1usIAaJy92pm6bLjfGFcSc42Z65 dzBfGIx6MF8YjHpcii+JS9SpctbJhP0JvpJRJ+TllUn3IkYIGqxZP4HLGE5vao/dkO13ufZl nX7buXFTwoSx+Ow8ez7dy9w4QR5eQPodiCVTYL68BYj5Af9BBBDu/xKRl8noPUhnvtTt11fn 0V0qLbJ8ih7n2N87SbfkmU7NmQn7j74BgC9ASMbvP3ylE27La43IPLVuovzOgzpP93JeBLEy gr5HqCqoGc75Oz0fN1jHSa7mauNCOMUfZqlHREY/Ig8L2uNcJJLLXtlFn4zAF1pr/VUgA6Um cJ4px4wTao2yx8h1E6UksjUkxHw4cFWkqVH3KLpBuTTKd7ocN57oz+rLW2KpPwwuP5XdCr6Q 9Rl5OOFjMt1s4rk+CLa4UkWi+IKymx6JfF7qa43iCxVjdk9qUj1FKUjWV4y+J5mcUkIiUdk7 XY5byNVVjLR1+QKNkjq+zHmcl/iy2P8e8yXVpKV8QREKxkEVX3Al0I+G0u2p9HSv5suMb1eR LyDuVLrTy/lC6ssbYlW+oFMlvkyUfzt1X8t8ycUq8GXKaxJpy1XzJVPQilqr50upfcmbP+e0 L3EwqrCCLk90lb7Tubjl9qVc2xfFGf2XNM/L+UKpCnmDqHRz9zvNATphnlPE9SJfQjSYl/DS vAmeXFRrFXyJ0z3H072cF6J2l/OF5Dh1p3Nx83ealPKGOGN8TExJrxl6WwvgOl0eEgLttT+V tuFpukv978F4THaYKkqX9hpH5kmUZ5IvxVoTPrlyungEkUqiehVEKS8wrkgkE3dmosubPLWI O52Lm8ZIckWr1cXB/jCr4y3q8Kbu0zmZuamCVID5sjaYLvdakBowXxhn4Ryr6A5XBTBfGIx6 MF8YjHq8hb9lfZR04Ihqs8uSl6f7Bg+Jh4eH6WF1iVVB9OeDwUkpVdpMlzStoA6ITIi3ycst 8SWZE8mMs1+eL2tXt9Hb0+NmJNZFfcAfy1FZGxd97MzxhZ7tXh+3ZI8V5hevnZPzAPT21Mh1 Z6lQMWkuVhtvxJeqADfCl9U88ZHIIDu7ggsnMSXpUuJKqYG4OKfRtlh07hPP/hkEPX14AB/W QApHwcp6cCdpQwqcTGJEKT/4LITEpigutBeJ5HI+/ulqCWJR7ezdhwsWUDgUIxUcpZHJS2bN wMk4z38MzmjnXCeQ98ip/isoriDixpHmUqPSjR0ucrknPVSKAIoZPh6Io8mTy58sty9UDDJc 4NXkuIFbn4es3Zbz8Y91lKrd+buffIipcM9JvfL3I5PlFdubk/3HYD4EvBodx9Wba0GoQmXi guQod4rkXpCpiTTXhI1M5YBSiXk80J0JpLPQbvM6W+QLGYMIh6Q/xNJnTDZck9lCF6iSuR9x jYucGOLelO8C/VxfAafz5SxPfLLyF/OFrIcSX2ivJ2SPpWeAZ3pU+RnfuAweiI9L8+UBB5wQ X7zpBWMS1h989iPzOXe3SO9Bii9RjS/iS0hjSiXfDF+m9Tzxk8p4o/YliSuSMNQlii+VlUw2 LW/BF6K/H/iSHzdL+i+w5HGVRL+yNUTyBV9Y3r5QAaYk6np0OZ0vpHVIaXXR5i33XzJxBRE3 rqpC+58oviCvLvsoDvk/YL313fxi/8VHRr/Q2UyMKBDmBcUXmspprcW3PNdnmKur3P0QWMx8 /yWOS+XlynxJrZcTPPFRyVADO9FXQ1zs856M0ZAe8fj6hOJCi4GyNko+5fgoX2UP8UjUAzpJ j4/Bc3XjY3E4ar7yAQyQPeBRsSCGuAehshLLzAcjPPHp+sO3K6RitTzYaIk2RXoVxyXzsiZd bmr+5WPhgThinGLu1ks8H8yXy+PhDnG92lqdL6vqNPPlSijaWx8YpRG48+StAuYLg1EP5gvj ZHxAbTlpv4v5WU00xnrdaj1tVQAp6aTEk8wkfmvz3uqLcjA7hxqNJBWkRGNSseR0fHF5DdWV aHFtXCovJ83v17AKhFsj52fIyJD2dL7Ux6RmiETl0Rm1IBZcFsVQtgCCrMX8zNjyTJ1ydZW6 WojT/S3L4Sp5VY31+fIWeRHFc+uPnJ4g7o75sl4l1OMkvugjAT4IXyJqZ29ny0UrAMJVNDOG zyUe9maOKp4ozeY5yima9IoNiih/yUU4Jbp0BrbIFzj7mfrQ45osPI2COPcB7GjifuSECHCQ 8kVE4eDlxNc+Mtui20DdX5RnwsefLMeFZikDFttj2J8y8VvwFzN7EcOeDfzDzzMsHpdegGRD fRYqCMoDORXpVXAW5Y0oRxwXJ1ey3OrsMcqHPvqe50vGZ4S4H5QQSvcovhDh8G0UcXZzdz8f F9508n6IbF2tixPGx2iP0pgv4LmTamZUqBwjKI0SMIiYVR0iDaq2c/mjFITMKZXaWXwhK6JS F1K+UFJm7FS63UhTIcKhezSl96h09/Nxc3cwc8duhi/FMqDKpsqVrTHs2x0/vLAl4p4yIomb y20NX6Bv0gTTy96Ja/FlZhYOR04yWc2X9FikETNNjoitjlq+ZOOW+RIiE/laD+etryzxpVQu ki/wdxKWeMIhThYqaIYv09IVCvhGxqm+DV9K5V2TL2ldJRGLGnwCX7IR5vkiUuFrYylf8C3M rgTKWxFE6ynSqyKOQXwAvsC4aRFowyDhSzZ/xXKIfGqr8IWUVy4vjpfeI9SyFmutwJfKGiI1 vXj3az9yz5bb4ks8eiEmylMbu9QnHtjkaAjVlpY87AUYIEPhiFwXVgWg25fmDzv7J57kUyE1 anwsOwuYHnlB6cBcubwiGYtKyxbqA3SoMzlN6gCrJZF74m7N3f25GNRHmppwI2Xo/q6J2/SH OSMbb1yCq1fYOhlYLOXq5b4SbpIvTJc3zsByKVcv+JVwg3y5TEP6sXPKWAk3yBcG42bBfGEw 6rF4PJlwl3qDbGYtH2pfEB+FFrSq7b1QVsalbH27rtaH/O2AB1YvV6zL4oT9lObPVEddgJya i/xPIqtgyuGcrJxeJmKuijx3NsT8hbfWvdNTvl6eY3wwvpyfjzPjUzlgvlwu5to4gy/B1ypt amt9tn04ME2XTdY2DsiLf0JpRJnJ553KKeVDP1MO6JobZspL9gaamUfkEbkclO0XKhxldFK5 ny1vqSDxOoz4UjTbOs1ofVleKc9vitP5EhwQsFcDnHcW6ByuryjczKMfpga9+GM/bsrfO817 JqfIp6KmHNj7Is0BUQ4BaQJbllwOZuQR4Sijk7wLs+WtSjcNF11In19imby5PL8hzrPH4NMS F5gIF7kc5X2Jcsm61AR5+9PaLvAlm4OEu6VyxEkJ/JGtPvoBk8nBvLUmcpKzQaZ8DKI1qEg3 uUDdozmrKv/InMnzG+I0vtj2FnoS5etdRIbHaXwBqaX3IkrjInwhyhEnVcsXY3t5v6u4/Ojq nLy05CfwRVCFmzPHUn8vIBluG5v46VHty4y8Yp7fECfzJb6XOb6I9FTm+V0a6EVpJHyJ08jx ZY4RpatUOeKkFvElrdK5q4W7AQ9PbV+mbLxiulS4wBdamFgsr5jnN8QafMmaF1FNYL0gHjo+ TqZlwHyxj5lcGvRTDEaJg9H2fKkc+HJyteglT36I0tVcvZC1S2icqMhB9PRYlC6q52J7v1he Oc9viFPmK4P7tjEd6PGxxMcatrREuFhxo2Ttp4ADZN4fHfpxh4/M1GA+p+WraTmooTIw2pf1 kp+QFHCEcyDm5VElB/VCFTwjOb+SoZwuOYwGnzdJXZF3piyvmOc3xS35w4jk4ErpX02gOOvy xXBVrbgt3BBfrk2X1dNdLk+ccfVyYLoE3AxfrtK6cg4Yy3AzfGEw7gDMFwajHpfjCxrUF3Xh akVf02w5MW1q0Kcon7paV6e56qnJOVuEZbwNX/LzT6f2itfL6NqDWPV5Fvmg0zxfpuXPoKqc M19KeCN7TBR/nids3axdKPkFkWqDMl+ugJP267MfYRYt9bGOPN3xg5Gc5ov89NOUBYyduxqd c9NbqQM+MeUISwlnCIVA+Ztbv1CZZzgbiKpNRIL9+wOIOoUL4EjP+SmOgaf70DxgFBfdmnQe t9Lv/51haftC+m5QfiTYU2TeHov99Il0BRE7vYrOAX8OgcJF/iFxXFQiJwrpaJwu4XZfzjO4 JqKEUL2kP2C4KJPlGsLhgOTsfaPyF2Va0Am+U5zBF/xB1veUUUqKL+4/GYPUmrzMKIagpBT5 kn5Q+RNFMbN5FnFqeW5k6xRra5YvZJ4p5mTTcKXP1OJHwbp8IbzBTuALYb3M6B5l7hCpQy95 0ju/UEqSL6Ik5o35QnripXmJVgqkRmmJL2R5P5I5ti5f0MPuzPaFipDTPcokyLcvab5rSplv XzKZWosvk4CHsWSqoahoX7BkkQYttC9UEh+GMKfwJbGcSVM2tbWxlLT9F4miRulGkklxRE4j faPMkGz+vBTY/k20OpF1lctzfA2nhjNN2lsiyV8pNeq+BcnE/YAExvJzdZre5neI5etfwKiT 87OPRnOmqOWmvcuxJRD76Qsq3SlEIcQJIoaIIpS886O0sG98yF+8fkHkMlXOM/Jvj1OjLSSy Tv0RWffpfUPlFTA3VBo2VFJ/1X7/7w1rzL/ccC3dcNbuB1yJAcwXxhy4EgNW4Mutjo/car7u DVyPAOyfzGDUg/nCYNSD+cJg1IP5wmDUg/nCYNSD+cJg1IP5wmDUg/nCYNSD+cJg1IP5wmDU g/nCYNSD+cJg1IP5wmDUg/nCYNSD+cJg1IP5wmDUg/nCuCuUd/G8+B4Cy/iCN2g4eeHdm63X e3h4o4QWFV64HSTClqxxVZ5Tu5lE6+XBbWftNxVqcalX0By45464fb7kd1ZcXuo3QQVf3pZS cEPmidh1zIcjzp2Z8ilBiT2WTpAXgp+rOWAfNZFh8U3xJb7BzJeTSi7cjb0TvpwggxR6vubA bNBbvt0WX9Aeb263Pmpnfby/V1LvxEb+IjVKCMl++69kz3qDB2+DqaMH/fVgPsBVc8qcePBR orgPybnEvivtdU/t2Q81cY4vJ9du7sbh+qPKEUue4gKlm5MRdyabgRU0BxWFvHJjfJmgeod6 ojY1TfZTDDLQjonZpw4tuahnD5NrMQwb0E949QGey8adCAFRXcR7PsYWtogj+CNR4ssZtTt3 34jUMpLj/gtljxF3ZjYH55WNyk2cl0vhDL4g44LeHzRT4OgCqTA5yfHuqYR0oNmRzhMXIgpE cfNUITIUlzxzQ/1OlEW+nFG7NEQqIXdPklwV+LKgX7KG5kyJPtBFuBTOssdg8b0mJJmmNicN H8RerVNJ8gxfvNGUaVW8QYY/cnGhuZaaYyRfKvbsD0wp919OrN3cjYvrHgu5OF9W0ZyoiSaK cdkBshX6+9GTkqw1ShsEEVjEwRLJ+DChC/7wn0k7QfCFivtAyY9yi/NCmSxUlBq+nFi7+TuX kRBLvghf1tGcvLIsqoyTscJ48oxWk88zVIHZJvgcvoA+SAVfHnJxqQ9cDq83UIHyJqa7LNAv Wi2W1e7Mg7WKLyYhgY/ouPBcemdoW2lFzYGXUGq3xBdq1gnurE/tek9vpw9khVGYdAv7VDLc zZ6omwc7KjbBMS6v5v6qNq3CmNkDGXdKriZ9GGq2ubxn/+RrTfgbTe6mv7h2i2NT5NsAcJ5C XvLvCijt44/fM3AxzQnlgOMGceVfCvftD3PR7N6gb8Dd4M70qB53zZcktw9vgWuX+g5wX2q0 BHfMl0s2vcwLBok75guD8eZgvjAY9bgcX/DE05WLeX3z6gRven9mnQxcrmhnRU4WMkzxONot 4W34cu0OIDX1CK+tifwsWi1h6iSuk69rS07qpXr+8zp4I3vsBvhyyrX1irqgAm5MQy4LQZ7J zmBfHUvn90WYkRJTNGMFvdojf+94Xm4N333vkz/BqccpNb6wD9gUxwi+/uHjYSJjRIJFui6B NiLI2T3wgaRQk7txaufeD5wD8n7MrFAQ8UXqvlGScZFI58Iwfy+8uFXWNJyPxf5jgP7ukHJo iPwlIr8PyifjBN995MWSeI3BkOCbdD4OR5G7/4w/Pyp61gkmro2oDiIpWXuM9MQ/7X7EOSDu Bw4ipjSNgmRRkIxsMKq24EPViVtnTcP5OMXfMsohXbOpP165kRXheUKlQ9n/xAKVB/efCJkQ pMSXNAhlt80/BnB5CopaIByqUUFdO+l+zHQSSNZF9+ckySSLM+UV4ACnfSWTLebLXzMYjEoI 8de/MBiMOii+/MZgMGrwhzq+CJG/9uuvvyZHl8TDG6TxNjkQV8j7NdJ8RzB8sUOi+oz69kfm QP0WOQm/2j945PHw8OA+7TDu+Vl+8KIf7MFiCWfmaiW+CFNrBqWA5z+GQAJiaS6BbjB8+yLs CfVtaof6IFDki1WtB/xxBqB+P0DphSi5U6flajXeuxr91X9ksYgvv5bPiuW5FNwsOcR8EeGT +qBQtscefkvV8ywEXT2dL+flah22MF/uETRf4hOzDXIgyq9pC+MMKKecD/a/+eG1/8Hrf9HU gvKctmMpPmbB4DorV+sYZK5Gf/Xt86/gwz971MGv/shddPX8q/+2h8i8Aw+wX5N067MpfgsW uv3+7YOaaKk9Bvos/ksUa3mmww9Uz+uy00L8nH+ILSSCL1EMH+qBuFpqPE7P1cNvSxskGq5G gXqHj1/hz1/Dkb3oOASMYRQjyPsVHON0l+dU/BaIc5Kg+0fCl99Q9wXUkfoIDy945OLBI/CQ C+ZTUMIHoHKQHzD8HB7SuCRVZviycq7q4Wrcty+QL+4j9AxRiF+Tq9HHbyjGbwRfQj++fPRb 1lbXj9FKKe/liOILfJBgvmRQbGCQ/eQOghX08JCoY2V3Ooq7jC8Xy1U9XIXi9iDPF/8IAnz5 FZ5M2xcw8LZC+yLCpzhR0t1jhf7+zIjyb4kaB83MK/W8alIsqebLxXK1AK5CK/mCzv+a1DXB F/SL+bIKEr6I3zINb15GiS+UBlOaSSt56YkedTBI+uQ0/7xcrQURqg9UJEWaHF/KHzRfxMkZ 5f5LOl8JBz4EPCwJydtj1MzgAxiKesDjT/7Az0lm0wySH6jxMX8JSl4pV2tBuCqD/T5Njl/9 RzhnAv7qT/irPhSI8WsQHQ+aicrchWyCjkzo0Xz08THGm0Pcb6rXyfoNgPlyRYi7TfMaOb8J MF8Yy/FxHco0X/7AYDCqIBgMxgK84VJoBuPewXxhMOrBfGEw6sF8YTDqwXxhMOrBfGEw6sF8 YTDqwXxhMOrBfGEw6sF8YTDqwXxhMOrBfGEw6sF8YTDqwXxhMOrBfGEw6iH+BoPBqIX4OwwG oxbibxbwN/7O32QwPhbKSs98YTAgmC8MRj2YLwxGPZgvDEY9mC8MRj3KSv//A63MX8V81oR3 AAAAAElFTkSuQmCC --XsQoSWH+UP9D9v3l-- From andyp@bea.com Sun May 20 16:46:57 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA16676; Sun, 20 May 2001 16:46:56 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA28667; Sun, 20 May 2001 13:47:03 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001256wss.beasys.com [192.168.6.87]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id NAA00137; Sun, 20 May 2001 13:47:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20010520134317.00b1d340@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 20 May 2001 13:44:31 -0700 To: Steve Youngs , XEmacs Beta From: Andy Piper Subject: Re: fyi mail-lib status In-Reply-To: References: <8zjt6oe4.fsf@rapier.ecf.teradyne.com> <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:22 PM 5/20/01 +1000, Steve Youngs wrote: >|--==> "APA" == Adrian Aichner writes: > > >>>>>>"Andy" == Andy Piper writes: > Andy> At 12:05 PM 5/19/01 +0200, Simon Josefsson wrote: > >>>pop3.el Heavy modifications. (Rename to xpop3.el?) > > Andy> We forked from the FSF because the author didn't want to make > Andy> reasonable changes. I don't see why we should rename it. > > APA> gnus also includes pop3.el. > > APA> The xemacs.mak I contributed to gnus allows use of XEmacs mail-lib's > APA> pop3.el by means of variable USE_XEMACS_MAIL_LIB. > >The mail-lib's pop3.el _is_ the Gnus one. Simon synced it a while back. Well, if that's true the GNUS people must have adopted my version because its still got the stuff I added. andy From andyp@bea.com Sun May 20 16:48:40 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA16766; Sun, 20 May 2001 16:48:40 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA28691; Sun, 20 May 2001 13:48:46 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001256wss.beasys.com [192.168.6.87]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id NAA00224; Sun, 20 May 2001 13:48:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010520134528.00b0f760@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 20 May 2001 13:46:14 -0700 To: Simon Josefsson , Steve Youngs From: Andy Piper Subject: Re: fyi mail-lib status Cc: XEmacs Beta In-Reply-To: References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:36 AM 5/20/01 +0200, Simon Josefsson wrote: >Oh, I just now noticed the pop3.el shipped with Gnus is not in the >XEmacs gnus package. I guess the mail-lib pop3.el is backwards >compatible then. That in fact was the motivation - I wanted a drop-in replacement for the GNUS version that support UIDL. andy From Adrian.Aichner@t-online.de Sun May 20 17:22:56 2001 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA18070; Sun, 20 May 2001 17:22:56 -0400 Received: from fwd00.sul.t-online.de by mailout03.sul.t-online.com with smtp id 151afJ-0006fm-02; Sun, 20 May 2001 23:23:05 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.45.7]) by fwd00.sul.t-online.com with esmtp id 151aeu-1p7hQmC; Sun, 20 May 2001 23:22:40 +0200 To: Andy Piper Cc: Simon Josefsson , Steve Youngs , XEmacs Beta Subject: Re: fyi mail-lib status References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> <4.3.2.7.2.20010520134528.00b0f760@san-francisco.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Andy" == Andy Piper writes: Andy> At 11:36 AM 5/20/01 +0200, Simon Josefsson wrote: >> Oh, I just now noticed the pop3.el shipped with Gnus is not in the >> XEmacs gnus package. I guess the mail-lib pop3.el is backwards >> compatible then. Andy> That in fact was the motivation - I wanted a drop-in Andy> replacement for the GNUS version that support UIDL. Yes, I remember testing your new UIDL support. I just love reading my mail on Windows using XEmacs/Gnus/mail-lib from a local UNIX server via pop3. That way I can avoid Lotus Notes + Domino Bricks. Adrian Andy> andy -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From youngs@xemacs.org Sun May 20 19:34:48 2001 Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [203.2.75.228]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA23322 for ; Sun, 20 May 2001 19:34:47 -0400 Received: from slackware.mynet.pc (wdcax13-145.dialup.optusnet.com.au [198.142.220.145]) by mail004.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4KNY7U27714; Mon, 21 May 2001 09:34:08 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4KNVXYZ006722; Mon, 21 May 2001 09:31:33 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: Brian Warner Subject: Re: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems References: <20010520184103.7730.qmail@luther.lothar.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 21 May 2001 09:31:33 +1000 In-Reply-To: <20010520184103.7730.qmail@luther.lothar.com> (Brian Warner's message of "20 May 2001 18:41:03 -0000") Message-ID: Lines: 29 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "BW" == Brian Warner writes: BW> I've checked in this change to the mailcrypt CVS repository BW> (http://mailcrypt.sourceforge.net has a pointer) and will be releasing BW> mailcrypt-3.5.6 just as soon as I can figure out Len's release procedure (in BW> particular I don't know how to upload anything to sunsite.. any pointers would BW> be appreciated). The last time I uploaded something to sunsite (a year or so ago), it was simply a matter of uploading the tarball and the lsm to ./incoming. They have some software that parses the lsm and moves the files to their rightful locations.[1] BW> The Debian folks already made a mailcrypt package revision BW> from the CVS repository.. you're more than welcome to do the same. Yep, I'm one step ahead of you. As soon as I was aware of your fix I released a new XEmacs mailcrypt package. Footnotes: [1] Please note this information is from my less than perfect memory and is at least 12 months old. So YMMV. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From martin@m17n.org Sun May 20 21:20:59 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA27407 for ; Sun, 20 May 2001 21:20:53 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4L1L9p25631; Mon, 21 May 2001 10:21:09 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id KAA16531; Mon, 21 May 2001 10:20:48 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4L1Kkl09885; Mon, 21 May 2001 10:20:46 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15112.28014.790096.635334@gargle.gargle.HOWL> Date: Mon, 21 May 2001 10:20:46 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: [Success, 1% lisp-tests fail] XEmacs 21.5-b0 "alfalfa", i586-pc-win32 In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "APA" == Adrian Aichner writes: APA> These test fails because my system prints 3 digits for the exponent: APA> (format "%e" 100) APA> "1.000000e+002" APA> MSDN actually documents that exponents are always printed with three APA> digits. APA> What's the preferable way to fix these tests? APA> 1. APA> (cond APA> ((equal system-type 'windows-nt) APA> (Assert (string= (format "%e" 100) "1.000000e+002"))) APA> (t APA> (Assert (string= (format "%e" 100) "1.000000e+02")))) APA> 2. APA> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100) 0)) I vote for 2. Except that the 3rd arg to string-match seems unnecessary. (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100))) Of course, a comment should be added. Microsoft's implementation is not standard compliant. From the standard: e,E A double argument representing a floating-point number is converted in the style [-]d.ddde_dd, where there is one digit before the decimal-point character (which is nonzero if the argument is nonzero) and the number of digits after it is equal to the precision; if the precision is missing, it is taken as 6; if the precision is zero and the # flag is not specified, no decimal-point character appears. The value is rounded to the appropriate number of digits. The E conversion specifier will produce a number with E instead of e introducing the =====> exponent. The exponent always contains at least two =====> digits, and only as many more digits as necessary to represent the exponent. If the value is zero, the exponent is zero. A double argument representing an infinity or a NaN is converted in the style of an f or F conversion specifier. So the truly correct thing to do is for (format) to remove the extra zero digit, but only on Microsoft platforms. Probably not worth it. From schaffer@optonline.net Sun May 20 22:03:59 2001 Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA29570 for ; Sun, 20 May 2001 22:03:59 -0400 Received: from SPEGGY.optonline.net (ool-18bf1659.dyn.optonline.net [24.191.22.89]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GDN003VQXQMQ4@mta6.srv.hcvlny.cv.net> for xemacs-beta@xemacs.org; Sun, 20 May 2001 22:03:59 -0400 (EDT) Date: Sun, 20 May 2001 22:04:47 -0400 From: Les Schaffer X-Face: [V?bWTh\+_V")"gXxY9KGQozO(|>ggwp;\Ds6@YGoS$wreQaSLmhWUp%V;okpj4C^i$FQWK Q:/luO.Zh=VP"U5M.%m1cK:v9DgiQp^JK47nxE^=e3~HPoLmY,igNBZo)LUT3a2CFm*chsyaq7~=dU _IX>v[h$BZsa*yn5;?{|3Z@ZI@FL(e`-@wq`f?~{1){A%o:/t"39M@}ER]6.62NbfxrD%!{9!So^\9 c Subject: Re: Font locking bug - infinite loop To: xemacs-beta@xemacs.org Message-id: <15112.30655.703000.237424@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 6.92 under 21.4 "Developer-Friendly Unix APIs" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT i've done a little snooping around in font-lock to see what coud be causing this problem (affects only VM for me). in font-lock-default-fontify-buffer, there is a call to unfontify-region followed by a fontify-region. (font-lock-unfontify-region (point-min) (point-max)) ... (font-lock-fontify-region (point-min) (point-max) ) i played around with commenting out each or both of these calls. case: both commented out: no infinite loop AND VM digest IS properly fontifed ANYWAY of course, things like C files get NO fontification both left on: infinite loop in unfontify-region call unfontify commented out: infinite loop in fontify-region call fontify commented out: infinite loop in unfontify-region call VM digest IS properly fontifed anyway upon breaking out of loop les schaffer From andyp@bea.com Sun May 20 22:51:56 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31528 for ; Sun, 20 May 2001 22:51:56 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA12147; Sun, 20 May 2001 19:51:59 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001256wss.beasys.com [192.168.6.87]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id TAA17608; Sun, 20 May 2001 19:51:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20010520194911.00b16290@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 20 May 2001 19:49:27 -0700 To: Les Schaffer , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Font locking bug - infinite loop In-Reply-To: <15112.30655.703000.237424@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Does this happen if you switch off the progress gauge? andy At 10:04 PM 5/20/01 -0400, Les Schaffer wrote: >i've done a little snooping around in font-lock to see what coud be >causing this problem (affects only VM for me). > > >in font-lock-default-fontify-buffer, there is a call to >unfontify-region followed by a fontify-region. > > (font-lock-unfontify-region (point-min) (point-max)) > ... > (font-lock-fontify-region (point-min) (point-max) ) > > >i played around with commenting out each or both of these calls. > >case: > >both commented out: > no infinite loop AND VM digest IS properly fontifed ANYWAY > of course, things like C files get NO fontification > >both left on: > infinite loop in unfontify-region call > >unfontify commented out: > infinite loop in fontify-region call > >fontify commented out: > infinite loop in unfontify-region call > VM digest IS properly fontifed anyway upon breaking out of loop > > > >les schaffer From schaffer@optonline.net Sun May 20 23:14:42 2001 Received: from mta4 (mta4.srv.hcvlny.cv.net [167.206.5.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA32344 for ; Sun, 20 May 2001 23:14:42 -0400 Received: from SPEGGY.optonline.net (ool-18bf1659.dyn.optonline.net [24.191.22.89]) by mta4.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GDO0020M10H0Z@mta4.srv.hcvlny.cv.net> for xemacs-beta@xemacs.org; Sun, 20 May 2001 23:14:41 -0400 (EDT) Date: Sun, 20 May 2001 23:15:31 -0400 From: Les Schaffer X-Face: [V?bWTh\+_V")"gXxY9KGQozO(|>ggwp;\Ds6@YGoS$wreQaSLmhWUp%V;okpj4C^i$FQWK Q:/luO.Zh=VP"U5M.%m1cK:v9DgiQp^JK47nxE^=e3~HPoLmY,igNBZo)LUT3a2CFm*chsyaq7~=dU _IX>v[h$BZsa*yn5;?{|3Z@ZI@FL(e`-@wq`f?~{1){A%o:/t"39M@}ER]6.62NbfxrD%!{9!So^\9 c Subject: Re: Font locking bug - infinite loop In-reply-to: <4.3.2.7.2.20010520194911.00b16290@san-francisco.beasys.com> To: Andy Piper , xemacs-beta@xemacs.org Message-id: <15112.34899.890000.841157@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 6.92 under 21.4 "Developer-Friendly Unix APIs" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <15112.30655.703000.237424@gargle.gargle.HOWL> <4.3.2.7.2.20010520194911.00b16290@san-francisco.beasys.com> > Does this happen if you switch off the progress gauge? with progress-feedback-use-echo-area t, the infinite loop does NOT occur (even with font-lock-default-fontify-buffer left untouched). les schaffer From wolk@netcomp.net Mon May 21 00:07:02 2001 Received: from mercury.netcomp.net (www.netcomp.net [206.64.84.162] (may be forged)) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA01875 for ; Mon, 21 May 2001 00:07:02 -0400 Received: from iqara.206.64.84.162.netcomp.net (dsl081-149-127.chi1.dsl.speakeasy.net [64.81.149.127]) by mercury.netcomp.net (8.11.0/8.11.0) with ESMTP id f4L44vS08556 for ; Sun, 20 May 2001 23:04:58 -0500 (CDT) Resent-From: Daniel Wolk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <15112.38439.368305.374021@iqara.206.64.84.162> Resent-Date: Sun, 20 May 2001 23:14:31 -0500 Resent-To: xemacs-beta@xemacs.org Message-Id: <200105210350.f4L3orS08465@mercury.netcomp.net> Errors-To: xemacs-news-admin@xemacs.org X-BeenThere: xemacs-news@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.emacs.xemacs bi-directional gateway List-Unsubscribe: , X-UIDL: 3bfe8ed2f851c57d7a60091f984685b0 From: "Daniel P. Wolk" To: xemacs@xemacs.org Subject: xemacs crash after quitting vm Date: Sun, 20 May 2001 22:50:53 -0500 (CDT) This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.4 (patch 3) "Academic Rigor" [Lucid] (i686-pc-linux, Mule) of Sun May 20 2001 on iqara configured using `configure --external-widget --with-pop --with-mule --debug' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: When I quit vm with "vm-quit", xemacs crashes. Here is the backtrace from my .X.err file: Lisp backtrace follows: vm-delete-frame(#) apply(vm-delete-frame #) # (condition-case ... . ((error))) # bind (args function) vm-error-free-call(vm-delete-frame #) # bind (wf b w) # (unwind-protect ...) vm-delete-buffer-frame() run-hooks(vm-delete-buffer-frame) # (unwind-protect ...) # bind (wf w) # (unwind-protect ...) # bind (vm-sbe-buffer do-not-raise configs commands display buffer) vm-display(# nil nil nil) # bind (summary-buffer pres-buffer mail-buffer virtual no-change) #() call-interactively(vm-quit) # (condition-case ... . error) # (catch top-level ...) kdeinit: PID 1266 terminated. Recent keystrokes: up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up up next down down down down down down down C-SPC down down down down down down down down down down down down down down down down down down down down down down down down down down down down down down down down down down up up up up up up up up up up up up f5 M-w misc-user Recent messages (most recent first): Parsing /home/wolk/.mailrc... Loading mail-abbrevs...done Loading mail-abbrevs... Loading emacsbug...done Loading emacsbug... Paren mode is sexp Loading paren...done Loading paren... Loading x-symbol...done Loading places from /home/wolk/.emacs-places...done From steve@turnbull.sk.tsukuba.ac.jp Mon May 21 02:33:59 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA08072; Mon, 21 May 2001 02:33:58 -0400 Received: by localhost id m151jGM-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 21 May 2001 15:33:54 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15112.46784.141868.614596@turnbull.sk.tsukuba.ac.jp> Date: Mon, 21 May 2001 15:33:36 +0900 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Steve Youngs , XEmacs Beta Subject: Re: fyi mail-lib status In-Reply-To: References: <4.3.2.7.2.20010519130419.00b13740@san-francisco.beasys.com> <8zjt6oe4.fsf@rapier.ecf.teradyne.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "APA" == Adrian Aichner writes: APA> gnus may have incompatible changes in the future. Yup. APA> I guess my gnus/xemacs.mak logic is still applicable. It's true a name change would break it, but intentionally shadowing a library is dangerous in any case. Even if it works, it makes debugging harder for naive users. If there are other good reasons for forking or recombining or whatever, it may be a good time to reconsider that design. Especially since there are now three or four versions of that particular library (pop.el) floating around, not to mention extended versions, any of which might end up in some user's ~/.xemacs/. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Mon May 21 02:40:55 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA08327 for ; Mon, 21 May 2001 02:40:52 -0400 Received: by localhost id m151jN1-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 21 May 2001 15:40:47 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15112.47200.706852.246287@turnbull.sk.tsukuba.ac.jp> Date: Mon, 21 May 2001 15:40:32 +0900 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: [Success, 1% lisp-tests fail] XEmacs 21.5-b0 "alfalfa", i586-pc-win32 In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid Thanks for following this up, Adrian! >>>>> "APA" == Adrian Aichner writes: APA> MSDN actually documents that exponents are always printed APA> with three digits. Yay, MSDN! APA> What's the preferable way to fix these tests? I prefer fix 1 "(cond ((equal system-type ...) ...) ...)". A,ong other things, if someone else decides to do the same thing, we'll get warning right away, rather than have user code failing for no obvious reason because it expects 2 digit exponents but doesn't get them. I will defer to the experts though. Either patch is acceptable for 21.4. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From sperber@informatik.uni-tuebingen.de Mon May 21 02:53:03 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA08744; Mon, 21 May 2001 02:53:01 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8CA944A5; Mon, 21 May 2001 08:52:59 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4L6qxk32841; Mon, 21 May 2001 08:52:59 +0200 (CEST) (envelope-from sperber) To: Ben Wing Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <3B072505.3B282E7B@666.com> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 21 May 2001 08:52:59 +0200 In-Reply-To: <3B072505.3B282E7B@666.com> (Ben Wing's message of "Sat, 19 May 2001 18:59:33 -0700") Message-ID: Lines: 32 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Thanks for the reports. There's one part I cannot reproduce: >>>>> "Ben" == Ben Wing writes: Ben> third, efs has problems with ftp.microsoft.com: Ben> /ftp.microsoft.com:/ Ben> use f to go to kbhelp, hit f on ~ftpsvc~.ckm, you get a buffer named "® PÔï". I don't. I get (2) (error/warning) Error in process filter: (ftp-error Opening input file: FTP Error: /anonymous@ftp.microsoft.com:/KBHelp/~ftpsvc~.ckm not arrived or readable) ... understandably so, as ftp.microsoft.com says this: ftp> get /KBHelp/~ftpsvc~.ckm /tmp/sperber/efsaKYqBq.ckm get /KBHelp/~ftpsvc~.ckm /tmp/sperber/efsaKYqBq.ckm 200 PORT command successful. 550 /KBHelp/~ftpsvc~.ckm: The system cannot find the file specified. (I also get a correctly named buffer.) Your ftp protocol is only about the other problem. Could you repeat and send the one containing a trace of this problem? Meanwhile, I'll see about the other problems. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From steve@turnbull.sk.tsukuba.ac.jp Mon May 21 02:59:51 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA09003 for ; Mon, 21 May 2001 02:59:48 -0400 Received: by localhost id m151jfA-00014mC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 21 May 2001 15:59:32 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15112.48315.862249.309489@turnbull.sk.tsukuba.ac.jp> Date: Mon, 21 May 2001 15:59:07 +0900 To: "Daniel P. Wolk" Cc: xemacs-beta@xemacs.org Subject: xemacs crash after quitting vm In-Reply-To: <200105210350.f4L3orS08465@mercury.netcomp.net> References: <200105210350.f4L3orS08465@mercury.netcomp.net> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Daniel" == Daniel P Wolk writes: Daniel> When I quit vm with "vm-quit", xemacs crashes. Daniel> Here is the backtrace from my .X.err file: We need a C backtrace. If the crash left a core file, "gdb `which xemacs' core", then "where" will give the backtrace. It _is_ possible to use gdb interactively with "gdb ... | tee gdb.out", except that you can't use the internal pager. If you didn't get a core, do ulimit -c unlimited in bash, then start XEmacs. Of course I'll try to replicate, but these things tend to be intermittent, and if you have a core file already it makes things easier. You can also run xemacs under gdb, but that is annoying and tends to slow things down and may result in memory leaks. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From ben@666.com Mon May 21 03:22:15 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id DAA10345 for ; Mon, 21 May 2001 03:22:06 -0400 Received: (qmail 42395 invoked by alias); 21 May 2001 07:22:00 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 42378 invoked by uid 0); 21 May 2001 07:21:59 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 21 May 2001 07:21:59 -0000 Message-ID: <3B08C274.3D973331@666.com> Date: Mon, 21 May 2001 00:23:32 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael Sperber [Mr. Preprocessor]" CC: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <3B072505.3B282E7B@666.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit never mind, it's a windows problem -- same results by calling expand-file-name on "~ftpsvc~.ckm". btw the log: open ftp.microsoft.com Connected to ftp.microsoft.com. 220 cpmsftftpa03 Microsoft FTP Service (Version 5.0). quote user "anonymous" 331 Anonymous access allowed, send identity (e-mail name) as password. quote pass Turtle Power! 230-This is FTP.MICROSOFT.COM. Please see the 230-dirmap.txt for more information. 230 Anonymous user logged in. hash Hash mark printing on (1024 bytes/hash mark). quote pwd 257 "/" is current directory. quote syst 215 Windows_NT version 5.0 quote cwd / 250 CWD command successful. ls "-al" C:/DOCUME~1/BENWIN~1/LOCALS~1/Temp/efsaVAG6Q 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. # 226 Transfer complete. quote site idle 500 'SITE idle': command not understood quote cwd /KBHelp/ 250 CWD command successful. ls "-al" C:/DOCUME~1/BENWIN~1/LOCALS~1/Temp/efsaVAG6Q 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. # 226 Transfer complete. "Michael Sperber [Mr. Preprocessor]" wrote: > > Thanks for the reports. There's one part I cannot reproduce: > > >>>>> "Ben" == Ben Wing writes: > > Ben> third, efs has problems with ftp.microsoft.com: > > Ben> /ftp.microsoft.com:/ > > Ben> use f to go to kbhelp, hit f on ~ftpsvc~.ckm, you get a buffer named "® PÔï". > > I don't. I get > > (2) (error/warning) Error in process filter: (ftp-error Opening input file: FTP Error: /anonymous@ftp.microsoft.com:/KBHelp/~ftpsvc~.ckm not arrived or readable) > > ... understandably so, as ftp.microsoft.com says this: > > ftp> get /KBHelp/~ftpsvc~.ckm /tmp/sperber/efsaKYqBq.ckm > get /KBHelp/~ftpsvc~.ckm /tmp/sperber/efsaKYqBq.ckm > 200 PORT command successful. > 550 /KBHelp/~ftpsvc~.ckm: The system cannot find the file specified. > > (I also get a correctly named buffer.) > > Your ftp protocol is only about the other problem. Could you repeat > and send the one containing a trace of this problem? > > Meanwhile, I'll see about the other problems. > > -- > Cheers =8-} Mike > Friede, Völkerverständigung und überhaupt blabla -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From Adrian.Aichner@t-online.de Mon May 21 04:54:58 2001 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA15779 for ; Mon, 21 May 2001 04:54:57 -0400 Received: from fwd02.sul.t-online.de by mailout05.sul.t-online.com with smtp id 151lTA-00072G-0E; Mon, 21 May 2001 10:55:16 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.20]) by fwd02.sul.t-online.com with esmtp id 151lTI-0WKcXAC; Mon, 21 May 2001 10:55:24 +0200 To: XEmacs Beta List Subject: [comp.emacs.xemacs] problem with xemacs-21.4.3-gtk X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 64 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Sender: 520002458184-0001@t-dialin.net --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Path: news.t-online.com!newsmm00.sul.t-online.com!newsfeed00.sul.t-online.de!t-online.de!fr.usenet-edu.net!usenet-edu.net!jussieu.fr!univ-lyon1.fr!news.ens-lyon.fr!news.imag.fr!not-for-mail From: Tuan Pham-Dinh Newsgroups: comp.emacs.xemacs Subject: problem with xemacs-21.4.3-gtk Date: 21 May 2001 10:19:19 +0200 Organization: IMAG Lines: 39 Message-ID: NNTP-Posting-Host: guepard.imag.fr X-Trace: trompette.imag.fr 990433622 30082 129.88.33.43 (21 May 2001 08:27:02 GMT) X-Complaints-To: abuse@imag.fr NNTP-Posting-Date: 21 May 2001 08:27:02 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) Xref: news.t-online.com comp.emacs.xemacs:53756 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In my previous post "xemacs-gtk-21.4.3: can't install lisp packages", I report on the problem of using the menu "Tools -> Manage Packages" to install packages. Actually, the problem can be solved by using the keyboard to issue command rather than click on the menu by the mouse. Specifically, clicking on "Tools -> Packages -> List & Install" doesn't work but launching M-x pui-list-packages does. In fact many things related to menu and mouse don't work. For example, using the "File -> Open" menu to open a file yields the error message "Wrong type of argument: string-p, nil". I havn't explored further. Speaking about opening file, it surprises me that the file chooser in xemacs-gtk does not have the same functionality of a file chooser of gtk. In fact one of the main reason I try xemacs-gtk is to get a decent file-chooser, the file chooser of xemacs-21.1.x is _ugly_ and _counter-intuitive_ (it lists files both horizontally and vertically). The file chooser of gtk, as appeared in gtk applications such as gimp, gvim, abiword, gedit ... is one of the best I have ever seen. Not only it has all things one can expect from a modern file chooser, but it can do file completion as well (this difers somewhat from xemacs file completion as the whole path is b=not explicitly shown but only the last part). So I just wonder why xemacs-gtk doesn't used the already avaiblabe file chooser of gtk by invent another of it own, which _doesn't do file completion_ (the file chooser of xemacs-21.1.x, in spite all its defects can do file completion). Further, one of the nice thing in xemacs-gtk is that it provide a similar GUI to other applications (a very important thing for newbee and those coming from the Windows/Mac world). Why xemacs has to do thing in his own way ? Another strange thing in xemacs-gtk is the presenc of a grey band the size of the menubar just below the toolbar, which seems to serve no purpose. It doesn't display text or anything, just occupy my precious space in the screen (and cannot be eliminated). Why ? Thanks for any information -- PHAM Dinh Tuan | e-mail: Dinh-Tuan.Pham@imag.fr Laboratoire de Modelisation et Calcul | Tel: +33 4 76 51 44 23 BP 53, 38041 Grenoble cedex 9 (France) | Fax: +33 4 76 63 12 63 ----------------------------------------------------------------------- --=-=-= -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-115 D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com --=-=-=-- From ben@666.com Mon May 21 05:14:08 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id FAA17165 for ; Mon, 21 May 2001 05:14:03 -0400 Received: (qmail 52764 invoked by alias); 21 May 2001 09:14:01 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 52743 invoked by uid 0); 21 May 2001 09:14:00 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 21 May 2001 09:14:00 -0000 Message-ID: <3B08DCB2.8A048C70@666.com> Date: Mon, 21 May 2001 02:15:30 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael Sperber [Mr. Preprocessor]" CC: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <3B072505.3B282E7B@666.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit mike, are there any plans to support URL-style syntax for EFS? It seems it would be trivial to allow a file of the form ftp://ben@gwyn.tux.org/etc/mail/xemacs/ in place of /ben@gwyn.tux.org:/etc/mail/xemacs/ that way, e.g. when we get an http:// processor, we can edit files [at the least in read-only mode] that way, too. "Michael Sperber [Mr. Preprocessor]" wrote: > > Thanks for the reports. There's one part I cannot reproduce: > > >>>>> "Ben" == Ben Wing writes: > > Ben> third, efs has problems with ftp.microsoft.com: > > Ben> /ftp.microsoft.com:/ > > Ben> use f to go to kbhelp, hit f on ~ftpsvc~.ckm, you get a buffer named "® PÔï". > > I don't. I get > > (2) (error/warning) Error in process filter: (ftp-error Opening input file: FTP Error: /anonymous@ftp.microsoft.com:/KBHelp/~ftpsvc~.ckm not arrived or readable) > > ... understandably so, as ftp.microsoft.com says this: > > ftp> get /KBHelp/~ftpsvc~.ckm /tmp/sperber/efsaKYqBq.ckm > get /KBHelp/~ftpsvc~.ckm /tmp/sperber/efsaKYqBq.ckm > 200 PORT command successful. > 550 /KBHelp/~ftpsvc~.ckm: The system cannot find the file specified. > > (I also get a correctly named buffer.) > > Your ftp protocol is only about the other problem. Could you repeat > and send the one containing a trace of this problem? > > Meanwhile, I'll see about the other problems. > > -- > Cheers =8-} Mike > Friede, Völkerverständigung und überhaupt blabla -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From steve@turnbull.sk.tsukuba.ac.jp Mon May 21 06:08:51 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA20200; Mon, 21 May 2001 06:08:50 -0400 Received: by localhost id m151mTl-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 21 May 2001 18:59:57 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15112.59146.608246.537634@turnbull.sk.tsukuba.ac.jp> Date: Mon, 21 May 2001 18:59:38 +0900 To: Ben Wing Cc: "Michael Sperber [Mr. Preprocessor]" , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS In-Reply-To: <3B08DCB2.8A048C70@666.com> References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Ben" == Ben Wing writes: Ben> mike, are there any plans to support URL-style syntax for Ben> EFS? The last time this was suggested, Stallman trashed it, because it would make it too easy to implement ssh: and scp: protocols etc transparently, and at that time they were too unfree to be allowed to work and play pleasantly with Emacs. :-( I don't know if there would still be resistence from the GNU camp, but there was. Be that as it may.... Mike, check me on this, but I think this is a _bad_ idea. The reason is that EFS installs itself on the file I/O handler hooks and thus transparently emulates local file operation semantics for remote files. All of the problems that we currently have with EFS will seem tiny if this is implemented, because EFS will not have 15 years of error- handling expertise embedded in the code for handling non-FTP protocols. Embedding the capability in EFS is just asking for scads of bug reports. I think it would be preferable to create a new package for doing this. We just don't want to muck with EFS at the moment. It's too critical and too stable. BTW, I have a design and half an implementation for alternative transports for package-get. Alternative transports will use URL syntax, and the EFS transport will also use URL syntax by preference (of course that will be converted to EFS's /user@remotehost:/path syntax internally). Besides EFS, I will implement a sample transport based on url-retrieve from w3. I may do another one based on Kai Grossjohan's tramp, too (but that would just be proof of concept, since typical users won't have ssh access to tux). I think that's a better way to go for the general case too. Mike? BTW, as long as you're here ... given an arbitrary function called by existing package-get code, is there an easy way to check whether it is EFS-infested and needs to be wrapped to use "alternative transports"? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From didier@lrde.epita.fr Mon May 21 06:26:56 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA20836 for ; Mon, 21 May 2001 06:26:55 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id MAA19445 Mon, 21 May 2001 12:24:43 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 151msc-0003Uc-00; Mon, 21 May 2001 12:25:38 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 151mqW-0000Tl-00; Mon, 21 May 2001 12:23:28 +0200 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: XEmacs Beta List Subject: Re: Failure in latest patcher.el References: X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: (Adrian.Aichner@t-online.de's message of "19 May 2001 00:30:02 +0200") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 21 May 2001 12:23:28 +0200 Message-ID: Lines: 29 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id GAA20836 Adrian.Aichner@t-online.de (Adrian Aichner) wrote: > Hi Didier, Ben, All! > > Here's the backtrace I get in > (emacs-version) > "XEmacs 21.1 (patch 14) \"Cuyahoga Valley\" [Lucid] (i386-pc-win32) of > Sun May 13 2001 on D5DC120J" > > with > patcher-version > "2.4" > > Best regards, > > Adrian > > Signaling: (wrong-number-of-arguments # 5) > extent-list(nil nil nil nil patcher-diff) Doesn't look like a bug in Patcher. More a bytecode incompatibility of some sort. Do you use different XEmacs versions with the same patcher.elc for example ? -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From rendhalver@users.sourceforge.net Mon May 21 08:34:43 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA28346; Mon, 21 May 2001 08:34:38 -0400 Received: from ulthwe.dyndns.org (p92-tnt1.brs.ihug.com.au [203.173.188.92]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id WAA23926; Mon, 21 May 2001 22:33:28 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p92-tnt1.brs.ihug.com.au [203.173.188.92] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15113.2642.47840.30771@ulthwe.dyndns.org> Date: Mon, 21 May 2001 22:30:10 +1000 To: "Stephen J. Turnbull" Cc: Ben Wing , "Michael Sperber [Mr. Preprocessor]" , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS In-Reply-To: <15112.59146.608246.537634@turnbull.sk.tsukuba.ac.jp> References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> <15112.59146.608246.537634@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Stephen J. Turnbull writes: > >>>>> "Ben" == Ben Wing writes: > > Ben> mike, are there any plans to support URL-style syntax for > Ben> EFS? > > I think it would be preferable to create a new package for doing > this. We just don't want to muck with EFS at the moment. It's too > critical and too stable. > > BTW, I have a design and half an implementation for alternative > transports for package-get. Alternative transports will use URL > syntax, and the EFS transport will also use URL syntax by preference > (of course that will be converted to EFS's /user@remotehost:/path > syntax internally). i have been considering asking about possible WebDAV support anyone have any problems with this ?? i was thinking of using EPL to do this cause perl has packages for talking to a WebDAV server EPL is a very beta implementation for wrighting (X?)Emacs extentions in perl for those who dont know -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From sperber@informatik.uni-tuebingen.de Mon May 21 08:45:45 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA28944 for ; Mon, 21 May 2001 08:45:40 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id BE58D1060 for ; Mon, 21 May 2001 14:45:36 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4LCjbQ33785; Mon, 21 May 2001 14:45:37 +0200 (CEST) (envelope-from sperber) To: xemacs-beta@xemacs.org Subject: Re: Help test EFS References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 21 May 2001 14:45:37 +0200 In-Reply-To: <3B08DCB2.8A048C70@666.com> (Ben Wing's message of "Mon, 21 May 2001 02:15:30 -0700") Message-ID: Lines: 28 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Ben" == Ben Wing writes: Ben> mike, are there any plans to support URL-style syntax for EFS? It seems it Ben> would be trivial to allow a file of the form Ben> ftp://ben@gwyn.tux.org/etc/mail/xemacs/ Ben> in place of Ben> /ben@gwyn.tux.org:/etc/mail/xemacs/ Ben> that way, e.g. when we get an http:// processor, we can edit files [at the least Ben> in read-only mode] that way, too. This is exactly why EFS is not the right place to do this: it's very ftp-centric, and you want to be able to dispatch to the other protocols as well. In fact, W3 handles exactly the translation needed. All somebody'd have to do is hack up a file-name handler which recognizes URLs and hands them off to W3. So, I think Stephen's assessment is right on the button. My own medium-term planned work on XEmacs is on bugfixing, so it's not really on my list currently. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From stodghil@cs.cornell.edu Mon May 21 09:50:52 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA00478 for ; Mon, 21 May 2001 09:50:52 -0400 Received: from milhouse.cs.cornell.edu.cs.cornell.edu (dhcp99-208.cs.cornell.edu [128.84.99.208]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id JAA22517; Mon, 21 May 2001 09:50:47 -0400 (EDT) Sender: stodghil@milhouse.cs.cornell.edu To: ding@gnus.org, xemacs-beta@xemacs.org Subject: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop From: Paul Stodghill Date: 21 May 2001 09:50:26 -0400 Message-ID: Lines: 37 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Recipe for disaster: milhouse$ uname -a CYGWIN_NT-5.0 MILHOUSE 1.3.1(0.38/3/2) 2001-04-24 20:01 i686 unknown milhouse$ xemacs -vanilla M-: (setq load-path (cons "/path/for/oort-gnus/" load-path)) M-x load-library message M-x message-mail M-x filladapt-mode (insert the following in the body of the message) > this is some citation > text that needs to be filled. (now put the cursor on this text and press) M-q XEmacs enters an infinite loop which cannot be broken with C-g. For the ding list: Oort v0.03 and filladapt don't work together under Cygwin XEmacs. This problem does not exist in 5.8.8. For the xemacs-beta: It would be really nice if C-g broken out of the loop. I realize that this may not be possible, though. Further details o Cygwin 1.3.1, most recent version of everything o Oort Gnus v0.03 o xemacs-21.4.3 and xemacs-21.5-b1, up-to-date with pre-release packages. If there are any other details that you need, please let me know. --- Paul Stodghill Dept. of Computer Science, Upson Hall, Ithaca, NY 14853 Phone: 607-254-8838 FAX: 607-255-4428 http://www.cs.cornell.edu/stodghil/ From hniksic@arsdigita.com Mon May 21 10:10:09 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA01786 for ; Mon, 21 May 2001 10:10:08 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 151qN6-0004YC-00; Mon, 21 May 2001 16:09:20 +0200 Sender: hniksic@florida.arsdigita.de To: Paul Stodghill Cc: ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 21 May 2001 16:09:20 +0200 In-Reply-To: (Paul Stodghill's message of "21 May 2001 09:50:26 -0400") Message-ID: Lines: 13 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Paul Stodghill writes: > XEmacs enters an infinite loop which cannot be broken with C-g. > > For the ding list: Oort v0.03 and filladapt don't work together under > Cygwin XEmacs. This problem does not exist in 5.8.8. I've been seeing this for some time, and it's been extremely annoying. The infinite loop is a Gnus bug, or a filladapt bug triggered by Gnus (but it used to work!) However, the misfunctioning of C-g is an XEmacs bug under Cygwin. On Linux, C-g is able to interrupt the loop. From npak@ispras.ru Mon May 21 10:44:27 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id KAA03824 for ; Mon, 21 May 2001 10:44:23 -0400 Received: (qmail 25533 invoked from network); 21 May 2001 14:43:54 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 21 May 2001 14:43:54 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f4LEiJU17009; Mon, 21 May 2001 18:44:19 +0400 (MSK) Received: tid SAA13609; Tue, 21 May 1996 18:43:30 +0300 Received: from HOOKAH.kasbek.ispras.ru (hookah.kazbek.ispras.ru [194.186.94.160]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f4LEhpg31259; Mon, 21 May 2001 18:43:51 +0400 (MSD) (envelope-from npak@ispras.ru) To: xemacs-nt@xemacs.org, xemacs-beta@xemacs.org, xemacs-patches@xemacs.org Subject: copy command in xemacs.mak From: npak@ispras.ru (Nick Pakoulin) Date: 21 May 2001 18:44:27 +0400 Message-ID: Lines: 87 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii `nmake install -f xemacs.mak' command might take ages to complete on my Windows2000 box because `copy' command asks confirmation to overwrite files in destination folders. I replaced all direct calls to `copy' and `xcopy' commands with COPY and COPYDIR variables. Nick 2001-05-21 Nick V. Pakoulin * xemacs.mak (install): Replace calls to (x)copy commands with COPY and COPYDIR variables. (COPY): New (COPYDIR): New Index: xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.58.2.3 diff -u -r1.58.2.3 xemacs.mak --- xemacs.mak 2001/05/17 13:37:39 1.58.2.3 +++ xemacs.mak 2001/05/21 14:38:20 @@ -48,6 +48,11 @@ # Define a variable for the 'del' command to use DEL=-del +# Define a variable for 'copy' command to use +# Suppress confirmation for overwriting files +COPY=@xcopy /q /y +COPYDIR=@xcopy /q /y /e + # Program name and version !include "$(XEMACS)\version.sh" @@ -502,13 +507,13 @@ $(SRC)\paths.h $(SRC)\config.h: config.h - copy config.h $(SRC) + $(COPY) config.h $(SRC) $(SRC)\Emacs.ad.h: Emacs.ad.h - copy Emacs.ad.h $(SRC) + $(COPY) Emacs.ad.h $(SRC) $(SRC)\paths.h: paths.h - copy paths.h $(SRC) + $(COPY) paths.h $(SRC) #------------------------------------------------------------------------------ @@ -1411,22 +1416,22 @@ cd $(NT) @echo Installing in $(INSTALL_DIR) ... @echo PlaceHolder > PlaceHolder - @xcopy /q PROBLEMS "$(INSTALL_DIR)\" - @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" + $(COPY) PROBLEMS "$(INSTALL_DIR)\" + $(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" - @xcopy /q $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" - @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" - @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" - @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" - @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" - @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" - @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" + $(COPY) $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" + $(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" + $(COPY) $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" + $(COPY) $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" + $(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" + $(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" + $(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" $(DEL) PlaceHolder From Olivier.Fambon@inrialpes.fr Mon May 21 11:01:31 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA04831 for ; Mon, 21 May 2001 11:01:30 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id RAA09248; Mon, 21 May 2001 17:00:12 +0200 (MEST) Received: from inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f4LF1Pd02001; Mon, 21 May 2001 17:01:26 +0200 (MEST) Message-ID: <3B092ED2.F390356F@inrialpes.fr> Date: Mon, 21 May 2001 17:05:54 +0200 From: Olivier Fambon X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: Paul Stodghill , ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hrvoje Niksic wrote: > ... > > However, the misfunctioning of C-g is an XEmacs bug under Cygwin. On > Linux, C-g is able to interrupt the loop. It seems they are having troubles with signals at cygnus, at least with blocking socket calls. Some might be fixed in the next DLL release. See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a' reply http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html In case it might avoid headaches... A+O. From stodghil@cs.cornell.edu Mon May 21 11:16:05 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA05451 for ; Mon, 21 May 2001 11:16:05 -0400 Received: from milhouse.cs.cornell.edu.cs.cornell.edu (dhcp99-208.cs.cornell.edu [128.84.99.208]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA26991; Mon, 21 May 2001 11:15:47 -0400 (EDT) Sender: stodghil@milhouse.cs.cornell.edu To: Olivier Fambon Cc: Hrvoje Niksic , ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B092ED2.F390356F@inrialpes.fr> From: Paul Stodghill In-Reply-To: <3B092ED2.F390356F@inrialpes.fr> (Olivier Fambon's message of "Mon, 21 May 2001 17:05:54 +0200") Date: 21 May 2001 11:15:28 -0400 Message-ID: Lines: 12 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > It seems they are having troubles with signals at cygnus, at least with > blocking socket calls. Some might be fixed in the next DLL release. > > See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a' > reply > http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html > > > In case it might avoid headaches... I just downloaded and tried cygwin1-20010519.dll and I am still unable to C-g my problems away.... From andyp@bea.com Mon May 21 11:59:58 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA09027 for ; Mon, 21 May 2001 11:59:57 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA14227; Mon, 21 May 2001 09:00:04 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA07936; Mon, 21 May 2001 09:00:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20010521085846.00d69180@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 09:00:41 -0700 To: Les Schaffer , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Font locking bug - infinite loop In-Reply-To: <15112.34899.890000.841157@gargle.gargle.HOWL> References: <4.3.2.7.2.20010520194911.00b16290@san-francisco.beasys.com> <15112.30655.703000.237424@gargle.gargle.HOWL> <4.3.2.7.2.20010520194911.00b16290@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:15 PM 5/20/01 -0400, Les Schaffer wrote: > > Does this happen if you switch off the progress gauge? > >with progress-feedback-use-echo-area t, the infinite loop does NOT >occur (even with font-lock-default-fontify-buffer left untouched). I have a feeling that font-lock makes assumptions about the event loop not being run while its setting itself up - this used to be the case, but unfortunately for widgets you have to go through the event loop to get them displayed properly. Therefore there is probably some hook that is being run which starts font=lock while it is already being font-locked. Seems like we need to temporarily disable all the hooks until font lock completes. andy From andyp@bea.com Mon May 21 12:01:29 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA09280 for ; Mon, 21 May 2001 12:01:16 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA14495; Mon, 21 May 2001 09:01:22 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA08281; Mon, 21 May 2001 09:01:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20010521090137.00d5c920@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 09:01:59 -0700 To: "Stephen J. Turnbull" , "Daniel P. Wolk" From: Andy Piper Subject: Re: xemacs crash after quitting vm Cc: xemacs-beta@xemacs.org In-Reply-To: <15112.48315.862249.309489@turnbull.sk.tsukuba.ac.jp> References: <200105210350.f4L3orS08465@mercury.netcomp.net> <200105210350.f4L3orS08465@mercury.netcomp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I bet a beer that this is the XtRemoveGrab problem andy At 03:59 PM 5/21/01 +0900, Stephen J. Turnbull wrote: > >>>>> "Daniel" == Daniel P Wolk writes: > > Daniel> When I quit vm with "vm-quit", xemacs crashes. > > Daniel> Here is the backtrace from my .X.err file: > >We need a C backtrace. If the crash left a core file, "gdb `which >xemacs' core", then "where" will give the backtrace. It _is_ possible >to use gdb interactively with "gdb ... | tee gdb.out", except that >you can't use the internal pager. > >If you didn't get a core, do ulimit -c unlimited in bash, then start >XEmacs. > >Of course I'll try to replicate, but these things tend to be >intermittent, and if you have a core file already it makes things >easier. > >You can also run xemacs under gdb, but that is annoying and tends to >slow things down and may result in memory leaks. > > >-- >University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN >Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 >_________________ _________________ _________________ _________________ >What are those straight lines for? "XEmacs rules." From andyp@bea.com Mon May 21 12:02:32 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA09614; Mon, 21 May 2001 12:02:27 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA14718; Mon, 21 May 2001 09:02:30 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA08515; Mon, 21 May 2001 09:02:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20010521090254.00d624b0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 09:03:06 -0700 To: Ben Wing , "Michael Sperber [Mr. Preprocessor]" From: Andy Piper Subject: Re: Help test EFS Cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org In-Reply-To: <3B08DCB2.8A048C70@666.com> References: <3B072505.3B282E7B@666.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:15 AM 5/21/01 -0700, Ben Wing wrote: >mike, are there any plans to support URL-style syntax for EFS? It seems it >would be trivial to allow a file of the form > >ftp://ben@gwyn.tux.org/etc/mail/xemacs/ This would be way cool. andy From andyp@bea.com Mon May 21 12:04:47 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA10192; Mon, 21 May 2001 12:04:47 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA15298; Mon, 21 May 2001 09:04:54 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA09505; Mon, 21 May 2001 09:04:54 -0700 (PDT) Message-Id: <4.3.2.7.2.20010521090517.00d63460@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 09:05:30 -0700 To: npak@ispras.ru (Nick Pakoulin), xemacs-nt@xemacs.org, xemacs-beta@xemacs.org, xemacs-review@xemacs.org From: Andy Piper Subject: Re: copy command in xemacs.mak In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reviewed and approved andy At 06:44 PM 5/21/01 +0400, Nick Pakoulin wrote: >`nmake install -f xemacs.mak' command might take ages to complete on my >Windows2000 box because `copy' command asks confirmation to overwrite files in >destination folders. > >I replaced all direct calls to `copy' and `xcopy' commands with COPY and >COPYDIR variables. > >Nick > >2001-05-21 Nick V. Pakoulin > > * xemacs.mak (install): Replace calls to (x)copy commands with > COPY and COPYDIR variables. > (COPY): New > (COPYDIR): New > >Index: xemacs.mak >=================================================================== >RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v >retrieving revision 1.58.2.3 >diff -u -r1.58.2.3 xemacs.mak >--- xemacs.mak 2001/05/17 13:37:39 1.58.2.3 >+++ xemacs.mak 2001/05/21 14:38:20 >@@ -48,6 +48,11 @@ > # Define a variable for the 'del' command to use > DEL=-del > >+# Define a variable for 'copy' command to use >+# Suppress confirmation for overwriting files >+COPY=@xcopy /q /y >+COPYDIR=@xcopy /q /y /e >+ > # Program name and version > > !include "$(XEMACS)\version.sh" >@@ -502,13 +507,13 @@ > $(SRC)\paths.h > > $(SRC)\config.h: config.h >- copy config.h $(SRC) >+ $(COPY) config.h $(SRC) > > $(SRC)\Emacs.ad.h: Emacs.ad.h >- copy Emacs.ad.h $(SRC) >+ $(COPY) Emacs.ad.h $(SRC) > > $(SRC)\paths.h: paths.h >- copy paths.h $(SRC) >+ $(COPY) paths.h $(SRC) > > >#------------------------------------------------------------------------------ > >@@ -1411,22 +1416,22 @@ > cd $(NT) > @echo Installing in $(INSTALL_DIR) ... > @echo PlaceHolder > PlaceHolder >- @xcopy /q PROBLEMS "$(INSTALL_DIR)\" >- @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" >+ $(COPY) PROBLEMS "$(INSTALL_DIR)\" >+ $(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" > $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" >- @xcopy /q $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" >- @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >- @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >- @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >- @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" >- @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" >- @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" >+ $(COPY) $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" >+ $(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >+ $(COPY) $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >+ $(COPY) $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >+ $(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" >+ $(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" >+ $(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... >- @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" >+ $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" >- @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" >+ $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" >- @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" >+ $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" > $(DEL) PlaceHolder > From andyp@bea.com Mon May 21 12:06:52 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA10492 for ; Mon, 21 May 2001 12:06:52 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA15937; Mon, 21 May 2001 09:06:58 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id JAA09907; Mon, 21 May 2001 09:06:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20010521090646.00d66480@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 09:07:34 -0700 To: Paul Stodghill , Olivier Fambon From: Andy Piper Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop Cc: Hrvoje Niksic , ding@gnus.org, xemacs-beta@xemacs.org In-Reply-To: References: <3B092ED2.F390356F@inrialpes.fr> <3B092ED2.F390356F@inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:15 AM 5/21/01 -0400, Paul Stodghill wrote: > > It seems they are having troubles with signals at cygnus, at least with > > blocking socket calls. Some might be fixed in the next DLL release. > > > > See http://sources.redhat.com/ml/cygwin/2001-05/msg00570.html and 'a' > > reply > > http://sources.redhat.com/ml/cygwin/2001-05/msg00752.html > > > > > > In case it might avoid headaches... > >I just downloaded and tried cygwin1-20010519.dll and I am still unable to >C-g my problems away.... Try defining BROKEN_SIGIO in your s/cygwin32.h and see how that goes. It will enable C-g but led to random lockups last time I tried it. But we need a crash test dummy .... andy From mdb@sammy.nwest.attws.com Mon May 21 13:05:03 2001 Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA16595; Mon, 21 May 2001 13:04:50 -0400 Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id KAA08325; Mon, 21 May 2001 10:01:55 -0700 (PDT) Received: from nwestmail.entp.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id KAA10456; Mon, 21 May 2001 10:03:40 -0700 (PDT) Received: from sammy.nwest.attws.com ([155.176.120.226]) by nwestmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id KAA12617; Mon, 21 May 2001 10:03:39 -0700 (PDT) Received: from mdb by sammy.nwest.attws.com with local (Exim 3.12 #1 (Debian)) id 151t5c-0002VF-00; Mon, 21 May 2001 10:03:28 -0700 To: "Stephen J. Turnbull" Cc: Ben Wing , "Michael Sperber [Mr. Preprocessor]" , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS Reply-To: mdb@jimi.nwest.attws.com References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> <15112.59146.608246.537634@turnbull.sk.tsukuba.ac.jp> Organization: AT&T Wireless Services, Inc X-Attribution: mb From: Mark Borges Date: 21 May 2001 10:03:28 -0700 In-Reply-To: <15112.59146.608246.537634@turnbull.sk.tsukuba.ac.jp> Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Mark Borges >> On Mon, 21 May 2001 18:59:38 +0900, >> Stephen J Turnbull(S) wrote: >>>>>> "Ben" == Ben Wing writes: Ben> mike, are there any plans to support URL-style syntax for Ben> EFS? S> I think it would be preferable to create a new package for doing S> this. We just don't want to muck with EFS at the moment. It's too S> critical and too stable. I've been using Grigni's find-file-at-point (ffap.el), ftp://ftp.mathcs.emory.edu/pub/mic/emacs/ffap-1.9-gen.el (also part of xemacs-base, I believe). Granted, it's quite old (created circa 1993), and may be considered obsolete by now, but it still works for me in conjunction with EFS and doing the translations I frequently come across. -- -mb- From stodghil@cs.cornell.edu Mon May 21 15:14:25 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA29708 for ; Mon, 21 May 2001 15:14:24 -0400 Received: from milhouse.cs.cornell.edu.cs.cornell.edu (d2017.dialup.cornell.edu [132.236.155.17]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id PAA25633; Mon, 21 May 2001 15:14:13 -0400 (EDT) Sender: stodghil@milhouse.cs.cornell.edu To: Andy Piper Cc: ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B092ED2.F390356F@inrialpes.fr> <3B092ED2.F390356F@inrialpes.fr> <4.3.2.7.2.20010521090646.00d66480@san-francisco.beasys.com> From: Paul Stodghill In-Reply-To: <4.3.2.7.2.20010521090646.00d66480@san-francisco.beasys.com> (Andy Piper's message of "Mon, 21 May 2001 09:07:34 -0700") Message-ID: Date: 21 May 2001 15:13:51 -0400 Lines: 12 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Try defining BROKEN_SIGIO in your s/cygwin32.h and see how that goes. It will > enable C-g but led to random lockups last time I tried it. I installed and tried cygwin 1.3.2 (I presume that this has the signals changes that were mentioned before). C-g still doesn't work. I put "#define BROKEN_SIGIO" as the very first line in s/cygwin32.h, did a "make clean ; make". C-g _still_ doesn't work. > But we need a crash test dummy .... I think that I'll put this on my resume. Yow! From stodghil@cs.cornell.edu Mon May 21 15:14:26 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA29715 for ; Mon, 21 May 2001 15:14:26 -0400 Received: from milhouse.cs.cornell.edu.cs.cornell.edu (d2017.dialup.cornell.edu [132.236.155.17]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id PAA26132; Mon, 21 May 2001 15:14:24 -0400 (EDT) Sender: stodghil@milhouse.cs.cornell.edu To: Andy Piper Cc: ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B092ED2.F390356F@inrialpes.fr> <3B092ED2.F390356F@inrialpes.fr> <4.3.2.7.2.20010521090646.00d66480@san-francisco.beasys.com> From: Paul Stodghill In-Reply-To: (Paul Stodghill's message of "21 May 2001 14:37:12 -0400") Message-ID: Date: 21 May 2001 15:14:03 -0400 Lines: 80 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit I managed to get a backtrace by sending HUP to a xemacs-21.5-b1 process that was in an infloop. Here it is, milhouse$ xemacs-21.5-b1 [1]+ Stopped xemacs-21.5-b1 milhouse$ bg [1]+ xemacs-21.5-b1 & milhouse$ kill -1 %1 milhouse$ Fatal error (1). Your files have been auto-saved. Use `M-x recover-session' to recover them. If you have access to the PROBLEMS file that came with your version of XEmacs, please check to see if your crash is described there, as there may be a workaround available. Otherwise, please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes@xemacs.org'. *MAKE SURE* to include the information in the command M-x describe-installation. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started the editor, or maybe in your home directory), and type gdb /usr/local/bin/xemacs-21.5-b1.exe core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: looking-at("--text follows this line--$\\|[ ]*$\\|-- $\\|---+$\\|^?$\\|.*wro te:$\\|\\(\\([ ]*\\(\\w\\|[-_.]\\)+>+\\|[ ]*[]>»|:}+]\\)+\\)[ ]*$") # bind (quoted point beg end leading-space bolp not-break arg) message-newline-and-reformat(nil t) # bind (arg) message-fill-paragraph(nil) # bind (function fill-paragraph-function arg) #(nil) apply(# nil) # bind (args function) filladapt-funcall(fill-paragraph nil) # bind (paragraph-ignore-fill-prefix adaptive-fill-mode adaptive-fill-regexp c omment-multi-line fill-prefix retval) # (unwind-protect ...) byte-code("..." [function done retval sign delta fill-column nil t filladapt-a dapt 1 0 filladapt-funcall filladapt-paragraph-within-fill-tolerance success run -hooks filladapt-fill-paragraph-post-hook throw arg low high lim fill-prefix old -fill-column filladapt-mode comment-multi-line adaptive-fill-regexp adaptive-fil l-mode paragraph-ignore-fill-prefix filladapt-fill-column-tolerance filladapt-fi ll-column-backward-fuzz filladapt-fill-column-forward-fuzz] 7) # (catch done ...) # bind (arg function) filladapt-fill-paragraph(fill-paragraph nil) # bind (filladapt-inside-filladapt arg) fill-paragraph(nil) # bind (command-debug-status) call-interactively(fill-paragraph) # bind (arg) fill-paragraph-or-region(nil) # bind (command-debug-status) call-interactively(fill-paragraph-or-region) # (condition-case ... . error) # (catch top-level ...) From Adrian.Aichner@t-online.de Mon May 21 16:12:47 2001 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA06209; Mon, 21 May 2001 16:12:47 -0400 Received: from fwd02.sul.t-online.de by mailout01.sul.t-online.com with smtp id 151w38-0003vu-0C; Mon, 21 May 2001 22:13:06 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.5]) by fwd02.sul.t-online.com with esmtp id 151w3D-1DIeLgC; Mon, 21 May 2001 22:13:11 +0200 To: Martin Buchholz Cc: Adrian.Aichner@t-online.de (Adrian Aichner), xemacs-beta@xemacs.org Subject: Re: [Success, 1% lisp-tests fail] XEmacs 21.5-b0 "alfalfa", i586-pc-win32 References: <15112.28014.790096.635334@gargle.gargle.HOWL> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 69 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Martin" == Martin Buchholz writes: >>>>> "APA" == Adrian Aichner writes: APA> These test fails because my system prints 3 digits for the exponent: APA> (format "%e" 100) APA> "1.000000e+002" APA> MSDN actually documents that exponents are always printed with three APA> digits. APA> What's the preferable way to fix these tests? APA> 1. APA> (cond APA> ((equal system-type 'windows-nt) APA> (Assert (string= (format "%e" 100) "1.000000e+002"))) APA> (t APA> (Assert (string= (format "%e" 100) "1.000000e+02")))) APA> 2. APA> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100) 0)) Martin> I vote for 2. Except that the 3rd arg to string-match Martin> seems unnecessary. Martin> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100))) Martin, for maintainability (regexps are pretty easily screwed up, I have used the fix of perl, grep, XEmacs for too long) I would prefer 1. Would it be OK with you if generated a patch grouping all %[eEgG] together in on (cond ...) and adding your comment from below? Best regards, Adrian Martin> Of course, a comment should be added. Martin> Microsoft's implementation is not standard compliant. From the standard: Martin> e,E A double argument representing a floating-point Martin> number is converted in the style [-]d.ddde_dd, where Martin> there is one digit before the decimal-point Martin> character (which is nonzero if the argument is Martin> nonzero) and the number of digits after it is equal Martin> to the precision; if the precision is missing, it is Martin> taken as 6; if the precision is zero and the # flag Martin> is not specified, no decimal-point character Martin> appears. The value is rounded to the appropriate Martin> number of digits. The E conversion specifier will Martin> produce a number with E instead of e introducing the Martin> =====> exponent. The exponent always contains at least two Martin> =====> digits, and only as many more digits as necessary to Martin> represent the exponent. If the value is zero, the Martin> exponent is zero. Martin> A double argument representing an infinity or a NaN Martin> is converted in the style of an f or F conversion Martin> specifier. Martin> So the truly correct thing to do is for (format) to remove the extra Martin> zero digit, but only on Microsoft platforms. Probably not worth it. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From Adrian.Aichner@t-online.de Mon May 21 16:21:47 2001 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA06684; Mon, 21 May 2001 16:21:46 -0400 Received: from fwd02.sul.t-online.de by mailout06.sul.t-online.com with smtp id 151wBc-0000CE-00; Mon, 21 May 2001 22:21:52 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.5]) by fwd02.sul.t-online.com with esmtp id 151wBg-09uJG4C; Mon, 21 May 2001 22:21:56 +0200 To: Andy Piper Cc: npak@ispras.ru (Nick Pakoulin), xemacs-nt@xemacs.org, xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: copy command in xemacs.mak References: <4.3.2.7.2.20010521090517.00d63460@san-francisco.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 124 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Andy" == Andy Piper writes: Andy> Reviewed and approved Andy> andy Hello Nick, I recently did a similar thing for $(DEL). Here is what I learned (with help from Ben and Stephen): Keep @ and - flags outside of the variable definition as they would break inside @if exist $(SRC)\dump-id.c $(DEL) $(SRC)\dump-id.c Could you please rewrite your patch to produce this: COPY=xcopy /q /y COPYDIR=xcopy /q /y /e ... @$(COPY) config.h $(SRC) ... Best regards, Adrian Andy> At 06:44 PM 5/21/01 +0400, Nick Pakoulin wrote: >> `nmake install -f xemacs.mak' command might take ages to complete on my >> Windows2000 box because `copy' command asks confirmation to overwrite files in >> destination folders. >> >> I replaced all direct calls to `copy' and `xcopy' commands with COPY and >> COPYDIR variables. >> >> Nick >> >> 2001-05-21 Nick V. Pakoulin >> >> * xemacs.mak (install): Replace calls to (x)copy commands with >> COPY and COPYDIR variables. >> (COPY): New >> (COPYDIR): New >> >> Index: xemacs.mak >> =================================================================== >> RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v >> retrieving revision 1.58.2.3 >> diff -u -r1.58.2.3 xemacs.mak >> --- xemacs.mak 2001/05/17 13:37:39 1.58.2.3 >> +++ xemacs.mak 2001/05/21 14:38:20 >> @@ -48,6 +48,11 @@ >> # Define a variable for the 'del' command to use >> DEL=-del >> >> +# Define a variable for 'copy' command to use >> +# Suppress confirmation for overwriting files >> +COPY=@xcopy /q /y >> +COPYDIR=@xcopy /q /y /e >> + >> # Program name and version >> >> !include "$(XEMACS)\version.sh" >> @@ -502,13 +507,13 @@ >> $(SRC)\paths.h >> >> $(SRC)\config.h: config.h >> - copy config.h $(SRC) >> + $(COPY) config.h $(SRC) >> >> $(SRC)\Emacs.ad.h: Emacs.ad.h >> - copy Emacs.ad.h $(SRC) >> + $(COPY) Emacs.ad.h $(SRC) >> >> $(SRC)\paths.h: paths.h >> - copy paths.h $(SRC) >> + $(COPY) paths.h $(SRC) >> >> #------------------------------------------------------------------------------ >> >> @@ -1411,22 +1416,22 @@ >> cd $(NT) >> @echo Installing in $(INSTALL_DIR) ... >> @echo PlaceHolder > PlaceHolder >> - @xcopy /q PROBLEMS "$(INSTALL_DIR)\" >> - @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" >> + $(COPY) PROBLEMS "$(INSTALL_DIR)\" >> + $(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" >> $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" >> - @xcopy /q $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" >> - @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >> - @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >> - @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >> - @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" >> - @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" >> - @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" >> + $(COPY) $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" >> + $(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >> + $(COPY) $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >> + $(COPY) $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" >> + $(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" >> + $(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" >> + $(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" >> @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... >> - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" >> + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" >> $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" >> - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" >> + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" >> $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" >> - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" >> + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" >> $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" >> $(DEL) PlaceHolder >> -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From ovidiu@orion.nsr.hp.com Mon May 21 16:31:12 2001 Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA07621 for ; Mon, 21 May 2001 16:31:12 -0400 Received: from orion.nsr.hp.com (orion.nsr.hp.com [15.47.171.122]) by palrel2.hp.com (Postfix) with ESMTP id A2B55169B for ; Mon, 21 May 2001 13:31:07 -0700 (PDT) Received: (from ovidiu@localhost) by orion.nsr.hp.com (8.9.3/8.9.3/client.cv) id NAA23483; Mon, 21 May 2001 13:31:06 -0700 Message-Id: <200105212031.NAA23483@orion.nsr.hp.com> X-Mailer: exmh 2.2 06/23/2000 with XEmacs 21.1.14 on Linux 2.2.13 From: Ovidiu Predescu To: xemacs-beta@xemacs.org Subject: Re: texinfo mode frustrations In-Reply-To: Your message of "Fri, 18 May 2001 23:42:39 PDT." <200105190642.XAA09801@hercules.home> X-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ X-Image-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ovidiu.tiff X-Face: ?(@Y~qjBA}~8ZMh5gM4{Q{bE_*:sCJ3@Z?{B*Co=J!#8bb~-z?-0._vJjt~MM59!MjxG%>U 5>MW^2-\7~z04buszR^=m^U|m66>FdR@cFwhb;.A(8*D.QmLkK]z,md0'HiOE\pyeiv_PACR+P:Cm. wq_%l':E:q]g-UCc>r&s@BVo'kFN;(\9PF22Myg5w%nUBWQ6MJJ#qL#w>2oxckP'H:\$9F"mxsz]Dg k{1`fTcP'Y$CgGnc^paTV$dzhVX+;(U$;Eb)P<>G)g) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2001 13:31:06 -0700 Sender: ovidiu@orion.nsr.hp.com I found what the problem was. My document had the top node declared as: @node Top By looking at the code, it turns out the texinfo mode is very strict about the name of the top node. It only accepts @node top with the "top" name all lowercase. This was the cause of all my problems, after fixing it, everything started working as expected. It would be nice to modify the regexp to also match "Top" in addition to "top", especially since the info documentation for texinfo uses the capitalized version in all its examples. Ovidiu On Fri, 18 May 2001 23:42:39 -0700, Ovidiu Predescu wrote: > Hi, > > I'm getting really frustrated by the way the texinfo mode works, and I > was wondering if it's only me that has these problems. > > Essentially I try to use the texinfo mode to update all the nodes in > my document. The basic pattern I follow is to outline the general > structure of the document first, and then start working on each > individual chapter. Each chapter has its own sections, subsections and > so on. At the time of outlining the structure of the document I don't > necessarily know all the section names. So I find myself very often in > need for introducing a new section in between two others. > > I'd like to use the texinfo mode to automatically update the node > pointers, using the texinfo-every-node-update and > texinfo-all-menus-update. However this seems to not work as > expected. For example it forgets to add pointers to the top node, and > sometimes even to the next or previous node. Even if I explicitly > write them, the next time I run the command it will remove them. So > what I ended up doing is not use the command altogether, and editing > the node pointers manually. Very unproductive! > > Needless to say, when I run such a document file through makeinfo or > texinfo, I get tons of complains about missing node pointers. Anybody > else seeing this, or am I doing something stupid here? From nix@esperi.demon.co.uk Mon May 21 17:31:52 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA14777 for ; Mon, 21 May 2001 17:31:49 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA05103 for ; Mon, 21 May 2001 22:30:59 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id WAA26056; Mon, 21 May 2001 22:30:57 +0100 Sender: nix@esperi.demon.co.uk To: xemacs-beta@xemacs.org Subject: Forthcoming revisions to the garbage collector; crazy huge hack X-Emacs: it's not slow --- it's stately. From: Nix Date: 21 May 2001 22:30:52 +0100 Message-ID: <87k83al78z.fsf@loki.wkstn.nix> Lines: 79 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm currently in the middle of a hack of crazy size, jumping in at the deep end of XEmacs development, in order to familiarize myself with all the code. I'm doing what should have been done a *long* time ago; ditching the garbage collector and replacing it with a nicer one. I think everyone can agree that XEmacs's garbage collector currently sucks really rather hard; I don't think there are any ways to worsen its VM behaviour or intrusiveness if we tried. The one I've picked is the Boehm collector; it's not terribly portable, but that can be fixed fairly easily --- and it lets us dump bloody GCPRO and all the uglinesses it has spawned over the years (blocking string compaction, Lispification in redisplay and many other things). The Boehm collector only has one downside that I can see; unportability (it's not portable to some of the more obscure platforms that XEmacs runs on). Upsides include: - better VM behaviour (mark bits kept in a bitmap, and GC_malloc_atomic() to state that certain kinds of objects cannot contain pointers). As it is most of XEmacs is forced to stay memory-resident all the time by mark bit setting; that proportion will reduce to just those parts that contain pointers that must be traced. This is my primary motivation for this because I run XEmacs on some fairly memory-poor machines and I'm fed up of waiting for bloody GC to finish. - mark bit sanity; we can reclaim at least one bit from many objects, and might even get lightweight cons cells back (I'm not sure if one bit saved is enough for that though). Certainly we can junk the myriad different ways we have to mark things; this is very much improved recently but the boehm-gc can fix it completely - (on some platforms) full incrementality/generationality; we can say a near-total goodbye to GC delays on those platforms - the death of GCPRO, and therefore probably also of gc_currently_forbidden and similar variables. This is my other major motivation; portable though it is, I *hate* GCPRO with a passion. (Besides, walking the stack is not that unportable; the unportabilities in the Boehm collector are in other areas, like incremental collection.) - and last but not least, it's written and actively maintained by someone who's very accessible and who's one of the best GC hackers there is, and it is itself acknowledged as probably the best general-purpose C garbage collector in existence. Plus, I think it's a fun hack. I'm implementing it in such a way that the tying of the specific GC implementation to Emacs is light; much lighter than the current one's. So if everyone else thinks the boehm-gc sucks, you can just rip it out and use the infrastructure left behind. (btw, I think we should under no circumstances implement a copying collector; they get less and less impressive the bigger the heap and the longer-lived its objects, and XEmacs has a large heap and a very large set of long-lived objects, mainly thanks to the obarray.) I'll be paying *no* attention to unexec() and friends in this, at least at first; I'll keep the portable dumper working, but if unexec() is totally broken by some interaction with the boehm gc, I will not mourn unduly. I'm doing the changes to 21.4.3 at first, because I know it's pretty stable otherwise, so that any crashes I may encounter are my fault. Once I've got it working fairly stably in there, I'll post the patches (and yes, I'll split the patches up into pieces; I don't want the GCPRO-removal to drown out the interesting stuff) and let everyone rip into them... and then I guess I'll forward-port it to 2.5, and everyone can let GCPRO fade into the mists of memory (maybe with the aid of a psychiatrist). -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From Adrian.Aichner@t-online.de Mon May 21 17:45:01 2001 Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA16677 for ; Mon, 21 May 2001 17:44:59 -0400 Received: from fwd02.sul.t-online.de by mailout00.sul.t-online.com with smtp id 151xU2-0000kj-05; Mon, 21 May 2001 23:44:58 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.5]) by fwd02.sul.t-online.com with esmtp id 151xUS-07sMrIC; Mon, 21 May 2001 23:45:24 +0200 To: XEmacs Beta List Subject: [comp.emacs.xemacs] gtk support broken X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Sender: 520002458184-0001@t-dialin.net --=-=-= Content-Type: message/rfc822 Content-Disposition: inline x-uunet-gateway: chi6sosrv11.alter.net from xemacs to comp.emacs.xemacs; Mon, 21 May 2001 20:54:04 GMT From: vijay@Zambeel.com (Vijay Ramachandran) Date: Mon, 21 May 2001 13:53:53 -0700 Message-ID: <200105212053.NAA01874@shakti.zambeel.com> Subject: gtk support broken Newsgroups: comp.emacs.xemacs Path: news.t-online.com!newsmm00.sul.t-online.com!newsfeed01.sul.t-online.de!t-online.de!lnewspeer00.lnd.ops.eu.uu.net!emea.uu.net!zur.uu.net!ash.uu.net!spool1.news.uu.net!wendy-fate.uu.net!xemacs Sender: xemacs-request@xemacs.org Lines: 24 Xref: news.t-online.com comp.emacs.xemacs:53767 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.4 (patch 2) "Developer-Friendly Unix APIs" [Lucid] (i686-pc-linux) of Mon May 21 2001 on shakti, configured using `configure --prefix=/usr --with-gtk --with-gnome' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: The support for gtk version 1.2.9 (and 1.2.10) is broken. 1. The scrollbars does not appear - there is space for it on the frame, but it is blank. The same is also true of the buffer-tab on the top of the frame. This may be a bug in gtk? Please see http://bugzilla.gnome.org/show_bug.cgi?id=52922 2. Changing font sizes using the options menu does not work when a new size is selected, with a "not a number" error message. There is no problem if I build xemacs without gtk support. thanks, Vijay --=-=-= -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-115 D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com --=-=-=-- From ovidiu@orion.nsr.hp.com Mon May 21 18:07:16 2001 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA19212 for ; Mon, 21 May 2001 18:07:16 -0400 Received: from orion.nsr.hp.com (orion.nsr.hp.com [15.47.171.122]) by atlrel1.hp.com (Postfix) with ESMTP id A2B1510E9; Mon, 21 May 2001 18:07:14 -0400 (EDT) Received: (from ovidiu@localhost) by orion.nsr.hp.com (8.9.3/8.9.3/client.cv) id PAA25763; Mon, 21 May 2001 15:07:12 -0700 Message-Id: <200105212207.PAA25763@orion.nsr.hp.com> X-Mailer: exmh 2.2 06/23/2000 with XEmacs 21.1.14 on Linux 2.2.13 From: Ovidiu Predescu To: Nix Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: Your message of "21 May 2001 22:30:52 BST." <87k83al78z.fsf@loki.wkstn.nix> X-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ X-Image-Url: http://www.geocities.com/SiliconValley/Monitor/7464/ovidiu.tiff X-Face: ?(@Y~qjBA}~8ZMh5gM4{Q{bE_*:sCJ3@Z?{B*Co=J!#8bb~-z?-0._vJjt~MM59!MjxG%>U 5>MW^2-\7~z04buszR^=m^U|m66>FdR@cFwhb;.A(8*D.QmLkK]z,md0'HiOE\pyeiv_PACR+P:Cm. wq_%l':E:q]g-UCc>r&s@BVo'kFN;(\9PF22Myg5w%nUBWQ6MJJ#qL#w>2oxckP'H:\$9F"mxsz]Dg k{1`fTcP'Y$CgGnc^paTV$dzhVX+;(U$;Eb)P<>G)g) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 May 2001 15:07:12 -0700 Sender: ovidiu@orion.nsr.hp.com This sounds like a really fun project! Although I don't have experience with XEmacs internals, about three years ago I worked on integrating the GNU Objective-C runtime system with Boehm's garbage collector. Objective-C is one of the, until recently, three languages supported by GCC, and is a C based, object oriented language, very dynamic in nature, originally modeled after Smalltalk. Based on this work, I modified two rather large libraries I worked on at that time, to use the new memory management system. What I used to describe the layout of the memory was the so-called typed memory, which allows one to describe exactly what is the memory layout of a class or structure. Essentially this tell the GC where are the pointers in your data structures, and gives the GC a very fast way to skip over unwanted data. It turns out however that describing memory layout however is not an easy task. Different machines have different memory layouts and getting this right is very machine dependent. Currently the piece of code that determines the memory layout (which in turn is used to describe the typed memory for Boehm's GC) is the most problematic and causes the most headaches in the GNU Objective-C runtime library. Just a word of caution if you decide to use typed memory. You may want to take a look at the GCC code in the Objective-C runtime library, to see how things are done. Checkout gc.c and encoding.c in the libobjc directory: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ Regards, -- Ovidiu Predescu http://orion.nsr.hp.com/ (inside HP's firewall only) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) On 21 May 2001 22:30:52 +0100, Nix wrote: > I'm currently in the middle of a hack of crazy size, jumping in at the > deep end of XEmacs development, in order to familiarize myself with all > the code. > > I'm doing what should have been done a *long* time ago; ditching the > garbage collector and replacing it with a nicer one. I think everyone > can agree that XEmacs's garbage collector currently sucks really rather > hard; I don't think there are any ways to worsen its VM behaviour or > intrusiveness if we tried. > > The one I've picked is the Boehm collector; it's not terribly portable, > but that can be fixed fairly easily --- and it lets us dump bloody GCPRO > and all the uglinesses it has spawned over the years (blocking string > compaction, Lispification in redisplay and many other things). > > The Boehm collector only has one downside that I can see; unportability > (it's not portable to some of the more obscure platforms that XEmacs > runs on). Upsides include: > > - better VM behaviour (mark bits kept in a bitmap, and GC_malloc_atomic() > to state that certain kinds of objects cannot contain pointers). As > it is most of XEmacs is forced to stay memory-resident all the time > by mark bit setting; that proportion will reduce to just those > parts that contain pointers that must be traced. This is my primary > motivation for this because I run XEmacs on some fairly memory-poor > machines and I'm fed up of waiting for bloody GC to finish. > > - mark bit sanity; we can reclaim at least one bit from many objects, > and might even get lightweight cons cells back (I'm not sure if one > bit saved is enough for that though). Certainly we can junk the myriad > different ways we have to mark things; this is very much improved > recently but the boehm-gc can fix it completely > > - (on some platforms) full incrementality/generationality; we can say a > near-total goodbye to GC delays on those platforms > > - the death of GCPRO, and therefore probably also of gc_currently_forbidden > and similar variables. This is my other major motivation; portable > though it is, I *hate* GCPRO with a passion. (Besides, walking the > stack is not that unportable; the unportabilities in the Boehm > collector are in other areas, like incremental collection.) > > - and last but not least, it's written and actively maintained by > someone who's very accessible and who's one of the best GC hackers > there is, and it is itself acknowledged as probably the best > general-purpose C garbage collector in existence. > > Plus, I think it's a fun hack. > > I'm implementing it in such a way that the tying of the specific GC > implementation to Emacs is light; much lighter than the current > one's. So if everyone else thinks the boehm-gc sucks, you can just rip > it out and use the infrastructure left behind. > > > (btw, I think we should under no circumstances implement a copying > collector; they get less and less impressive the bigger the heap and the > longer-lived its objects, and XEmacs has a large heap and a very large > set of long-lived objects, mainly thanks to the obarray.) > > > I'll be paying *no* attention to unexec() and friends in this, at least > at first; I'll keep the portable dumper working, but if unexec() is > totally broken by some interaction with the boehm gc, I will not mourn > unduly. > > I'm doing the changes to 21.4.3 at first, because I know it's pretty > stable otherwise, so that any crashes I may encounter are my fault. Once > I've got it working fairly stably in there, I'll post the patches (and > yes, I'll split the patches up into pieces; I don't want the > GCPRO-removal to drown out the interesting stuff) and let everyone rip > into them... and then I guess I'll forward-port it to 2.5, and everyone > can let GCPRO fade into the mists of memory (maybe with the aid of > a psychiatrist). > > -- > `LARTing lusers is supposed to be satisfying. This is just tedious. The > silly shite I'm doing now is like trying to toothpick to death a Black > Knight made of jelly.' --- RDD > > From andyp@bea.com Mon May 21 18:18:31 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA19717 for ; Mon, 21 May 2001 18:18:30 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA03426; Mon, 21 May 2001 15:18:37 -0700 (PDT) Received: from wolfe.bea.com ([172.17.15.122]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id PAA13865; Mon, 21 May 2001 15:18:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20010521151831.00d59bf0@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 May 2001 15:19:13 -0700 To: Nix , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: <87k83al78z.fsf@loki.wkstn.nix> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Er, I believe someone has already done something similar and is writing their PhD dissertation on it. andy At 10:30 PM 5/21/01 +0100, Nix wrote: >I'm currently in the middle of a hack of crazy size, jumping in at the >deep end of XEmacs development, in order to familiarize myself with all >the code. > >I'm doing what should have been done a *long* time ago; ditching the >garbage collector and replacing it with a nicer one. I think everyone >can agree that XEmacs's garbage collector currently sucks really rather >hard; I don't think there are any ways to worsen its VM behaviour or >intrusiveness if we tried. > >The one I've picked is the Boehm collector; it's not terribly portable, >but that can be fixed fairly easily --- and it lets us dump bloody GCPRO >and all the uglinesses it has spawned over the years (blocking string >compaction, Lispification in redisplay and many other things). > >The Boehm collector only has one downside that I can see; unportability >(it's not portable to some of the more obscure platforms that XEmacs >runs on). Upsides include: > >- better VM behaviour (mark bits kept in a bitmap, and GC_malloc_atomic() > to state that certain kinds of objects cannot contain pointers). As > it is most of XEmacs is forced to stay memory-resident all the time > by mark bit setting; that proportion will reduce to just those > parts that contain pointers that must be traced. This is my primary > motivation for this because I run XEmacs on some fairly memory-poor > machines and I'm fed up of waiting for bloody GC to finish. > >- mark bit sanity; we can reclaim at least one bit from many objects, > and might even get lightweight cons cells back (I'm not sure if one > bit saved is enough for that though). Certainly we can junk the myriad > different ways we have to mark things; this is very much improved > recently but the boehm-gc can fix it completely > >- (on some platforms) full incrementality/generationality; we can say a > near-total goodbye to GC delays on those platforms > >- the death of GCPRO, and therefore probably also of gc_currently_forbidden > and similar variables. This is my other major motivation; portable > though it is, I *hate* GCPRO with a passion. (Besides, walking the > stack is not that unportable; the unportabilities in the Boehm > collector are in other areas, like incremental collection.) > >- and last but not least, it's written and actively maintained by > someone who's very accessible and who's one of the best GC hackers > there is, and it is itself acknowledged as probably the best > general-purpose C garbage collector in existence. > >Plus, I think it's a fun hack. > >I'm implementing it in such a way that the tying of the specific GC >implementation to Emacs is light; much lighter than the current >one's. So if everyone else thinks the boehm-gc sucks, you can just rip >it out and use the infrastructure left behind. > > >(btw, I think we should under no circumstances implement a copying > collector; they get less and less impressive the bigger the heap and the > longer-lived its objects, and XEmacs has a large heap and a very large > set of long-lived objects, mainly thanks to the obarray.) > > >I'll be paying *no* attention to unexec() and friends in this, at least >at first; I'll keep the portable dumper working, but if unexec() is >totally broken by some interaction with the boehm gc, I will not mourn >unduly. > >I'm doing the changes to 21.4.3 at first, because I know it's pretty >stable otherwise, so that any crashes I may encounter are my fault. Once >I've got it working fairly stably in there, I'll post the patches (and >yes, I'll split the patches up into pieces; I don't want the >GCPRO-removal to drown out the interesting stuff) and let everyone rip >into them... and then I guess I'll forward-port it to 2.5, and everyone >can let GCPRO fade into the mists of memory (maybe with the aid of >a psychiatrist). > >-- >`LARTing lusers is supposed to be satisfying. This is just tedious. The > silly shite I'm doing now is like trying to toothpick to death a Black > Knight made of jelly.' --- RDD From nix@esperi.demon.co.uk Mon May 21 18:30:15 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA20283 for ; Mon, 21 May 2001 18:30:13 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id XAA05418; Mon, 21 May 2001 23:26:53 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id XAA26204; Mon, 21 May 2001 23:26:52 +0100 Sender: nix@esperi.demon.co.uk To: Andy Piper Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <4.3.2.7.2.20010521151831.00d59bf0@san-francisco.beasys.com> X-Emacs: a learning curve that you can use as a plumb line. From: Nix Date: 21 May 2001 23:26:51 +0100 In-Reply-To: <4.3.2.7.2.20010521151831.00d59bf0@san-francisco.beasys.com> Message-ID: <87wv7ajq38.fsf@loki.wkstn.nix> Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mon, 21 May 2001, Andy Piper gibbered: > Er, I believe someone has already done something similar and is > writing their PhD dissertation on it. Any idea who? (This probably won't stop me from doing it again; this is at least partially a `learning project' for me, so I'll gain from it even if nobody but me uses it.) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From Adrian.Aichner@t-online.de Mon May 21 18:34:07 2001 Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA20539 for ; Mon, 21 May 2001 18:34:06 -0400 Received: from fwd02.sul.t-online.de by mailout02.sul.t-online.com with smtp id 151yFZ-000593-01; Tue, 22 May 2001 00:34:05 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.5]) by fwd02.sul.t-online.com with esmtp id 151yG5-1ACRA8C; Tue, 22 May 2001 00:34:37 +0200 To: Andy Piper Cc: Nix , xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <4.3.2.7.2.20010521151831.00d59bf0@san-francisco.beasys.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 97 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Andy" == Andy Piper writes: Andy> Er, I believe someone has already done something similar and is Andy> writing their PhD dissertation on it. richard.reingruber@xemacs.org, a student of Mr. Preprocessor. Andy> andy Andy> At 10:30 PM 5/21/01 +0100, Nix wrote: >> I'm currently in the middle of a hack of crazy size, jumping in at the >> deep end of XEmacs development, in order to familiarize myself with all >> the code. >> >> I'm doing what should have been done a *long* time ago; ditching the >> garbage collector and replacing it with a nicer one. I think everyone >> can agree that XEmacs's garbage collector currently sucks really rather >> hard; I don't think there are any ways to worsen its VM behaviour or >> intrusiveness if we tried. >> >> The one I've picked is the Boehm collector; it's not terribly portable, >> but that can be fixed fairly easily --- and it lets us dump bloody GCPRO >> and all the uglinesses it has spawned over the years (blocking string >> compaction, Lispification in redisplay and many other things). >> >> The Boehm collector only has one downside that I can see; unportability >> (it's not portable to some of the more obscure platforms that XEmacs >> runs on). Upsides include: >> >> - better VM behaviour (mark bits kept in a bitmap, and GC_malloc_atomic() >> to state that certain kinds of objects cannot contain pointers). As >> it is most of XEmacs is forced to stay memory-resident all the time >> by mark bit setting; that proportion will reduce to just those >> parts that contain pointers that must be traced. This is my primary >> motivation for this because I run XEmacs on some fairly memory-poor >> machines and I'm fed up of waiting for bloody GC to finish. >> >> - mark bit sanity; we can reclaim at least one bit from many objects, >> and might even get lightweight cons cells back (I'm not sure if one >> bit saved is enough for that though). Certainly we can junk the myriad >> different ways we have to mark things; this is very much improved >> recently but the boehm-gc can fix it completely >> >> - (on some platforms) full incrementality/generationality; we can say a >> near-total goodbye to GC delays on those platforms >> >> - the death of GCPRO, and therefore probably also of gc_currently_forbidden >> and similar variables. This is my other major motivation; portable >> though it is, I *hate* GCPRO with a passion. (Besides, walking the >> stack is not that unportable; the unportabilities in the Boehm >> collector are in other areas, like incremental collection.) >> >> - and last but not least, it's written and actively maintained by >> someone who's very accessible and who's one of the best GC hackers >> there is, and it is itself acknowledged as probably the best >> general-purpose C garbage collector in existence. >> >> Plus, I think it's a fun hack. >> >> I'm implementing it in such a way that the tying of the specific GC >> implementation to Emacs is light; much lighter than the current >> one's. So if everyone else thinks the boehm-gc sucks, you can just rip >> it out and use the infrastructure left behind. >> >> >> (btw, I think we should under no circumstances implement a copying >> collector; they get less and less impressive the bigger the heap and the >> longer-lived its objects, and XEmacs has a large heap and a very large >> set of long-lived objects, mainly thanks to the obarray.) >> >> >> I'll be paying *no* attention to unexec() and friends in this, at least >> at first; I'll keep the portable dumper working, but if unexec() is >> totally broken by some interaction with the boehm gc, I will not mourn >> unduly. >> >> I'm doing the changes to 21.4.3 at first, because I know it's pretty >> stable otherwise, so that any crashes I may encounter are my fault. Once >> I've got it working fairly stably in there, I'll post the patches (and >> yes, I'll split the patches up into pieces; I don't want the >> GCPRO-removal to drown out the interesting stuff) and let everyone rip >> into them... and then I guess I'll forward-port it to 2.5, and everyone >> can let GCPRO fade into the mists of memory (maybe with the aid of >> a psychiatrist). >> >> -- >> `LARTing lusers is supposed to be satisfying. This is just tedious. The >> silly shite I'm doing now is like trying to toothpick to death a Black >> Knight made of jelly.' --- RDD -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From nix@esperi.demon.co.uk Mon May 21 19:00:16 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA21693; Mon, 21 May 2001 19:00:12 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id XAA05576; Mon, 21 May 2001 23:51:43 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id XAA26260; Mon, 21 May 2001 23:51:41 +0100 Sender: nix@esperi.demon.co.uk To: Ovidiu Predescu Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <200105212207.PAA25763@orion.nsr.hp.com> X-Emacs: more boundary conditions than the Middle East. From: Nix Date: 21 May 2001 23:51:40 +0100 In-Reply-To: <200105212207.PAA25763@orion.nsr.hp.com> Message-ID: <87r8xijoxv.fsf@loki.wkstn.nix> Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mon, 21 May 2001, Ovidiu Predescu said: > This sounds like a really fun project! Absolutely. I like cleaning up ugly cruft, and the XEmacs GC layer is really rather in need of a good clean, encrufted by sheer age. [typed memory] > It turns out however that describing memory layout however is not an > easy task. Different machines have different memory layouts and > getting this right is very machine dependent. Currently the piece of > code that determines the memory layout (which in turn is used to > describe the typed memory for Boehm's GC) is the most problematic and > causes the most headaches in the GNU Objective-C runtime library. I plan to try out the _EXPLICITLY_TYPED() stuff, but it would indeed be a nightmare to implement portably, even with heavy use of offsetof(). I agree with Hans when he said in gc_typed.h * Should be used only for extremely performance critical applications, * or if conservative collector leakage is otherwise a problem (unlikely). ... so I plan to let XEmacs run for a while both with and without heavy use (nonportably implemented, quickly hacked up ;) ) of typed memory and compare their memory hits. I doubt it'll have all that much of an impact, because most of XEmacs's data structures are either stuffed with pointers, or totally devoid of them. What'll really have an impact is using GC_MALLOC_ATOMIC() in the right places. (Thank goodness for the objectified nature of XEmacs's memory allocation code!) > Just a word of caution if you decide to use typed memory. You may want > to take a look at the GCC code in the Objective-C runtime library, to > see how things are done. Checkout gc.c and encoding.c in the libobjc > directory: The method you use there (__objc_generate_gc_type_description() and friends) depends intimately on a description of the layout of the type being provided by the compiler. Of course, this is practical for libobjc; but I rather doubt that I can convince the SC that a `Typed GNU C' extension is wise when offsetof() will do the same job :) (And, in any case, XEmacs has to build with non-GCC compilers, distasteful though the thought is ;) ) Myself, I'm still slightly worried about what this will do to the weird old architectures XEmacs presumably still builds on. I guess if anyone complains about any of them the collector can be ported to them as needed; certainly it can't be ported *before* that :) and does anyone still use the latest XEmacs on a Masscomp, or a Gould, or a Tahoe? Hell, some of those targets were removed from GCC last year because they'd not been ported from GCC 1 in ten years, and *nobody* had ever complained... So I'll bite the bullet and do it, and if it's alreay been done better or I've done it in an insane manner you can all laugh at me and -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From 08.58016472@telia.com Mon May 21 19:05:00 2001 Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA21907; Mon, 21 May 2001 19:04:59 -0400 Received: from d1o891.telia.com (d1o891.telia.com [213.66.124.241]) by mailb.telia.com (8.9.3/8.9.3) with ESMTP id BAA00928; Tue, 22 May 2001 01:04:53 +0200 (CEST) Received: from blixten2 (h122n1fls33o891.telia.com [213.66.126.122]) by d1o891.telia.com (8.10.2/8.10.1) with SMTP id f4LN4rU22120; Tue, 22 May 2001 01:04:53 +0200 (CEST) Received: by localhost with Microsoft MAPI; Tue, 22 May 2001 01:07:27 +0200 Message-ID: <01C0E25B.91743FB0.08.58016472@telia.com> From: Jerker Haglund <08.58016472@telia.com> Reply-To: "08.58016472@telia.com" <08.58016472@telia.com> To: "'Michael Sperber [Mr. Preprocessor]'" Cc: Thomas Nichols , Mats Lidell , "xemacs-beta@xemacs.org" , "xemacs-nt@xemacs.org" Subject: RE: Help test EFS Date: Tue, 22 May 2001 01:07:26 +0200 Organization: GigaSoft X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/efs-1.25-pkg.tar.gz > > In order to turn this into an official package release, I urgently > need your help in testing it. I've tested EFS on a number of servers, I tried it with XEmacs 21.4.3 on Win2k (and NT), but I wasn't entirely successful. It did work better than the one included in 21.4.3, because that one locked up at once and didn't work at all for me. The new one could list a directory in dired With the new EFS I tried to upload a bunch of files by marking them in dired and pressing 'C'. No response and nothing copied. The end of the ftp buffer implied problems with back-slashes: delete /html/behag/#anmlan.htm# 250 DELE command successful. type image 200 Type set to I. put c:\myweb\behag\anmlan.htm /html/behag/anmlan.htm /usr/bin/ftp: local: c:mywebbehaganmlan.htm: No such file or directory Also, there seems to be a lot of trouble down in the process filter. Could be the same kind of thing, or it could be my settings. For example, copying a remote file to 'c:\myweb\tmp.tmp': (1) (error/warning) Error in process filter: (file-error Opening directory Resource temporarily unavailable c:\myweb\tmp.tmp) /J. Haglund From mlivshin@bigfoot.com Mon May 21 19:20:36 2001 Received: from smtp.verisity.com (carmel.verisity.com [212.150.223.1]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA22888 for ; Mon, 21 May 2001 19:20:35 -0400 Received: from alps.verisity.com (alps [212.150.223.27]) by smtp.verisity.com (8.9.3/npuexaJIu?) with ESMTP id CAA11892; Tue, 22 May 2001 02:15:56 +0300 (IDT) To: Nix Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> In-Reply-To: <87k83al78z.fsf@loki.wkstn.nix> From: Michael Livshin Organization: The Church of God the Utterly Indifferent Date: 22 May 2001 02:15:55 +0300 Message-ID: Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nix writes: > I'm doing what should have been done a *long* time ago; ditching the > garbage collector and replacing it with a nicer one. I think everyone > can agree that XEmacs's garbage collector currently sucks really rather > hard; I don't think there are any ways to worsen its VM behaviour or > intrusiveness if we tried. > > [...] > > The one I've picked is the Boehm collector; it's not terribly portable, > but that can be fixed fairly easily --- and it lets us dump bloody GCPRO > and all the uglinesses it has spawned over the years (blocking string > compaction, Lispification in redisplay and many other things). > > The Boehm collector only has one downside that I can see; unportability > (it's not portable to some of the more obscure platforms that XEmacs > runs on). the other downside is its quite pessimal data locality characteristics (it groups objects according to their size -- great for lists, sucks for everything else). whether it matters for XEmacs -- dunno, perhaps not. I've seen one system where it made quite a huge difference, when compared with a custom copying collector. > - (on some platforms) full incrementality/generationality; we can say a > near-total goodbye to GC delays on those platforms um, not really. it does help, but the delays are still there, especially if your heap is fragmented (and it will become so, as people tend to run one Emacs instance for weeks). > - the death of GCPRO, and therefore probably also of gc_currently_forbidden > and similar variables. This is my other major motivation; portable > though it is, I *hate* GCPRO with a passion. (Besides, walking the > stack is not that unportable; the unportabilities in the Boehm > collector are in other areas, like incremental collection.) the problem with walking the stack is not the unportability, it's the conservatism. you might want to tinker with the code to switch off the data segment scanning, BTW (I don't think it's a run-time option). > Plus, I think it's a fun hack. er. if you consider living in gdb fun, yes. ;) > (btw, I think we should under no circumstances implement a copying > collector; they get less and less impressive the bigger the heap and the > longer-lived its objects, and XEmacs has a large heap and a very large > set of long-lived objects, mainly thanks to the obarray.) last I heard, generational copying collectors were doing quite well. I believe all the major commercial (and most of the free) Common Lisp and *ML systems use such collectors. good luck, --mike -- When your hammer is C++, everything begins to look like a thumb. -- Steve Hoflich on comp.lang.c++ From youngs@xemacs.org Mon May 21 20:11:22 2001 Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [203.2.75.228]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA25038 for ; Mon, 21 May 2001 20:11:21 -0400 Received: from slackware.mynet.pc (wdcax13-070.dialup.optusnet.com.au [198.142.220.70]) by mail004.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4M0BAU22016 for ; Tue, 22 May 2001 10:11:11 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4M08lfF023232; Tue, 22 May 2001 10:08:47 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: texinfo mode frustrations References: <200105212031.NAA23483@orion.nsr.hp.com> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 22 May 2001 10:08:46 +1000 In-Reply-To: <200105212031.NAA23483@orion.nsr.hp.com> (Ovidiu Predescu's message of "Mon, 21 May 2001 13:31:06 -0700") Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "OP" == Ovidiu Predescu writes: OP> It would be nice to modify the regexp to also match "Top" in addition OP> to "top", especially since the info documentation for texinfo uses the OP> capitalized version in all its examples. I agree that would be good. Feel free to hack away. :-) -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From nix@esperi.demon.co.uk Mon May 21 20:30:39 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA25972 for ; Mon, 21 May 2001 20:30:31 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id BAA06001; Tue, 22 May 2001 01:04:31 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id BAA26491; Tue, 22 May 2001 01:04:30 +0100 Sender: nix@esperi.demon.co.uk To: Michael Livshin Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> X-Emacs: because idle RAM is the Devil's playground. From: Nix Date: 22 May 2001 01:04:22 +0100 In-Reply-To: Message-ID: <87zoc6i709.fsf@loki.wkstn.nix> Lines: 113 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On 22 May 2001, Michael Livshin stated: > Nix writes: >> The Boehm collector only has one downside that I can see; unportability >> (it's not portable to some of the more obscure platforms that XEmacs >> runs on). > > the other downside is its quite pessimal data locality characteristics > (it groups objects according to their size -- great for lists, sucks > for everything else). whether it matters for XEmacs -- dunno, perhaps > not. That has one advantage; it keeps fragmentation down. Maybe this is why that was done. It could well cause cacheline problems as well as data locality problems... ... but it can't fail to have better locality at GC time than the XEmacs GC system; and like it or not right now a busy XEmacs is GC-bound. What does Hans say about this criticism? Knowing Hans he's probably benchmarked it to death :) >> - (on some platforms) full incrementality/generationality; we can say a >> near-total goodbye to GC delays on those platforms > > um, not really. it does help, but the delays are still there, Much much smaller though, because they're cut up :) also, the massive slowdowns caused by GC pulling all of Emacs out of swap even if it's almost never used for anything but GC traversal are improved. > especially if your heap is fragmented (and it will become so, as > people tend to run one Emacs instance for weeks). Agreed; the allocator part of the Boehm GC doesn't look ideal as an allocator... I might see if I can rejig it in terms of an underlying malloc(), so we can use the nice general purpose malloc()s to do the allocation, and Boehm to do the GC. (But that's a blue-sky far future project, I think.) >> - the death of GCPRO, and therefore probably also of gc_currently_forbidden >> and similar variables. This is my other major motivation; portable >> though it is, I *hate* GCPRO with a passion. (Besides, walking the > > the problem with walking the stack is not the unportability, it's the > conservatism. I expect there to be some space wastage from that, yes. But all that wastes is swap, because the unreferenced object is, well, unreferenced; and I'm willing to burn a bit of swap in order to get that better VM behaviour. (It's *horrible* running XEmacs on 16--24Mb machines; the swapping at each GC can take 45 seconds or more!) > you might want to tinker with the code to switch off the data segment > scanning, BTW (I don't think it's a run-time option). I'm not sure if 5.3 can do that; there's DATASTART, but messing with that is a bit hairy (OK, it's very nasty 'cos it's one of the nonportable defined-differently-for-everyone options.) I plan to turn off ALL_INTERIOR_POINTERS, if it doesn't kill XEmacs. That should drastically reduce the number of incorrectly retained blocks; and in any case 5.x has got much better at spotting these blocks and zapping them. 4.x was worse, 3.x was horrible :) 5.x isn't bad. >> Plus, I think it's a fun hack. > > er. if you consider living in gdb fun, yes. ;) It teaches me a lot about XEmacs ('cos I've got to read most of the code to audit it for GC-safety). That's one of my primary goals. :) >> (btw, I think we should under no circumstances implement a copying >> collector; they get less and less impressive the bigger the heap and the >> longer-lived its objects, and XEmacs has a large heap and a very large >> set of long-lived objects, mainly thanks to the obarray.) > > last I heard, generational copying collectors were doing quite well. Something like Bartlett's Mostly Copying collector? That too looks nice; if the overhead of the Boehm collector is too high, I might well try the Bartlett one instead (note that I'm trying to make the changes to the XEmacs code itself independent of any one GC implementation; this is one reason why). I avoided it for fear that its VM performance would be worse, and because Richard Jones says in his wonderful GC book : A study of the comparative performance of the Boehm-Demers-Weiser : Conservative Collector and the Mostly Copying Collector would be : interesting, although as usual performance would be heavily dependent : on implementation detail. One may speculate that Mostly Copying might : perform better in an environment with a high allocation rate of : short-lived objects [...] and Emacs has lots and lots of objects with very long lifetimes indeed; the exact opposite of this case. (See my original reasoning, above. This just backs it up a little bit.) > I believe all the major commercial (and most of the free) Common Lisp > and *ML systems use such collectors. ML in particular has very different allocation patterns to Emacs; huge numbers of tiny, short-lived allocations are common, with very little long-term persistent state. Allocation performance is *really* important in that environment, while what matters here, I think, is GC latency and overhead. -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From jhar@tardis.ed.ac.uk Mon May 21 20:41:10 2001 Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA26404; Mon, 21 May 2001 20:41:09 -0400 Received: from marginal.demonadsltrial.co.uk ([193.195.64.136] helo=tardis.ed.ac.uk) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 1520EW-000Bgg-0U; Tue, 22 May 2001 01:41:08 +0100 Message-ID: <3B09B5A4.CEB137E7@tardis.ed.ac.uk> Date: Tue, 22 May 2001 01:41:08 +0100 From: Jonathan Harris X-No-Archive: Yes X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "08.58016472@telia.com" <08.58016472@telia.com> CC: "'Michael Sperber [Mr. Preprocessor]'" , "xemacs-beta@xemacs.org" , "xemacs-nt@xemacs.org" Subject: Re: Help test EFS References: <01C0E25B.91743FB0.08.58016472@telia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerker Haglund wrote: > put c:\myweb\behag\anmlan.htm /html/behag/anmlan.htm > /usr/bin/ftp: local: c:mywebbehaganmlan.htm: No such file or directory The fix to efs-tmp-name-template in efs release 1.20pre1 / package 1.25 is insufficient since it isn't just temporary file names that get passed to the ftp program, as the above example shows. A hack like the following is also required. --- efs.el.bak Mon May 21 23:44:32 2001 +++ efs.el Tue May 22 00:35:46 2001 @@ -3476,6 +3476,8 @@ (defun efs-maybe-quote-local-path (path) "Quote special characters in PATH if `efs-quote-local-paths' is non-nil." + (if (eq system-type 'windows-nt) + (setq path (replace-in-string path "\\\\" "/"))) (if efs-quote-local-paths (apply (function concat) (mapcar (function Since this is getting pretty ugly, an alternative is to stick with telling users to customise efs-ftp-program-name to point to the version of ftp.exe that ships with Windows. Jonathan. -- Jonathan Harris | jhar@tardis.ed.ac.uk London, England | Jonathan.Harris@symbian.com From steve@turnbull.sk.tsukuba.ac.jp Mon May 21 20:55:44 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA26987 for ; Mon, 21 May 2001 20:55:42 -0400 Received: by localhost id m1520S9-00014mC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 22 May 2001 09:55:13 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.47326.437918.846134@turnbull.sk.tsukuba.ac.jp> Date: Tue, 22 May 2001 09:54:54 +0900 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: xemacs-beta@xemacs.org, wmperry@aventail.com Subject: Re: Help test EFS In-Reply-To: References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "ms" == Michael Sperber writes: ms> In fact, W3 handles exactly the translation needed. All ms> somebody'd have to do is hack up a file-name handler which ms> recognizes URLs and hands them off to W3. W3 is close, but it needs reorganization before this could be convenient and robust. At the moment I find I need to require 'w3 as well as 'url in order to use the url-retrieve facility. I think we also want to implement the HEAD method (or whatever it's called) in order to get the file's "attributes" as much as possible without downloading it. I don't think w3 does yet. This needs to be cached since HTTP is in principle stateless == connection per transaction (although w3 may implement persistent connections, I don't know if servers are required to do so even in HTTP 1.1). I don't know how much of this w3 does, and I'm pretty sure it is not done at the url library level. Finally, w3 is in general in sad repair; I don't think Bill is doing much with it at the moment (he posted a cry for help a few months back, and that's about it). I know that T. V. Raman has expressed interest in packaging Emacspeak as an XEmacs package, but he is also concerned about the maintainership of w3. Bill? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Mon May 21 21:00:44 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA27285; Mon, 21 May 2001 21:00:42 -0400 Received: by localhost id m1520Ft-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 22 May 2001 09:42:33 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.46565.793873.184979@turnbull.sk.tsukuba.ac.jp> Date: Tue, 22 May 2001 09:42:13 +0900 To: Steve Youngs Cc: XEmacs Beta Subject: Re: texinfo mode frustrations In-Reply-To: References: <200105212031.NAA23483@orion.nsr.hp.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "SY" == Steve Youngs writes: >> --==> "OP" == Ovidiu Predescu writes: OP> It would be nice to modify the regexp to also match "Top" in OP> addition to "top", especially since the info documentation for OP> texinfo uses the capitalized version in all its examples. SY> I agree that would be good. Feel free to hack away. :-) I believe nodenames are case sensitive in Info searching. So you have to be careful. But when texinfo-mode is looking for a literal (such as "top" or "dir") maybe the search/match should be case-insensitive in general? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From rendhalver@users.sourceforge.net Mon May 21 22:28:55 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA30771 for ; Mon, 21 May 2001 22:28:52 -0400 Received: from ulthwe.dyndns.org (p92-tnt1.brs.ihug.com.au [203.173.188.92]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id MAA27731; Tue, 22 May 2001 12:28:41 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p92-tnt1.brs.ihug.com.au [203.173.188.92] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15113.52808.686307.227412@ulthwe.dyndns.org> Date: Tue, 22 May 2001 12:26:16 +1000 To: "Stephen J. Turnbull" Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), xemacs-beta@xemacs.org, wmperry@aventail.com Subject: Re: Help test EFS In-Reply-To: <15113.47326.437918.846134@turnbull.sk.tsukuba.ac.jp> References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> <15113.47326.437918.846134@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Stephen J. Turnbull writes: > >>>>> "ms" == Michael Sperber writes: > > ms> In fact, W3 handles exactly the translation needed. All > ms> somebody'd have to do is hack up a file-name handler which > ms> recognizes URLs and hands them off to W3. > > W3 is close, but it needs reorganization before this could be > convenient and robust. > > At the moment I find I need to require 'w3 as well as 'url in order to > use the url-retrieve facility. I think we also want to implement the > HEAD method (or whatever it's called) in order to get the file's yep its HEAD i believe, i will look it up to be sure im a web geek if you need some help with http stuff :) > "attributes" as much as possible without downloading it. I don't > think w3 does yet. This needs to be cached since HTTP is in principle > stateless == connection per transaction (although w3 may implement > persistent connections, I don't know if servers are required to do so no they are not "required" it is set by default in apache tho so thats most of the web servers :) > even in HTTP 1.1). I don't know how much of this w3 does, and I'm > pretty sure it is not done at the url library level. > -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From jay@jay.fm Mon May 21 23:29:24 2001 Received: from avg001.inetmessaging.com (host25-75-153-216.inetmessaging.com [216.153.75.25]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA00866; Mon, 21 May 2001 23:29:23 -0400 Received: from localhost (localhost.inetmessaging.com [127.0.0.1]) by avg001.inetmessaging.com (Postfix) with ESMTP id DC1A77DF22; Mon, 21 May 2001 22:18:20 -0500 (CDT) Received: from jay.fm (host5-75-153-216.inetmessaging.com [216.153.75.5]) by avg001.inetmessaging.com (Postfix) with ESMTP id 59D177DF1A; Mon, 21 May 2001 22:18:19 -0500 (CDT) Received: from office [209.6.189.17] by jay.fm with ESMTP (SMTPD32-6.05) id AD0BF30152; Mon, 21 May 2001 22:29:15 -0500 Message-ID: <002601c0e26f$607f3310$46fb000a@office> From: "Jay Levitt" To: "Jonathan Harris" , <08.58016472@telia.com> Cc: "'Michael Sperber [Mr. Preprocessor]'" , , References: <01C0E25B.91743FB0.08.58016472@telia.com> <3B09B5A4.CEB137E7@tardis.ed.ac.uk> Subject: Re: Help test EFS Date: Mon, 21 May 2001 23:29:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: iNET Messaging AVG 1.0 > Since this is getting pretty ugly, an alternative is to stick with > telling users to customise efs-ftp-program-name to point to the version > of ftp.exe that ships with Windows. Can XEmacs elisp access Windows environment variables? If so, this should always be available at %SystemRoot%\system32\ftp.exe, at least on NT/2000 boxes. ----- Original Message ----- From: "Jonathan Harris" To: <08.58016472@telia.com> Cc: "'Michael Sperber [Mr. Preprocessor]'" ; ; Sent: Monday, May 21, 2001 8:41 PM Subject: Re: Help test EFS > Jerker Haglund wrote: > > > put c:\myweb\behag\anmlan.htm /html/behag/anmlan.htm > > /usr/bin/ftp: local: c:mywebbehaganmlan.htm: No such file or directory > > The fix to efs-tmp-name-template in efs release 1.20pre1 / package 1.25 > is insufficient since it isn't just temporary file names that get passed > to the ftp program, as the above example shows. A hack like the > following is also required. > > > --- efs.el.bak Mon May 21 23:44:32 2001 > +++ efs.el Tue May 22 00:35:46 2001 > @@ -3476,6 +3476,8 @@ > > (defun efs-maybe-quote-local-path (path) > "Quote special characters in PATH if `efs-quote-local-paths' is > non-nil." > + (if (eq system-type 'windows-nt) > + (setq path (replace-in-string path "\\\\" "/"))) > (if efs-quote-local-paths > (apply (function concat) > (mapcar (function > > > Since this is getting pretty ugly, an alternative is to stick with > telling users to customise efs-ftp-program-name to point to the version > of ftp.exe that ships with Windows. > > Jonathan. > > -- > Jonathan Harris | jhar@tardis.ed.ac.uk > London, England | Jonathan.Harris@symbian.com > > From martin@m17n.org Mon May 21 23:53:17 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA02205 for ; Mon, 21 May 2001 23:53:16 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4M3rRp09392; Tue, 22 May 2001 12:53:27 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id MAA25960; Tue, 22 May 2001 12:53:06 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4M3r4105443; Tue, 22 May 2001 12:53:04 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.58016.384950.283156@gargle.gargle.HOWL> Date: Tue, 22 May 2001 12:53:04 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: [Success, 1% lisp-tests fail] XEmacs 21.5-b0 "alfalfa", i586-pc-win32 In-Reply-To: References: <15112.28014.790096.635334@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "APA" == Adrian Aichner writes: >>>>> "Martin" == Martin Buchholz writes: >>>>> "APA" == Adrian Aichner writes: APA> These test fails because my system prints 3 digits for the exponent: APA> (format "%e" 100) APA> "1.000000e+002" APA> MSDN actually documents that exponents are always printed with three APA> digits. APA> What's the preferable way to fix these tests? APA> 1. APA> (cond APA> ((equal system-type 'windows-nt) APA> (Assert (string= (format "%e" 100) "1.000000e+002"))) APA> (t APA> (Assert (string= (format "%e" 100) "1.000000e+02")))) APA> 2. APA> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100) 0)) Martin> I vote for 2. Except that the 3rd arg to string-match Martin> seems unnecessary. Martin> (Assert (string-match "1\\.000000e\\+0?02" (format "%e" 100))) APA> Martin, for maintainability (regexps are pretty easily screwed up, I APA> have used the fix of perl, grep, XEmacs for too long) I would prefer APA> 1. Would it be OK with you if generated a patch grouping all %[eEgG] APA> together in on (cond ...) and adding your comment from below? That is fine with me. But I have some concerns that the solution you come up with isn't portable enough and will need to be fixed again in the future. 1. For example, MS might actually fix the bug. 2. (equal system-type 'windows-nt) is better written (eq system-type 'windows-nt) 3. Which systems does this really apply to? Only windows-nt? What about windows-98? What about if microsoft renames their OS again? What about if we're on a windows system, but we're using a cygwin libc? Doesn't Borland ship a libc without this bug? etc... This bug is *not* a bug of the system, but of the C library. The principle is to avoid system-level ifdefs (usually in favor of feature tests). Time to add an autoconf test? 4. Instead of (cond), how about (if) or (case)? From ben@666.com Mon May 21 23:56:25 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id XAA02394 for ; Mon, 21 May 2001 23:56:21 -0400 Received: (qmail 20123 invoked by alias); 22 May 2001 03:56:20 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 20062 invoked by uid 0); 22 May 2001 03:56:19 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 22 May 2001 03:56:19 -0000 Message-ID: <3B09E3C1.A5AFBD32@666.com> Date: Mon, 21 May 2001 20:57:53 -0700 From: Ben Wing X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Aichner CC: Andy Piper , Nick Pakoulin , xemacs-nt@xemacs.org, xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: copy command in xemacs.mak References: <4.3.2.7.2.20010521090517.00d63460@san-francisco.beasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit please verify that these switches exist in win95. Adrian Aichner wrote: > > >>>>> "Andy" == Andy Piper writes: > > Andy> Reviewed and approved > Andy> andy > > Hello Nick, > > I recently did a similar thing for $(DEL). > > Here is what I learned (with help from Ben and Stephen): > > Keep @ and - flags outside of the variable definition as they would break > inside > @if exist $(SRC)\dump-id.c $(DEL) $(SRC)\dump-id.c > > Could you please rewrite your patch to produce this: > > COPY=xcopy /q /y > COPYDIR=xcopy /q /y /e > ... > @$(COPY) config.h $(SRC) > ... > > Best regards, > > Adrian > > Andy> At 06:44 PM 5/21/01 +0400, Nick Pakoulin wrote: > >> `nmake install -f xemacs.mak' command might take ages to complete on my > >> Windows2000 box because `copy' command asks confirmation to overwrite files in > >> destination folders. > >> > >> I replaced all direct calls to `copy' and `xcopy' commands with COPY and > >> COPYDIR variables. > >> > >> Nick > >> > >> 2001-05-21 Nick V. Pakoulin > >> > >> * xemacs.mak (install): Replace calls to (x)copy commands with > >> COPY and COPYDIR variables. > >> (COPY): New > >> (COPYDIR): New > >> > >> Index: xemacs.mak > >> =================================================================== > >> RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v > >> retrieving revision 1.58.2.3 > >> diff -u -r1.58.2.3 xemacs.mak > >> --- xemacs.mak 2001/05/17 13:37:39 1.58.2.3 > >> +++ xemacs.mak 2001/05/21 14:38:20 > >> @@ -48,6 +48,11 @@ > >> # Define a variable for the 'del' command to use > >> DEL=-del > >> > >> +# Define a variable for 'copy' command to use > >> +# Suppress confirmation for overwriting files > >> +COPY=@xcopy /q /y > >> +COPYDIR=@xcopy /q /y /e > >> + > >> # Program name and version > >> > >> !include "$(XEMACS)\version.sh" > >> @@ -502,13 +507,13 @@ > >> $(SRC)\paths.h > >> > >> $(SRC)\config.h: config.h > >> - copy config.h $(SRC) > >> + $(COPY) config.h $(SRC) > >> > >> $(SRC)\Emacs.ad.h: Emacs.ad.h > >> - copy Emacs.ad.h $(SRC) > >> + $(COPY) Emacs.ad.h $(SRC) > >> > >> $(SRC)\paths.h: paths.h > >> - copy paths.h $(SRC) > >> + $(COPY) paths.h $(SRC) > >> > >> #------------------------------------------------------------------------------ > > >> > >> @@ -1411,22 +1416,22 @@ > >> cd $(NT) > >> @echo Installing in $(INSTALL_DIR) ... > >> @echo PlaceHolder > PlaceHolder > >> - @xcopy /q PROBLEMS "$(INSTALL_DIR)\" > >> - @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" > >> + $(COPY) PROBLEMS "$(INSTALL_DIR)\" > >> + $(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" > >> $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" > >> - @xcopy /q $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" > >> - @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > >> - @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > >> - @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > >> - @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" > >> - @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" > >> - @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > >> + $(COPY) $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" > >> + $(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > >> + $(COPY) $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > >> + $(COPY) $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > >> + $(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" > >> + $(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" > >> + $(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > >> @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... > >> - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > >> + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > >> $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" > >> - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > >> + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > >> $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" > >> - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > >> + $(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > >> $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" > >> $(DEL) PlaceHolder > >> > > -- > Adrian Aichner > mailto:adrian@xemacs.org > http://www.xemacs.org/ -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From steve@turnbull.sk.tsukuba.ac.jp Tue May 22 00:30:33 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA04480 for ; Tue, 22 May 2001 00:30:32 -0400 Received: by localhost id m1523oO-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 22 May 2001 13:30:24 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.60238.222255.389902@turnbull.sk.tsukuba.ac.jp> Date: Tue, 22 May 2001 13:30:06 +0900 To: Nix Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: <87r8xijoxv.fsf@loki.wkstn.nix> References: <200105212207.PAA25763@orion.nsr.hp.com> <87r8xijoxv.fsf@loki.wkstn.nix> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Nix" == Nix writes: Nix> On Mon, 21 May 2001, Ovidiu Predescu said: >> This sounds like a really fun project! Nix> Absolutely. I like cleaning up ugly cruft, and the XEmacs GC Nix> layer is really rather in need of a good clean, encrufted by Nix> sheer age. Well, it would be nice if you could be compatible with Richard Reingrub's basic outline. Then we could choose among similarly implemented GCs with different basic strategies, and avoid the question of "is it the GC or the way it's hooked into XEmacs?" BTW, I can't think of a good way to see what has been proposed, except by reading tons of old xemacs-beta posts. Ben's Architecting XEmacs page (link from www.xemacs.org) is the most complete (although dated by now). But you can see some of what's in the process of implementation by doing "cvs status -v version.sh" (in particular, grep for "gc" or "GC" to find Richard Reingrub's branch). I checked fairly recently with our host, and cvs.xemacs.org has sufficient bandwidth and disk space to add a more branches like that. So once you've got things in shape where you're willing to let other people look at it, talk to martin@xemacs.org about getting CVS commit privileges, create a branch, and let us know about it. :-) Nix> Myself, I'm still slightly worried about what this will do to Nix> the weird old architectures XEmacs presumably still builds Nix> on. Don't worry; for released XEmacsen your collector will surely go in as a configure option at first. If they still are in use but can't use your collector, so be it---the configure option won't work for them. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From martin@m17n.org Tue May 22 00:36:55 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA05223; Tue, 22 May 2001 00:36:50 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4M4aqp10065; Tue, 22 May 2001 13:36:52 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id NAA26285; Tue, 22 May 2001 13:36:30 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4M4aUv05835; Tue, 22 May 2001 13:36:30 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.60622.238546.663823@gargle.gargle.HOWL> Date: Tue, 22 May 2001 13:36:30 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Nix CC: Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: <87k83al78z.fsf@loki.wkstn.nix> References: <87k83al78z.fsf@loki.wkstn.nix> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Nix" == nix writes: Nix> I'm currently in the middle of a hack of crazy size, jumping in at the Nix> deep end of XEmacs development, in order to familiarize myself with all Nix> the code. Richard Reingruber is working on a new GC. It can be found in the CVS branch NewGC-21-2. Richard is quiet. Search for his few postings on xemacs-beta. Richard is a student of Michael Sperber. Yoshiki Hayashi has written a copying gc for xemacs recently. It is not yet ready for prime time. His is precise, i.e. he has to maintain all the gcpros, and actually add a few, since the copying involves finding and updating ALL the places on the stack where Lisp_Objects live. Most of the recent maintenance of the existing gc has been by Olivier Galibert and myself. I've taken a look at the Boehm gc in the past, considering its possible use in XEmacs. I rejected using it because: - it's non-portable (reading its portability layer is frightening) - the concurrent or incremental gc feature isn't even intended to be portable currently, but incremental gc is a key attraction. - The big advantage of boehm gc is ditching the gcpros. But this is only a long-term advantage. Probably xemacs is fairly gcpro-clean these days. Incorporating boehm gc is going to be extreme short-term pain for long-term gain. However, the gcc project has recently started using boehm gc. Since gcc is very portable, they must be making any necessary portability improvements to boehm gc as they go. Nix> I'm doing what should have been done a *long* time ago; ditching the Nix> garbage collector and replacing it with a nicer one. I think everyone Nix> can agree that XEmacs's garbage collector currently sucks really rather Nix> hard; I don't think there are any ways to worsen its VM behaviour or Nix> intrusiveness if we tried. Everyone thinks the current gc sux, yes. Nix> The one I've picked is the Boehm collector; it's not terribly portable, Nix> but that can be fixed fairly easily --- and it lets us dump bloody GCPRO Nix> and all the uglinesses it has spawned over the years (blocking string Nix> compaction, Lispification in redisplay and many other things). Nix> The Boehm collector only has one downside that I can see; unportability Nix> (it's not portable to some of the more obscure platforms that XEmacs Nix> runs on). Upsides include: Nix> - better VM behaviour (mark bits kept in a bitmap, and GC_malloc_atomic() Nix> to state that certain kinds of objects cannot contain pointers). As Nix> it is most of XEmacs is forced to stay memory-resident all the time Nix> by mark bit setting; that proportion will reduce to just those Nix> parts that contain pointers that must be traced. This is my primary Nix> motivation for this because I run XEmacs on some fairly memory-poor Nix> machines and I'm fed up of waiting for bloody GC to finish. Hmmm. It seems to me mark() has to examine most of the heap anyways. Unless you do a lot of work, boehm gc might end up examining even more memory than the existing mark. Most of the guts of existing Lisp_Objects are other Lisp_Objects, so there isn't a whole lot of scope for GC_malloc_atomic() to be a big win. Nix> - mark bit sanity; we can reclaim at least one bit from many objects, Nix> and might even get lightweight cons cells back (I'm not sure if one Nix> bit saved is enough for that though). Certainly we can junk the myriad Nix> different ways we have to mark things; this is very much improved Nix> recently but the boehm-gc can fix it completely we can also put the mark-bits into a bitmap without complete boehmification. Understanding and extracting that code from boehm gc would be a much smaller and still very instructive project. Nix> - and last but not least, it's written and actively maintained by Nix> someone who's very accessible and who's one of the best GC hackers Nix> there is, and it is itself acknowledged as probably the best Nix> general-purpose C garbage collector in existence. I share your admiration of Hans. Nix> I'll be paying *no* attention to unexec() and friends in this, at least Nix> at first; I'll keep the portable dumper working, but if unexec() is Nix> totally broken by some interaction with the boehm gc, I will not mourn Nix> unduly. Agreed. Nix> I'm doing the changes to 21.4.3 at first, because I know it's pretty Nix> stable otherwise, so that any crashes I may encounter are my fault. Once Nix> I've got it working fairly stably in there, I'll post the patches (and Nix> yes, I'll split the patches up into pieces; I don't want the Nix> GCPRO-removal to drown out the interesting stuff) and let everyone rip Nix> into them... and then I guess I'll forward-port it to 2.5, and everyone Nix> can let GCPRO fade into the mists of memory (maybe with the aid of Nix> a psychiatrist). I encourage you on your adventure. However, some advice: - communicate with Richard and Yoshiki. - consider implementing mark bitmaps only in the existing gc. - investigate the version of boehm gc from the gcc project. - of course, you do have the blue book called "Garbage Collection", right? Good Luck. From jhar@tardis.ed.ac.uk Tue May 22 00:42:34 2001 Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA05602; Tue, 22 May 2001 00:42:33 -0400 Received: from marginal.demonadsltrial.co.uk ([193.195.64.136] helo=tardis.ed.ac.uk) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 152406-000L57-0C; Tue, 22 May 2001 04:42:30 +0000 Message-ID: <3B09EE35.CC47498A@tardis.ed.ac.uk> Date: Tue, 22 May 2001 05:42:29 +0100 From: Jonathan Harris X-No-Archive: Yes X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Wing CC: Adrian Aichner , Andy Piper , Nick Pakoulin , xemacs-nt@xemacs.org, xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: copy command in xemacs.mak References: <4.3.2.7.2.20010521090517.00d63460@san-francisco.beasys.com> <3B09E3C1.A5AFBD32@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Wing wrote: > please verify that these switches exist in win95. They do, and we've been using the /q and /e flags for a long time. Jonathan. -- Jonathan Harris | jhar@tardis.ed.ac.uk London, England | Jonathan.Harris@symbian.com From wmperry@gnu.org Tue May 22 00:49:20 2001 Received: from femail17.sdc1.sfba.home.com (femail17.sdc1.sfba.home.com [24.0.95.144]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA05897 for ; Tue, 22 May 2001 00:49:19 -0400 Received: from hel.bp.aventail.com ([24.12.70.142]) by femail17.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010522044915.YESU1719.femail17.sdc1.sfba.home.com@hel.bp.aventail.com>; Mon, 21 May 2001 21:49:15 -0700 Received: from hel.bp.aventail.com (wmperry@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4M4nAsQ027298; Mon, 21 May 2001 23:49:10 -0500 Received: (from wmperry@localhost) by hel.bp.aventail.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4M4n9WA027294; Mon, 21 May 2001 23:49:09 -0500 X-Authentication-Warning: hel.bp.aventail.com: wmperry set sender to wmperry@gnu.org using -f Sender: wmperry@aventail.com To: "Stephen J. Turnbull" Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), xemacs-beta@xemacs.org Subject: Re: Help test EFS X-Now-Listening-To: Sebastian - Kiss the Girl References: <3B072505.3B282E7B@666.com> <3B08DCB2.8A048C70@666.com> <15113.47326.437918.846134@turnbull.sk.tsukuba.ac.jp> X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 ("Stephen J. Turnbull"'s message of "Tue, 22 May 2001 09:54:54 +0900") Message-ID: <8666eut2d6.fsf@hel.bp.aventail.com> Lines: 83 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Urania) MIME-Version: 1.0 "Stephen J. Turnbull" writes: > >>>>> "ms" == Michael Sperber writes: > > ms> In fact, W3 handles exactly the translation needed. All > ms> somebody'd have to do is hack up a file-name handler which > ms> recognizes URLs and hands them off to W3. > > W3 is close, but it needs reorganization before this could be convenient > and robust. I tried this ages ago, but the file-name-handler stuff was in its infancy and there were just too many places it was utterly fubared. Hopefully things are better now. The code in the old URL package was just commented out. If you are feeling adventurous, you can use the code out of cvs and just do (url-setup-file-name-handlers) in your .emacs. And may the gods have mercy on your soul. > At the moment I find I need to require 'w3 as well as 'url in order to > use the url-retrieve facility. This should be fixed in the CVS versions, but w3 is still pretty broken. I concentrated on the URL subsystem, and then ran out of time. It is pretty close, and if people want to help, PLEASE do so. :) > I think we also want to implement the HEAD method (or whatever it's > called) in order to get the file's "attributes" as much as possible > without downloading it. I don't think w3 does yet. Shocked, SHOCKED I am that you would think something this simple wasn't implemented ages ago. :) url-file-attributes has worked for years. It tries to do the right thing for HTTP, but some things just aren't possible, but it is fairly useful now and then. > This needs to be cached since HTTP is in principle stateless == > connection per transaction (although w3 may implement persistent > connections, I don't know if servers are required to do so even in HTTP > 1.1). I don't know how much of this w3 does, and I'm pretty sure it is > not done at the url library level. The caching is done at the URL level, but for things like this we would just be doing HEADs, which is equivalent to what would do most of the time anyway, checking the consistency of the cache. HTTP/1.1 does require persistent connections and chunked encoding support, both on the client and the server. The URL code in CVS supports this, but there are still some issues with it. I'm considering taking a week off to work on it, but the next few weeks are insane around here with birthdays, anniversaries, weddings, and all sorts of other crap. > Finally, w3 is in general in sad repair; I don't think Bill is doing much > with it at the moment (he posted a cry for help a few months back, and > that's about it). My main goal for the next month is to get it usable in Emacs 21 (Dave Love is working on ripping out the need for mule-sysdp, bless him) and figuring out the last few things in the URL library that need to be finished (not many). W3 effectively needs a major overhaul and rewrite. The currently display code is very close to ideal in terms of theory. The execution is pretty lacking. Basic idea is to do everything off of a stylesheet and the parsed representation of the document. Where the document comes from, we shouldn't care. XML? Sure. HTML? Sure, what the hell. RTF? Join the party. At least in theory. I want to use savannah.gnu.org to try and drag more people into actively developing - I just haven't had the time, and the web has so thoroughly disgusted me for the last few years, I haven't had the heart even when I had the time. > I know that T. V. Raman has expressed interest in packaging Emacspeak as > an XEmacs package, but he is also concerned about the maintainership of > w3. I desperately need help (in general, but on Emacs/W3 specifically :) - there is just too much to do to get w3 back up to par. I can see maintaining the URL library myself, as that is something much more useful than w3 in its current state. But w3 needs more hands. -bp -- Ceterum censeo vi esse delendam. From galibert@pobox.com Tue May 22 00:50:49 2001 Received: from zalem.puupuu.org (cp912944-a.mtgmry1.md.home.com [24.18.149.178]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA05976; Tue, 22 May 2001 00:50:47 -0400 Received: (from galibert@localhost) by zalem.puupuu.org (8.9.3/8.9.3) id AAA07698; Tue, 22 May 2001 00:50:45 -0400 Date: Tue, 22 May 2001 00:50:45 -0400 From: Olivier Galibert To: Martin Buchholz Cc: Nix , Richard Reingruber , Yoshiki Hayashi , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack Message-ID: <20010522005045.A7656@zalem.puupuu.org> Mail-Followup-To: Martin Buchholz , Nix , Richard Reingruber , Yoshiki Hayashi , Michael Sperber , XEmacs Beta Test References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <15113.60622.238546.663823@gargle.gargle.HOWL>; from martin@xemacs.org on Tue, May 22, 2001 at 01:36:30PM +0900 On Tue, May 22, 2001 at 01:36:30PM +0900, Martin Buchholz wrote: > Most of the recent maintenance of the existing gc has been by Olivier > Galibert and myself. Mostly you. I've been quite inactive lately, as you've probably noticed. > Nix> The one I've picked is the Boehm collector; it's not terribly portable, > Nix> but that can be fixed fairly easily --- and it lets us dump bloody GCPRO > Nix> and all the uglinesses it has spawned over the years (blocking string > Nix> compaction, Lispification in redisplay and many other things). One thing I've heard you should be careful with: conservative GCs tend to "memory leak" with time, finding pointers that aren't really there anymore. They're perfect for short running applications (gcc is a good example), but tend to suck on long running ones. I don't really know how true it is, but you should probably do some research on the subject. Otherwise, as Martin says, good luck :-) OG. From sperber@informatik.uni-tuebingen.de Tue May 22 03:07:01 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA11960; Tue, 22 May 2001 03:07:00 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id B0E7F49E; Tue, 22 May 2001 09:06:57 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4M76vB35220; Tue, 22 May 2001 09:06:57 +0200 (CEST) (envelope-from sperber) To: Martin Buchholz Cc: Nix , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 May 2001 09:06:56 +0200 In-Reply-To: <15113.60622.238546.663823@gargle.gargle.HOWL> (Martin Buchholz's message of "Tue, 22 May 2001 13:36:30 +0900") Message-ID: Lines: 45 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Martin" == Martin Buchholz writes: >>>>> "Nix" == nix writes: Nix> I'm currently in the middle of a hack of crazy size, jumping in at the Nix> deep end of XEmacs development, in order to familiarize myself with all Nix> the code. Martin> Richard Reingruber is working on a new GC. It can be found in the Martin> CVS branch NewGC-21-2. Richard is quiet. Search for his few postings Martin> on xemacs-beta. Richard is a student of Michael Sperber. Martin> Yoshiki Hayashi has written a copying gc for xemacs recently. It is Martin> not yet ready for prime time. His is precise, i.e. he has to maintain Martin> all the gcpros, and actually add a few, since the copying involves Martin> finding and updating ALL the places on the stack where Lisp_Objects Martin> live. Let me try to clarify matters: - Robert Pluim at one time did hook up the Boehm collector to XEmacs in 1999 with rather disappointing results. - Richard has been working on making the current GC replaceable. This is a somewhat different goal from implementing a new GC (which is what Yoshiki Hayashi did). Hopefully, there'll be enough time left from his thesis project (which is finished) to actually plug in a different GC, albeit one he didn't write himself. (Current plans are for the RScheme incremental collector.) The interface is mostly finished; the only thing currently missing is a write barrier. - I rather doubt that Richard will have enough time to integrate the changes of the NewGC branch into the trunk. This would be a very worthwhile goal for anyone working on the GC, no matter which one. - You generally might want to look at http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-generation/gc.html to read up on some of the issues involved. It's quite dated by now, but most of the stuff there still applies. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From nix@esperi.demon.co.uk Tue May 22 03:30:18 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA12958 for ; Tue, 22 May 2001 03:30:14 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id IAA07286; Tue, 22 May 2001 08:04:33 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id IAA27875; Tue, 22 May 2001 08:04:29 +0100 Sender: nix@esperi.demon.co.uk To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <200105212207.PAA25763@orion.nsr.hp.com> <87r8xijoxv.fsf@loki.wkstn.nix> <15113.60238.222255.389902@turnbull.sk.tsukuba.ac.jp> X-Emacs: featuring the world's first municipal garbage collector! From: Nix Date: 22 May 2001 08:04:22 +0100 In-Reply-To: <15113.60238.222255.389902@turnbull.sk.tsukuba.ac.jp> Message-ID: <87elthj24p.fsf@loki.wkstn.nix> Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Tue, 22 May 2001, Stephen J. Turnbull stated: >>>>>> "Nix" == Nix writes: > Nix> Myself, I'm still slightly worried about what this will do to > Nix> the weird old architectures XEmacs presumably still builds > Nix> on. > > Don't worry; for released XEmacsen your collector will surely go in as > a configure option at first. If they still are in use but can't use > your collector, so be it---the configure option won't work for them. In practice, this means that part of the patch would go in; probably most of it, but not the GCPRO-junking bit. When it works for lots of people, we can junk GCPRO anyway. (After all, you can't junk GCPRO with a configure option; the horrible thing is too pervasive. :( ) Thanks for the pointer to Richard's outline; I'll have a look at it. There are only so many ways to implement the GC layer, so probably I'll be quite happy with the way Richard's doing it and can pitch in there. (This means that some of the really boring stuff will have been done for me :) ) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From rpluim@corpemea.BayNetworks.COM Tue May 22 03:39:51 2001 Received: from lobster.baynetworks.com (ns3.BayNetworks.COM [192.32.253.3]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA13497; Tue, 22 May 2001 03:39:49 -0400 Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by lobster.baynetworks.com (8.9.1/8.9.1) with ESMTP id DAA00796; Tue, 22 May 2001 03:45:51 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id DAA07892; Tue, 22 May 2001 03:39:13 -0400 (EDT) Received: from localhost ([47.162.85.104]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id DAA05346; Tue, 22 May 2001 03:39:10 -0400 for Received: from rpluim by localhost with local (Exim 3.22 #1 (Debian)) id 1526kz-0003eu-00; Tue, 22 May 2001 09:39:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.6040.683679.924905@europe.nortel.com> Date: Tue, 22 May 2001 09:39:04 +0200 To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: Martin Buchholz , Nix , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Sender: Robert Pluim Michael Sperber writes: > >>>>> "Martin" == Martin Buchholz writes: > > >>>>> "Nix" == nix writes: > > Nix> I'm currently in the middle of a hack of crazy size, jumping in at the > Nix> deep end of XEmacs development, in order to familiarize myself with all > Nix> the code. > > Martin> Richard Reingruber is working on a new GC. It can be found in the > Martin> CVS branch NewGC-21-2. Richard is quiet. Search for his few postings > Martin> on xemacs-beta. Richard is a student of Michael Sperber. > > Martin> Yoshiki Hayashi has written a copying gc for xemacs recently. It is > Martin> not yet ready for prime time. His is precise, i.e. he has to maintain > Martin> all the gcpros, and actually add a few, since the copying involves > Martin> finding and updating ALL the places on the stack where Lisp_Objects > Martin> live. > > Let me try to clarify matters: > > - Robert Pluim at one time did hook up the Boehm > collector to XEmacs in 1999 with rather disappointing results. That's a mild way of putting it. My notes from that attempt say "Leaks like a piece of string" ;-) The investigation I did seemed to indicate that the incidence of false positives on the stack was rather high (and I remember you mentioning another application using Boehm that had had the same sort of problems. MrEd?). > - Richard has been working on making the current GC replaceable. This > is a somewhat different goal from implementing a new GC (which is > what Yoshiki Hayashi did). Hopefully, there'll be enough time left > from his thesis project (which is finished) to actually plug in a > different GC, albeit one he didn't write himself. (Current plans > are for the RScheme incremental collector.) The interface is mostly > finished; the only thing currently missing is a write barrier. > > - I rather doubt that Richard will have enough time to integrate the > changes of the NewGC branch into the trunk. This would be a very > worthwhile goal for anyone working on the GC, no matter which one. Cool. I might tinker with this again if I have time. Robert -- From nix@esperi.demon.co.uk Tue May 22 03:44:00 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA13674; Tue, 22 May 2001 03:43:57 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id IAA07436; Tue, 22 May 2001 08:43:28 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id IAA28007; Tue, 22 May 2001 08:43:27 +0100 Sender: nix@esperi.demon.co.uk To: Martin Buchholz Cc: Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> X-Emacs: (setq software-quality (/ 1 number-of-authors)) From: Nix Date: 22 May 2001 08:43:24 +0100 In-Reply-To: <15113.60622.238546.663823@gargle.gargle.HOWL> Message-ID: <87ae45j0bn.fsf@loki.wkstn.nix> Lines: 109 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Tue, 22 May 2001, Martin Buchholz stated: > Richard Reingruber is working on a new GC. It can be found in the > CVS branch NewGC-21-2. Richard is quiet. Search for his few postings > on xemacs-beta. Richard is a student of Michael Sperber. It seems that it needs a bit of a forward port, at least :) > Yoshiki Hayashi has written a copying gc for xemacs recently. It is > not yet ready for prime time. His is precise, i.e. he has to maintain > all the gcpros, and actually add a few, since the copying involves > finding and updating ALL the places on the stack where Lisp_Objects > live. The real problem with GCPROs is that they are nasty to maintain; the type-accuracy they provide is good. It occurs to me that I could make GCPROs maintainable by making all the alloc_*() routines do an automatic GCPRO (well, do the same thing to the gcpro roots that GCPRO now does), and could write a fairly simple preprocessor that takes (one file of) the XEmacs C code and spits out a (transient) source file with UNGCPRO-alikes inserted at the end of each block where they are allocated. That would let us dump visible GCPROs in the source yet keep type-accuracy... > I've taken a look at the Boehm gc in the past, considering its > possible use in XEmacs. I rejected using it because: > - it's non-portable (reading its portability layer is frightening) That's my biggest worry, too. I don't really mind which GC I go to, really; my primary goals are zapping the GCPRO construct as it currently exists (although keeping its type-accuracy would be nice) and getting something with better VM behaviour. Both of these can be done without actually replacing the GC; it just seemed simpler to do that. > However, the gcc project has recently started using boehm gc. Since > gcc is very portable, they must be making any necessary portability > improvements to boehm gc as they go. Not yet. There are many architectures that GCC works on that libjava and parts of libobjc (the primary users of that gc) do not work on, and the boehm-gc in the GCC tree is a rather aged implementation. When version 6 comes out Hans has said he will move to making the GCC tree's copy of the collector the master copy; if I'm still using the boehm-gc in XEmacs by then, I'll migrate it to that version. > Hmmm. It seems to me mark() has to examine most of the heap anyways. > Unless you do a lot of work, boehm gc might end up examining even more > memory than the existing mark. Most of the guts of existing > Lisp_Objects are other Lisp_Objects, so there isn't a whole lot of > scope for GC_malloc_atomic() to be a big win. This isn't true of anything except for cons cells and other sequences, and things like hash tables, is it? For `leaf' objects (string data &c), a conservative collector like Boehm's would wind up tracing them for pointers they couldn't possibly contain pointers to anything. (It's true that the gains from this bit over the *existing* allocator would be marginal; it reduces the negative effects of using a conservative collector substantially, though. It's a tradeoff; GCPRO versus the occasional malloc_atomic()... but the more I think about it the more it seems to me that a preprocessor that automatically inserts UNGCPROs is the right way to go; type-accuracy *and* maintainability, wow ;) ) > we can also put the mark-bits into a bitmap without complete > boehmification. Understanding and extracting that code from boehm gc > would be a much smaller and still very instructive project. True. I think, for the first implementation, I'll go with -- Richard's infrastructure (general modifications), forward-ported to 21.4; they look praiseworthy, and the forward-porting job doesn't look too enormous -- A bitmapped version of the current GC -- and, if I can get it to work --- and I damned well will ;) --- a GCPROizing preprocessor, so we can dump *visible* evidence of GCPRO (that being what does the harm; we can forget it exists completely if it is automatically maintained!) (I might even be able to make it so that only one GCPRO/UNGCPRO operation needs to be done for an entire stack frame, because the preprocessor knows exactly what Lisp_Objects have been allocated in a given frame, so it can insert a single operation that does all the work...) > I encourage you on your adventure. However, some advice: > > - communicate with Richard and Yoshiki. > - consider implementing mark bitmaps only in the existing gc. Agreed and agreed (see above). > - investigate the version of boehm gc from the gcc project. Absolutely. > - of course, you do have the blue book called "Garbage Collection", > right? Of course! Wonderful book it is, too. (I originally bought it many moons ago with the explicit intention of using it to improve XEmacs's GC, but it's taken me this long to assimilate it properly.) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From mhummel@mosquitonet.com Tue May 22 04:00:46 2001 Received: from swarm.mosquitonet.com (swarm.mosquitonet.com [209.161.160.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA14337 for ; Tue, 22 May 2001 04:00:45 -0400 Received: from g9e0c4 (ppp6114.mosquitonet.com [209.161.166.114]) by swarm.mosquitonet.com (8.9.1/8.9.3) with SMTP id AAA12243 for ; Tue, 22 May 2001 00:00:43 -0800 Message-ID: <000c01c0e294$fa647a60$72a6a1d1@g9e0c4> From: "Hummel Family" To: Subject: Date: Mon, 21 May 2001 23:58:20 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C0E251.E9A1D760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C0E251.E9A1D760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to make my student class list appear in kanji, so they can = see what it would look like. How can I download a font to do this? Thanks ------=_NextPart_000_0009_01C0E251.E9A1D760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would like to make my  student class list = appear in=20 kanji, so they can see what it would look like.
How can I download a font to do this?
Thanks
------=_NextPart_000_0009_01C0E251.E9A1D760-- From sperber@informatik.uni-tuebingen.de Tue May 22 04:14:14 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA15104; Tue, 22 May 2001 04:14:11 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id 122721061; Tue, 22 May 2001 10:14:08 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4M8E8100386; Tue, 22 May 2001 10:14:08 +0200 (CEST) (envelope-from sperber) To: Nix Cc: Martin Buchholz , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 May 2001 10:14:08 +0200 In-Reply-To: <87ae45j0bn.fsf@loki.wkstn.nix> (Nix's message of "22 May 2001 08:43:24 +0100") Message-ID: Lines: 14 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Nix" == Nix writes: Nix> The real problem with GCPROs is that they are nasty to maintain; the Nix> type-accuracy they provide is good. Yeah, originally Richard and I were thinking of implementing a preprocessor to automatically put in the GCPROs. Some pervasive changes in the code are still necessary to make it work, but we know how it should be done in principle. We'd be happy to discuss what's involved. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From warner@luther.lothar.com Tue May 22 04:20:48 2001 Received: from luther.lothar.com (adsl-64-164-209-218.dsl.snfc21.pacbell.net [64.164.209.218]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id EAA15425 for ; Tue, 22 May 2001 04:20:48 -0400 Received: (qmail 31784 invoked by uid 1000); 22 May 2001 08:20:42 -0000 Date: 22 May 2001 08:20:42 -0000 Message-ID: <20010522082042.31783.qmail@luther.lothar.com> From: Brian Warner To: youngs@xemacs.org CC: xemacs-beta@xemacs.org In-reply-to: (message from Steve Youngs on 21 May 2001 09:31:33 +1000) Subject: Re: mailcrypt-3.5.5, XEmacs 21.4 (patch 3), gnupg-1.0.5, cygwin 1.3.1 problems References: <20010520184103.7730.qmail@luther.lothar.com> User-Agent: EMIKO/1.13.9 (Euglena tripteris) FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by EMIKO 1.13.9 - "Euglena tripteris") Content-Type: text/plain; charset=US-ASCII FYI: I just released mailcrypt-3.5.6 which contains the gnupg-1.0.5 patch (among some small others). Details on sourceforge at cheers, -Brian From sperber@informatik.uni-tuebingen.de Tue May 22 04:40:49 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA16058; Tue, 22 May 2001 04:40:49 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 191AB49E; Tue, 22 May 2001 10:40:47 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4M8ekX00435; Tue, 22 May 2001 10:40:46 +0200 (CEST) (envelope-from sperber) To: Nix Cc: Ovidiu Predescu , xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <200105212207.PAA25763@orion.nsr.hp.com> <87r8xijoxv.fsf@loki.wkstn.nix> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 May 2001 10:40:46 +0200 In-Reply-To: <87r8xijoxv.fsf@loki.wkstn.nix> (Nix's message of "21 May 2001 23:51:40 +0100") Message-ID: Lines: 20 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Nix" == Nix writes: Nix> On Mon, 21 May 2001, Ovidiu Predescu said: >> This sounds like a really fun project! Nix> Absolutely. I like cleaning up ugly cruft, and the XEmacs GC layer is Nix> really rather in need of a good clean, encrufted by sheer age. Nix> [typed memory] >> It turns out however that describing memory layout however is not an >> easy task. Actually, with Richard's changes, this particular part is trivial: there are only two sorts of objects, those containing only consecutive descriptors, and those containing only bitmap data not relevant to the GC. No more type-specific mark functions, and trivial tracing. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From provisor@mega.kharkiv.com Tue May 22 05:23:52 2001 Received: from uran.kharkiv.net (uran.kharkiv.net [194.44.156.30]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA17504 for ; Tue, 22 May 2001 05:23:41 -0400 Received: (from uucp@localhost) by uran.kharkiv.net (8.9.3/8.9.3/uran) with UUCP id MAA66615; Tue, 22 May 2001 12:23:34 +0300 (EEST) (envelope-from provisor@mega.kharkiv.com) Received: from Helix (helix.provisor.kharkiv.com [192.168.1.1]) by mega.kharkiv.com (8.8.7/8.8.7) with SMTP id MAA03871; Tue, 22 May 2001 12:08:36 +0300 Message-ID: <00c401c0e29e$bb3e3420$0101a8c0@provisor.kharkiv.com> From: "provisor" To: =?koi8-r?B?8dLBzg==?= , =?koi8-r?B?4M7PzsE=?= , =?koi8-r?B?6MXS08/O?= , =?koi8-r?B?5sXOycvT?= , =?koi8-r?B?5sXEz9LP1yDhLuEu?= , =?koi8-r?B?5sHSzcEt4Mc=?= , =?koi8-r?B?9NLJz8zY?= , =?koi8-r?B?9MHO2MvPIOTNydTSyco=?= , =?koi8-r?B?89XN2SAo0NLFxNPUwdfJ1MXM2Ck=?= , =?koi8-r?B?88zB19XUyd4=?= , =?koi8-r?B?88nMzcXU?= , =?koi8-r?B?88XSx8XKIOLF08XEwQ==?= , =?koi8-r?Q?=F3entral_office_of_Ilyashev_&_Partners_Law_firm?= , =?koi8-r?B?8sHVzNg=?= , =?koi8-r?B?8NLP18naz9Ix?= , =?koi8-r?B?8NLJ1NnLyc4g7MXX?= , =?koi8-r?B?8M/M1MHXwQ==?= , =?koi8-r?B?8M/Mz9PP1w==?= , =?koi8-r?B?8M/XxdLOz9cg5MXOydM=?= , =?koi8-r?B?8MHOwcPF0SDn6w==?= , =?koi8-r?B?79rPzi3JztfF09Q=?= , =?koi8-r?B?7vDmIO7P19g=?= , =?koi8-r?B?7snLz8zBxdc=?= , =?koi8-r?B?7sHUwczJ?= , =?koi8-r?B?7c/dxc7Ty8HRIOzAxM3JzMEg4s/SydPP187B?= , =?koi8-r?B?7c/E1dM=?= , =?koi8-r?B?ze7i++kgzO7x8g==?= , =?koi8-r?B?7cXEycPJzsEgxMzRIPfB0w==?= , =?koi8-r?B?7cHSydXQz8zY?= , =?koi8-r?B?7cHSydXQz8zY?= , =?koi8-r?B?7cHSyc7BIPDS0c7J3s7Jy8/XwQ==?= , =?koi8-r?B?7cHSyc7B?= , =?koi8-r?B?7NXHwc7Tyw==?= , =?koi8-r?B?7D/LySD1y9LBP87J?= , =?koi8-r?B?7MXMxcvB?= , =?koi8-r?B?69XSyczP?= , =?koi8-r?B?69LZzQ==?= , =?koi8-r?B?69LJ18/K8s/H?= , =?koi8-r?B?69LFzcXO3tXH?= , =?koi8-r?B?68/O09TBztTJziDwz8vB09g=?= , =?koi8-r?B?68nF1+3FxPDSxdDB0sHU?= , =?koi8-r?B?+snOwcfVzNg=?= , =?koi8-r?B?+sHQz9LP1tjF?= , =?koi8-r?B?5NXEyc7BIO7B1MHbwQ==?= , =?koi8-r?B?5M7F0NLP0MXU0s/X08s=?= , =?koi8-r?B?xM3J1NLJyg==?= , =?koi8-r?B?5MXPzjE=?= , =?koi8-r?B?58/MxMXOLebB0s0=?= , =?koi8-r?B?58XSzcXT?= , =?koi8-r?B?98zBxO3J98E=?= , =?koi8-r?B?98zBxMnNydI=?= , =?koi8-r?B?18nUwdM=?= , =?koi8-r?B?98nU?= , =?koi8-r?B?98nL1dPYy8E=?= , =?koi8-r?B?4s/SydMg/cHX1dLTy8nK?= , =?koi8-r?B?4s/OxMHSxc7LzyD+8CDtxcTUxcjOycvB?= , =?koi8-r?B?4s/C0tnbxdc=?= , =?koi8-r?B?4sHMwcLBzs/XIPPF0sfFyg==?= , =?koi8-r?B?4dDUxcvBLTIwMDA=?= , =?koi8-r?B?4dDUxcvBIC0gNjM=?= , =?koi8-r?B?4dDUxcvBIC0gMjI0?= , =?koi8-r?B?4c7ExdLT?= , =?koi8-r?B?4czFzsE=?= , =?koi8-r?B?4czFy9PBzsTSIOvB0svB3qPX?= , =?koi8-r?B?4SAtIDIyOA==?= , "Zhygman Yuriy G." , "Yuriy Tyshetskiy" , "Yuriy Byeskov" , "Yuri Keshishev" , , "X" , , , , "Vyatcheslav Krasovski" , , "Vladyslav Ukis" , "Vladimir Sova" , "Vladimir Bazdyrev" , "Vlad Golovin" , , "vitafarm" , "Vira-K" , "vikont" , "Victoria" , "Victor Chebotarjov" , "vbaych" , "Valera Judin" , "Vadim Melnik" , "Vadim K" , , "V.D. Bogomaz" , "V" , "Unipharm" , "ttt0057" , "triton" , "trigram" , "Triad" , , "Tatyana Borovik" , "Tarasov" , "T.V.K. Group" , "SysAdm" , "Sqlmail" , "Slusar Leonid" , "Slipchenko N.I." , "Slavich" , "Skyline_it" , "Sistrum" , "Shangli" , , "Sergey Vitcin" , "Sergey Malegikov" , "Serg_K" , "Serg_K" , "Secretary" , "Saturn" , , "Sales" , , , "Roman Smishko" , "Roman Lesyk" , "Roman Lesyk" , "ROBOT" , "radnyk" , "radio" , "Pzventa" , "pulse" , "provisor" , "provisor" , , "prov_adv" , "Promed Ltd." , , "Price Robot" , "Pharmateca" , "PF Megapolis" , , "Olga Shelest" , "Olena Novatska" , , "Nikolay Khamaganov" , "Natasha" , "Natala Ryabovol" , , , "MEDIVIT Ltd" , "medivit" , "Medical Ukraine" , , , "Marketing Department" , "Marina Artemenko" , "Malin, Alexander" , , "LudmilaPharm" , , "Lena" , , "Legenchenko" , , "KrivoyRog \"Farmacia\"" , , "konstantin fausto" , "Kokozey Denis" , "KODA&PRIZMA" , "Karkachovs family" , "Karen Topuzyan" , "Judin V." , "Janna, Sergej" , =?koi8-r?B?SmFpbmEg8MHO3sXOy88g5S7uLg==?= , "Irina" , "Igor Pivovarov" , "Igor Pivovarov" , "Igor Bereznyakov" , "Igor A. Rodnevskiy" , "Igor" , "I.Stelmakh" , "hemo" , "helen bronnikova" , "Hadjigeorgiev Alex" , "Grimaluk" , "Grigory Mikhailick" , "Georgy V. Khomyakov" , "gdv" , "Galina Antoschuk" , "FORTIS" , , "Fedor Lanovoy" , "Fedko, Nikolay" , "fausto" , "farma" , "ExpoService" , "Eugene Tokarev" , , "Ekateryna Belozertseva" , "dudkin" , , , "Draz3" , "Dortorus" , "Dolganenko, Denys N." , "Dmitry A.Deineka" , "Dima Egorenkov" , "Dima" , "dima" , , , "CyberAlien" , "counter" , "Coordination Bureau of Encyclopedia of Modern Ukraine" , "CityCat" , "chris" , "Cherednichenko Lidiya" , "Centre" , , "BMI2" , "Biznes kredit" , "BIOFARM" , "Biochemie Ukraine" , "Bezenchuk" , , "artel" , , , "Anna Davidenko" , "Andy V. Kryachko" , "Andy V. Kryachko" , "Andy Ivanov" , "andrey chuprina" , "Andrew Zubriy" , "Andretty" , "Alexey Yefymov" , "Alexey Vassiliev" , "Alexey Minchenko" , "Alexander Partola" , "Alexander Lushpaenko" , "Alexander Chernov" , , "Alex V." , "Alex Laryanovsky" , "Alex" , "AlekseyT" , "Aleksey N. Rodin" , "AJUS" , "AJUS" , "Advertizing Manager" , "Advertising Manager" , "Administrator" , "A. Mazur (Proteus)" , =?koi8-r?B?XCLmwdLNydrEwdTFzNjT1NfPXCIg5M7F0NLP0MXU0s/X08s=?= , "\"Next farma\"" Date: Tue, 22 May 2001 12:08:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 ÷ÎÉÍÁÎÉÅ! ôÏÌØËÏ ÞÔÏ ÐÒÉÛÌÏ ÓÏÏÂÝÅÎÉÅ ÉÚ áÍÅÒÉËÉ: ÐÏÑ×ÉÌÉÓØ ÎÏ×ÙÅ, ÞÒÅÚ×ÙÞÁÊÎÏ ÏÐÁÓÎÙÅ ×ÉÒÕÓÙ.éÎÆÏÒÍÁÃÉÀ Ï ÎÉÈ ÎÕÖÎÏ ÒÁÚÏÓÌÁÔØ ÐÏ ×ÓÅÍ ÉÚ×ÅÓÔÎÙÍ ÷ÁÍ ÁÄÒÅÓÁÍ ïÞÅÎØ ÂÙÓÔÒÏ. ïÓÔÁÎÏ×ÉÔÅ ÜÔÉ ×ÉÒÕÓÙ! 1. ôÏÌØËÏ ÞÔÏ Microsoft'ÏÍ ÏÂÎÁÒÕÖÅÎ É ÏÐÒÅÄÅÌÅÎ ËÁË ÎÁÉÂÏÌÅÅ ÏÐÁÓÎÙÊ ÉÚ ×ÓÅÈ ËÏÇÄÁ-ÌÉÂÏ ÓÕÝÅÓÔ×Ï×Á×ÛÉÈ ÎÏ×ÙÊ ×ÉÒÕÓ. üÔÏÔ ×ÉÒÕÓ ÂÙÌ ÏÂÎÁÒÕÖÅÎ ×ÞÅÒÁ (ÐÏÚÁ×ÞÅÒÁ) ×ÅÞÅÒÏÍ MCAfee,É ÐÒÏÔÉ× ÎÅÇÏ ÐÏËÁ ÎÅ ÒÁÚÒÁÂÏÔÁÎÏ ÎÉËÁËÏÇÏ ÓÒÅÄÓÔ×Á. üÔÏÔ ×ÉÒÒÕÓ ÕÎÉÞÔÏÖÁÅÔ ÎÕÌÅ×ÏÊ ÓÅËÔÏÒ ×ÁÛÅÇÏ ÖÅÓÔËÏÇÏ ÄÉÓËÁ, ÔÏÔ, ÇÄÅ ÒÁÓÐÏÌÏÖÅÎÁ ÖÉÚÎÅÎÎÏ ×ÁÖÎÁÑ ÄÌÑ ÒÁÂÏÔÙ ÓÉÓÔÅÍÙ ÉÎÆÏÒÍÁÃÉÑ. üÔÏÔ ×ÉÒÕÓ ÄÅÊÓÔ×ÕÅÔ ÓÌÅÄÕÀÝÉÍ ÏÂÒÁÚÏÍ: ÏÎ ÓÁÍ ÓÅÂÑ ÒÁÓÓÙÌÁÅÔ ÐÏ ×ÓÅÍÕ ÓÐÉÓËÕ ×ÁÛÉÈ ËÏÎÔÁËÔÏ× Ó ÚÁÇÏÌÏ×ËÏÍ "A Virtual Card for you" ÉÌÉ "une carte virtuelle pour vous". îå ïôëòù÷áêôå îéþåçï ó ôáëïê îáäðéóøà. ëÁË ÔÏÌØËÏ ÐÒÅÄÐÏÌÐÇÁÅÍÁÑ ×ÉÒÔÕÁÌØÎÁÑ ÏÔËÒÙÔËÁ ÂÕÄÅÔ ÏÔËÒÙÔÁ, ËÏÍÐØÀÔÅÒ ÚÁ×ÉÓÎÅÔ, É ÐÏÌØÚÏ×ÁÔÅÌØ ÄÏÌÖÅÎ ÂÕÄÅÔ ÐÅÒÅÚÁÇÒÕÚÉÔØ ÅÇÏ. ðÏÓÌÅ ÎÁÖÁÔÉÑ ËÌÁ×ÉÛ ctrl+alt+dÅl ÉÌÉ ËÎÏÐËÉ "reset" ×ÉÒÕÓ ÕÎÉÞÔÏÖÉÔ ÎÕÌÅ×ÏÊ ÓÅËÔÏÒ, É ÔÏÇÄÁ ×ÁÛ ÖÅÓÔËÉÊ ÄÉÓË ÂÕÄÅÔ ÏËÏÎÞÁÔÅÌØÏ ÕÎÉÞÔÏÖÅÎ. ðÏÖÁÌÕÊÓÔÁ, ÐÅÒÅÛÌÉÔÅ ÜÔÏ ÐÉÓØÍÏ ËÁË ÍÏÖÎÏ ÂÏÌØÛÅÍÕ ÞÉÓÌÕ ÌÀÄÅÊ. 2. áËÁÄÅÍÉÑ ëÒÅÔÅÑ ÐÒÅÄÕÐÒÅÖÄÁÅÔ ÎÁÓ Ï ÔÏÍ, ÞÔÏ ÁÎÔÉ-ËÒÉÍÉÎÁÌØÎÙÊ ×ÉÒÕÓÎÙÊ ÃÅÎÔÒ ÓÏÏÂÝÉÌ Ï ÏÔËÒÙÔÉÉ Ä×ÕÈ ÎÏ×ÙÈ ×ÉÒÕÓÏ×. ïÎÉÕÄÕÔ ÒÁÓÓÙÌÁÔØÓÑ ÐÏ e-mail c ÚÁÇÏÌÏ×ËÁÍÉ "CALIFORNIA IBM" É "GIRL THING". Microsoft ÓÏÏÂÛÁÅÔ, ÞÔÏ ÏÎÉ ÏÞÅÎØ ÏÐÁÓÎÙ, ÅÝÅ ÂÏÌÅÅ ÏÐÁÓÎÙ ÞÅÍ "I Love you". ðÒÏÔÉ× ÎÉÈ ÎÅ ÓÕÝÅÓÔ×ÕÅÔ ÎÉËÁËÏÇÏ ÓÒÅÄÓÔ×Á ìÅÞÅÎÉÑ,ÏÎÉ ÓÔÉÒÁÀÔ ×ÓÀ ÉÎÆÏÒÍÁÃÉÀ Ó ÖÅÓÔËÏÇÏ ÄÉÓËÁ, ÕÎÉÞÔÏÖÁÀÔ Internet Explorer Netscape Navigator. îÅ ÏÔËÒÙ×ÁÊÔÅ ÎÉÞÅÇÏ Ó ÔÁËÉÍ ÚÁÇÏÌÏ×ËÏÍ. 3. åÓÌÉ ×Ù ÐÏÌÕÞÉÔÅ ÐÏ e-mail ÓÏÏÂÝÅÎÉÅ Ó ×ÌÏÖÅÎÉÅÍ ÜËÒÁÎÎÏÊ ÚÁÓÔÁ×ËÉ ÐÏÄ ÎÁÚ×ÁÎÉÅÍ "BUDDLY SIP", ÎÉ × ËÏÅÍ ÓÌÕÞÁÅ ÅÇÏ ÎÅ ÏÔËÒÙ×ÁÊÔÅ. îÅÍÅÄÌÅÎÎÏ ÅÇÏ ÕÎÉÞÔÏÖØÔÅ. ïÔËÒÙ× ÅÇÏ, ×Ù ÓÏÔÒÅÔÅ ×ÓÅ ÄÁÎÎÙÅ ÎÁ Ó×ÏÅÍ ÖÅÓÔËÏÍ ÄÉÓËÅ. üÔÏÔ ×ÉÒÕÓ ÂÙÌ ÚÁÐÕÝÅÎ 5 (6) ÄÎÅÊ ÎÁÚÁÄ. åÓÌÉ ×ÓÅ ÂÕÄÕÔ × ËÕÒÓÅ, ÚÁÐÕÓË ÜÔÏÇÏ ×ÉÒÕÓÁ ïâñúáôåìøîï ÐÒÏ×ÁÌÉÔÓÑ. âõäåí âìáçïäáòîù ÷áí úá ôï, þôï ÷ù ðåòåûìåôå üôï óïïâýåîéå ÷óåí ÷áûéí ëïòòåóðïîìäåîôáí ó ÎÁÉÌÕÞÛÉÍÉ ÐÏÖÅÌÁÎÉÑÍÉ, (ÉÎÆÏÒÍÁÃÉÑ ÐÏÌÕÞÅÎÁ ÏÔ àÒÉÑ óÅÍÅÎÏ×Á) From npak@ispras.ru Tue May 22 05:44:37 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id FAA18229 for ; Tue, 22 May 2001 05:44:34 -0400 Received: (qmail 28460 invoked from network); 22 May 2001 09:43:57 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 22 May 2001 09:43:57 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f4M9iIU21770; Tue, 22 May 2001 13:44:19 +0400 (MSK) Received: tid NAA04913; Wed, 22 May 1996 13:44:08 +0300 Received: from HOOKAH.kasbek.ispras.ru (hookah.kazbek.ispras.ru [194.186.94.160]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f4M9iVg75998; Tue, 22 May 2001 13:44:32 +0400 (MSD) (envelope-from npak@ispras.ru) To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Andy Piper , xemacs-nt@xemacs.org, xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: copy command in xemacs.mak References: <4.3.2.7.2.20010521090517.00d63460@san-francisco.beasys.com> From: npak@ispras.ru (Nick Pakoulin) Date: 22 May 2001 13:45:14 +0400 In-Reply-To: Adrian.Aichner@t-online.de's message of "21 May 2001 22:21:19 +0200" Message-ID: Lines: 105 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii intro: "AA" == Adrian Aichner writes: Done, patch below. Nick. >>>>>> "Andy" == Andy Piper writes: Andy> Reviewed and approved andy AA> Hello Nick, AA> I recently did a similar thing for $(DEL). AA> Here is what I learned (with help from Ben and Stephen): AA> Keep @ and - flags outside of the variable definition as they would break AA> inside @if exist $(SRC)\dump-id.c $(DEL) $(SRC)\dump-id.c AA> Could you please rewrite your patch to produce this: AA> COPY=xcopy /q /y COPYDIR=xcopy /q /y /e ... @$(COPY) config.h $(SRC) ... AA> Best regards, AA> Adrian Andy> At 06:44 PM 5/21/01 +0400, Nick Pakoulin wrote: >>> `nmake install -f xemacs.mak' command might take ages to complete on my >>> Windows2000 box because `copy' command asks confirmation to overwrite >>> files in destination folders. >>> >>> I replaced all direct calls to `copy' and `xcopy' commands with COPY and >>> COPYDIR variables. >>> >>> Nick >>> Index: xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.58.2.3 diff -u -r1.58.2.3 xemacs.mak --- xemacs.mak 2001/05/17 13:37:39 1.58.2.3 +++ xemacs.mak 2001/05/22 09:41:33 @@ -48,6 +48,11 @@ # Define a variable for the 'del' command to use DEL=-del +# Define a variable for 'copy' command to use +# Suppress confirmation for overwriting files +COPY=xcopy /q /y +COPYDIR=xcopy /q /y /e + # Program name and version !include "$(XEMACS)\version.sh" @@ -502,13 +507,13 @@ $(SRC)\paths.h $(SRC)\config.h: config.h - copy config.h $(SRC) + @$(COPY) config.h $(SRC) $(SRC)\Emacs.ad.h: Emacs.ad.h - copy Emacs.ad.h $(SRC) + @$(COPY) Emacs.ad.h $(SRC) $(SRC)\paths.h: paths.h - copy paths.h $(SRC) + @$(COPY) paths.h $(SRC) #------------------------------------------------------------------------------ @@ -1411,22 +1416,22 @@ cd $(NT) @echo Installing in $(INSTALL_DIR) ... @echo PlaceHolder > PlaceHolder - @xcopy /q PROBLEMS "$(INSTALL_DIR)\" - @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" + @$(COPY) PROBLEMS "$(INSTALL_DIR)\" + @$(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" - @xcopy /q $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" - @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" - @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" - @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" - @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" - @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" - @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" + @$(COPY) $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" + @$(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" + @$(COPY) $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" + @$(COPY) $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" + @$(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" + @$(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" + @$(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" + @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" + @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" - @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" + @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" $(DEL) PlaceHolder From Olivier.Fambon@inrialpes.fr Tue May 22 05:47:35 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA18377 for ; Tue, 22 May 2001 05:47:34 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id LAA28176; Tue, 22 May 2001 11:46:16 +0200 (MEST) Received: from inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f4M9lUd24816; Tue, 22 May 2001 11:47:30 +0200 (MEST) Message-ID: <3B0A36C2.92092FDD@inrialpes.fr> Date: Tue, 22 May 2001 11:52:02 +0200 From: Olivier Fambon X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Stodghill CC: xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Stodghill wrote: > > Recipe for disaster: > > milhouse$ uname -a > CYGWIN_NT-5.0 MILHOUSE 1.3.1(0.38/3/2) 2001-04-24 20:01 i686 unknown > milhouse$ xemacs -vanilla > > M-: (setq load-path (cons "/path/for/oort-gnus/" load-path)) > M-x load-library message > M-x message-mail > M-x filladapt-mode > (insert the following in the body of the message) > > this is some citation > > text that needs to be filled. > (now put the cursor on this text and press) > M-q > > XEmacs enters an infinite loop which cannot be broken with C-g. > > For the ding list: Oort v0.03 and filladapt don't work together under > Cygwin XEmacs. This problem does not exist in 5.8.8. > It seems to be a font-lock problem, coz if you do that with xemacs -nw -vanilla it works, as long as you don't go M-x font-lock-mode Moreover, C-g works in this case (tty). From martin@m17n.org Tue May 22 05:48:05 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA18401; Tue, 22 May 2001 05:47:56 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4M9llp20864; Tue, 22 May 2001 18:47:47 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id SAA28384; Tue, 22 May 2001 18:47:26 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4M9lPk15116; Tue, 22 May 2001 18:47:25 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.13741.708870.454969@gargle.gargle.HOWL> Date: Tue, 22 May 2001 18:47:25 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Nix Cc: Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: <87ae45j0bn.fsf@loki.wkstn.nix> References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Nix" == nix writes: Nix> The real problem with GCPROs is that they are nasty to maintain; the Nix> type-accuracy they provide is good. It occurs to me that I could make Nix> GCPROs maintainable by making all the alloc_*() routines do an automatic Nix> GCPRO (well, do the same thing to the gcpro roots that GCPRO now does), The alloc routines know what they're allocating, but they don't know about the references to the memory being allocated. Unless you do something very radical, you have to gcpro the address of the Lisp_Object on the stack that is about to receive the pointer to the allocated memory. This means that Fcons can't gcpro anything. Perhaps I'm missing something. The standard tricky thing about implementing a preprocessor that adds gcpros automatically is that sometimes the Lisp_Objects that have to be protected aren't even declared - they're temporaries. For example return Fcons_user1 (Fcons_user2 (Fcons (Qnil, Qnil))); This has to be expanded into { Lisp_Object x = Qnil, y = Qnil, z = Qnil; struct gcpro gcpro1, gcpro2, gcpro3; GCPRO3 (x, y, z); x = Fcons (Qnil, Qnil); y = Fcons_user2 (x); z = Fcons_user3 (y); UNGCPRO; return z; } (this example could of course be optimized - but this is the obvious translation) (this example also shows how incredibly ugly gcpros are) The current source code does a lot fewer GCPROs than the above, because of detailed knowledge of various functions (can they gc, or could they return a fresh object). It is possible to determine this kind of information from a global analysis of the source code, but it won't be easy. In particular, the C preprocessor will tend to make the source more resistant to automated understanding by your gcpro preprocessor. E.g. #ifdef MULE #define FROB(x) Fcons_user1 (Fcons_user2 (Fcons (x, x))) #else #define FROB(x) Fcons_user3 (Fcons_user4 (Fcons (x, x))) #endif ... return FROB(Qnil); Nix> and could write a fairly simple preprocessor that takes (one file of) Nix> the XEmacs C code and spits out a (transient) source file with Nix> UNGCPRO-alikes inserted at the end of each block where they are Nix> allocated. That would let us dump visible GCPROs in the source yet keep Nix> type-accuracy... >> I've taken a look at the Boehm gc in the past, considering its >> possible use in XEmacs. I rejected using it because: >> - it's non-portable (reading its portability layer is frightening) Nix> That's my biggest worry, too. I don't really mind which GC I go to, Nix> really; my primary goals are zapping the GCPRO construct as it currently Nix> exists (although keeping its type-accuracy would be nice) and getting Nix> something with better VM behaviour. Both of these can be done without Nix> actually replacing the GC; it just seemed simpler to do that. >> However, the gcc project has recently started using boehm gc. Since >> gcc is very portable, they must be making any necessary portability >> improvements to boehm gc as they go. Nix> Not yet. There are many architectures that GCC works on that libjava and Nix> parts of libobjc (the primary users of that gc) do not work on, and the Nix> boehm-gc in the GCC tree is a rather aged implementation. Bad news. Nix> When version 6 comes out Hans has said he will move to making the GCC Nix> tree's copy of the collector the master copy; if I'm still using the Nix> boehm-gc in XEmacs by then, I'll migrate it to that version. Very good news. >> Hmmm. It seems to me mark() has to examine most of the heap anyways. >> Unless you do a lot of work, boehm gc might end up examining even more >> memory than the existing mark. Most of the guts of existing >> Lisp_Objects are other Lisp_Objects, so there isn't a whole lot of >> scope for GC_malloc_atomic() to be a big win. Nix> This isn't true of anything except for cons cells and other sequences, Nix> and things like hash tables, is it? For `leaf' objects (string data &c), Nix> a conservative collector like Boehm's would wind up tracing them for Nix> pointers they couldn't possibly contain pointers to anything. Nix> (It's true that the gains from this bit over the *existing* allocator Nix> would be marginal; it reduces the negative effects of using a Nix> conservative collector substantially, though. It's a tradeoff; GCPRO Nix> versus the occasional malloc_atomic()... but the more I think about it Nix> the more it seems to me that a preprocessor that automatically inserts Nix> UNGCPROs is the right way to go; type-accuracy *and* maintainability, Nix> wow ;) ) Sorry, I meant there's little scope for a Boehm mark() to be better than the existing mark() because the existing one, via lisp object type mark methods, already knows exactly which object components might contain other Lisp_Objects. The mark bitmap won't help you much during the mark phase, in fact it ought to make things worse. The place where the Boehm gc shines performance wise is not during gc at all, but in the fact that gcpros can be dispensed with entirely while the mutator runs. Normally the advantage of mark&sweep over reference counting is: not slowing down the mutator. But gcproing does slow down the mutator. But I really don't know how much overhead we have from GCPROing, and it's hard to measure. My random guess is that 10% of the runtime of lisp function calls that do no work (i.e. return immediately) is taken up with gcproing. >> we can also put the mark-bits into a bitmap without complete >> boehmification. Understanding and extracting that code from boehm gc >> would be a much smaller and still very instructive project. Nix> True. I think, for the first implementation, I'll go with Nix> -- Richard's infrastructure (general modifications), forward-ported to Nix> 21.4; they look praiseworthy, and the forward-porting job doesn't Nix> look too enormous Nix> -- A bitmapped version of the current GC Nix> -- and, if I can get it to work --- and I damned well will ;) --- a Nix> GCPROizing preprocessor, so we can dump *visible* evidence of GCPRO Nix> (that being what does the harm; we can forget it exists completely Nix> if it is automatically maintained!) Harder than it looks, as I try to point out above. I'll be very impressed if you can produce a reliable GCPROizing preprocessor. I think you'll have to run the source through the C preprocessor first, which means your gcproizer has to run every build. Using the standard Unix utilities, this will be hard (i.e. you'll want to use something like perl or python). Most free software projects don't have such dependencies for non-maintainer-mode, but I think the time might be right to introduce such a dependency for xemacs. Nix> (I might even be able to make it so that only one GCPRO/UNGCPRO Nix> operation needs to be done for an entire stack frame, because the Nix> preprocessor knows exactly what Lisp_Objects have been allocated in Nix> a given frame, so it can insert a single operation that does all the Nix> work...) I like your plan very much. ObAdvice: Have you read the internals manual section that deals with gc? From sperber@informatik.uni-tuebingen.de Tue May 22 05:58:45 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA18863; Tue, 22 May 2001 05:58:44 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 733BA49E; Tue, 22 May 2001 11:58:41 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4M9wfg07167; Tue, 22 May 2001 11:58:41 +0200 (CEST) (envelope-from sperber) To: Martin Buchholz Cc: Nix , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 May 2001 11:58:40 +0200 In-Reply-To: <15114.13741.708870.454969@gargle.gargle.HOWL> (Martin Buchholz's message of "Tue, 22 May 2001 18:47:25 +0900") Message-ID: Lines: 17 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Martin" == Martin Buchholz writes: Martin> The place where the Boehm gc shines performance wise is not during gc Martin> at all, but in the fact that gcpros can be dispensed with entirely Martin> while the mutator runs. Normally the advantage of mark&sweep over Martin> reference counting is: not slowing down the mutator. Erh, yeah, well, at the cost of introducing an entire additional phase to the execution. I'm sure GCPRO is not a very relevant factor during runtime. Garbage collection is. Adding a bunch of GCPRO's is not going to make much of a difference to execution time. That difference should be more than offset by the speed gain from a decent collector. You can't get much slower than the one in Emacs. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From Olivier.Fambon@inrialpes.fr Tue May 22 06:01:20 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA19023 for ; Tue, 22 May 2001 06:01:19 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id LAA29396; Tue, 22 May 2001 11:59:47 +0200 (MEST) Received: from inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f4MA10d26450; Tue, 22 May 2001 12:01:00 +0200 (MEST) Message-ID: <3B0A39EC.C9DACFBC@inrialpes.fr> Date: Tue, 22 May 2001 12:05:32 +0200 From: Olivier Fambon X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Stodghill , xemacs-beta@xemacs.org Subject: Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B0A36C2.92092FDD@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Olivier Fambon wrote: > > It seems to be a font-lock problem, coz if you do that with > xemacs -nw -vanilla > > it works, as long as you don't go M-x font-lock-mode > Hum. Not really... My fault. Miss-manipulated. The funny thing is that if you M-q on the first citation line, it works !!! eg: --text follows this line-- a > b <- M-q here: fine > c <- M-q here: inf loop > Moreover, C-g works in this case (tty). This holds. From sperber@informatik.uni-tuebingen.de Tue May 22 06:01:16 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA19018; Tue, 22 May 2001 06:01:15 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id B2AAD1061; Tue, 22 May 2001 12:00:57 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4MA0vO07176; Tue, 22 May 2001 12:00:57 +0200 (CEST) (envelope-from sperber) To: Martin Buchholz Cc: Nix , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 22 May 2001 12:00:57 +0200 In-Reply-To: <15114.13741.708870.454969@gargle.gargle.HOWL> (Martin Buchholz's message of "Tue, 22 May 2001 18:47:25 +0900") Message-ID: Lines: 21 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Martin" == Martin Buchholz writes: Martin> I think you'll have to run the source through the C preprocessor Martin> first, which means your gcproizer has to run every build. Using the Martin> standard Unix utilities, this will be hard (i.e. you'll want to use Martin> something like perl or python). Most free software projects don't Martin> have such dependencies for non-maintainer-mode, But we have plenty of library dependencies which are actually harder to satisfy in a lot of setups. Martin> but I think the time might be right to introduce such a Martin> dependency for xemacs. Yes, but preferably not on Perl or Python. You want an actual C frontend for this. I already have most of one lying around here for the job. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From martin@m17n.org Tue May 22 06:24:53 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA20001; Tue, 22 May 2001 06:24:51 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4MAP6p21116; Tue, 22 May 2001 19:25:06 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id TAA28607; Tue, 22 May 2001 19:24:45 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4MAOj415856; Tue, 22 May 2001 19:24:45 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.15980.951322.824687@gargle.gargle.HOWL> Date: Tue, 22 May 2001 19:24:44 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: Nix , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "MS" == Michael Sperber writes: >>>>> "Martin" == Martin Buchholz writes: Martin> I think you'll have to run the source through the C preprocessor Martin> first, which means your gcproizer has to run every build. Using the Martin> standard Unix utilities, this will be hard (i.e. you'll want to use Martin> something like perl or python). Most free software projects don't Martin> have such dependencies for non-maintainer-mode, MS> But we have plenty of library dependencies which are actually harder MS> to satisfy in a lot of setups. The library dependencies should mostly be optional. E.g. X11 is optional. Martin> but I think the time might be right to introduce such a Martin> dependency for xemacs. MS> Yes, but preferably not on Perl or Python. You want an actual C MS> frontend for this. I already have most of one lying around here for MS> the job. Writing it in C is the Right Thing - portable and fast. But also difficult. If you already have one, use it, share it. From jmincy@muniversal.com Tue May 22 09:17:00 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA29653; Tue, 22 May 2001 09:16:50 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 152C1k-0007Eh-00 ; Tue, 22 May 2001 09:16:44 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15114.26434.540000.531175@antarres.muniversal.com> Date: Tue, 22 May 2001 09:18:58 -0400 To: "Jay Levitt" Cc: "Jonathan Harris" , <08.58016472@telia.com>, "'Michael Sperber [Mr. Preprocessor]'" , , Subject: Re: Help test EFS In-Reply-To: <002601c0e26f$607f3310$46fb000a@office> References: <01C0E25B.91743FB0.08.58016472@telia.com> <3B09B5A4.CEB137E7@tardis.ed.ac.uk> <002601c0e26f$607f3310$46fb000a@office> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Jay Levitt writes: > Since this is getting pretty ugly, an alternative is to stick with > telling users to customise efs-ftp-program-name to point to the version > of ftp.exe that ships with Windows. Can XEmacs elisp access Windows environment variables? If so, this should always be available at %SystemRoot%\system32\ftp.exe, at least on NT/2000 boxes. c:\WINDOWS\FTP.EXE on w98. I have a vague worry that using windows ftp.exe will be swapping one set of problems for another... -jeff ----- Original Message ----- From: "Jonathan Harris" Sent: Monday, May 21, 2001 8:41 PM > Jerker Haglund wrote: > > > put c:\myweb\behag\anmlan.htm /html/behag/anmlan.htm > > /usr/bin/ftp: local: c:mywebbehaganmlan.htm: No such file or directory > > The fix to efs-tmp-name-template in efs release 1.20pre1 / package 1.25 > is insufficient since it isn't just temporary file names that get passed > to the ftp program, as the above example shows. A hack like the > following is also required. > > (defun efs-maybe-quote-local-path (path) > "Quote special characters in PATH if `efs-quote-local-paths' is > non-nil." > + (if (eq system-type 'windows-nt) > + (setq path (replace-in-string path "\\\\" "/"))) > (if efs-quote-local-paths > (apply (function concat) > (mapcar (function > > > Since this is getting pretty ugly, an alternative is to stick with > telling users to customise efs-ftp-program-name to point to the version > of ftp.exe that ships with Windows. From james@eecs.ku.edu Tue May 22 17:36:44 2001 Received: from stephens.ittc.ukans.edu (stephens.ittc.ukans.edu [129.237.125.220]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA09077 for ; Tue, 22 May 2001 17:36:43 -0400 Received: from diannao.ittc.ukans.edu (IDENT:root@diannao.ittc.ukans.edu [129.237.126.112]) by stephens.ittc.ukans.edu (8.11.2/8.11.2/ITTC-NOSPAM-NOVIRUS-2.2) with ESMTP id f4MLagQ05056 for ; Tue, 22 May 2001 16:36:42 -0500 Received: by diannao.ittc.ukans.edu (8.9.3/KU-4.0-client) id QAA17493; Tue, 22 May 2001 16:48:11 -0500 Sender: james@ittc.ukans.edu From: james@xemacs.org To: xemacs-beta@xemacs.org Subject: Preprocessor Date: 22 May 2001 16:48:11 -0500 Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= The talk about using a preprocessor to insert GCPRO and UNGCPRO has convinced me to post a proposal of my own a bit early. I also think that a specialized preprocessor is a good idea, but for a different purpose. I was actually going to work on cleaning up and extending this a bit this week, but I'd better throw it out now while people are thinking about preprocessors. Forgive the rough spots. If you like what I propose in principle, but hate the syntax, please suggest an alternate syntax. I'm not a language guy, so I'll willingly accept suggestions for improvement from those with better ideas than mine. Incidentally, I agree with Martin that using a preprocessor to insert GCPRO/UNGCPRO is going to be very hard. But I think the use I propose will actually be pretty straightforward. Let me know what you think. If you post to the list, don't bother CC:ing me. Thanks, -- Jerry James --=-=-= Content-Disposition: attachment; filename=xemacstrans.txt Content-Description: Preprocessor proposal XEmacs Internal and External APIs: A Modest Proposal Jerry James May 22, 2001 1. Introduction The introduction of loadable modules has exposed the internals of XEmacs to outside developers. This situation is obviously undesirable, as it allows developers to write code that will break due to small internal changes. That, in turn, puts pressure on XEmacs developers to reduce or eliminate changes to existing functions, variables, and data structures. Clearly, a fixed and limited API should be exposed to module writers. The API should be written in a way that maximizes developer flexibility, yet gives enough power to the module writer to enable nontrivial modules to be developed. It should, at the least, give the module writer access to anything visible at the Lisp level. Developing such an API is called the "external module API problem" throughout this document. It would be a mistake to limit attention to loadable modules. XEmacs is a large enough piece of software that it has a nontrivial internal structure. We should take this opportunity to reflect on the internal APIs that various parts of XEmacs expose to other parts. Determining what those APIs should be is called the "internal API problem" throughout this document. This proposal attempts to address both the external module API problem and the internal API problem (collectively the "API problems"). The rest of this proposal is organized as follows. Part 2 proposes a significant change to the way in which C/Lisp "glue" code is structured. Part 3 shows how the proposal in part 2 solves the API problems. Part 4 discusses the pros and cons of this proposal. Part 5 discusses an approach to implementing the proposal. Part 6 discusses the capabilities of the proposer. Part 7 contains some concluding remarks. 2. A New Glue: Changing the way that Lisp-visible C code is written The currently available way of writing Lisp-visible C code suffers from some restrictions, largely due to limitations of the C preprocessor. However, the need to ship C code to those who build XEmacs does not necessarily imply that all code has to be written in C! In particular, a source-to-source translator with more capabilities than the C preprocessor could be used to write the C/Lisp glue code in a more Lispish fashion. Whether the ultimate source, the preprocessed source, or both would be shipped with releases is not specified in this proposal. This topic should be discussed by the current developers if this proposal is found to have any merit. The preprocessor would have several responsibilities, detailed in the following subsections. A. Function and special form declarations Currently, Lisp-visible C functions are declared with the DEFUN macro, defined in lisp.h. That macro has some limitations, including: 1. Limited number of required parameters: currently the limit is 8. While this could be extended, the current scheme requires *some* fixed limit. 2. Unhelpful documentation strings with MANY: no documentation string is generated for functions that accept a variable number of arguments (the equivalent of &rest in Lisp). If you want help to display the argument list, you have to write the list yourself in the function documentation. This has not been done for many functions (e.g., concat, max, format). 3. Need to know whether a function with MANY is being called: the calling convention is different for functions that do not use MANY (one C parameter per Lisp parameter) and functions that do use MANY (two C parameters: a length, and an array of parameters). 4. Inability to automatically generate the C function name: you have to write essentially the same name twice, once in the Lisp form (e.g., "widget-apply"), and once in the C form (e.g., Fwidget_apply). Nothing prevents a developer from making the Lisp and C names completely unrelated. 5. Requirement to list functions names in syms_of_xxx manually: this is one of those trivial requirements that a computer can do better than a human. The computer never gets tired or overlooks a function. The preprocessor would instead allow code like the following to be written: DEFUN lisp-function-name (arglist) "docstring" "interactive-spec" { body; } where the arglist could contain &rest and &optional declarations. A &rest parameter would be given a Lisp list containing the actual parameters (if any, Qnil if there are none.) For example, the definition of max would look like this: DEFUN max (num &rest nums) "Return largest ..." 0 { ... } ###THINK ABOUT THIS### Making rest args contain Lisp lists is an incompatible change from the current code. It might be better to stick with two arguments: a length and an array. Otherwise, every MANY function will have to be rewritten in a nontrivial way. There would also be a companion DEFSPECIAL for declaring special forms (with unevaluated arguments). The syntax would be equivalent in every other respect, however. The developer would put nothing in syms_of_xxx corresponding to the function declaration. B. Function calls When Lisp calls are made from the C level, the caller currently has to know: - whether the called function is declared in C or Lisp; - if in C, whether the called function takes MANY arguments or not. The calling convention is different for the three cases. Instead, we could use a uniform calling convention, which is mapped to one of these three cases automatically. The new function call syntax would be: FUNCALL (lisp-function-name args) and APPLY (lisp-function-name args) where the semantics are equivalent to the Lisp funcall and apply. C. Variable declarations The current state of Lisp variable declarations is not bad. But as long as we are considering a preprocessor, it behooves us to consider whether that state can be improved at all. With a preprocessor, we could lift the following restrictions: 1. Variables must be declared in vars_of_xxx: instead, we could declare them anywhere (e.g., close to related functions), and the preprocessor could move the declaration to vars_of_xxx automatically. 2. Inability to automatically generate the C variable name: this one has to be thought about carefully, however, due to the dual symbol/variable nature of such declarations and the inconsistent naming patterns in the current code. (That is, some code uses the convention that the Lisp variable foo is called Vfoo in C, and some code uses foo in C as well.) D. Variable access Accessing a Lisp variable from C requires the programmer to know whether the variable is declared in Lisp or C. Instead, we will use the following syntax to read a Lisp variable: LISP_VAR (lisp-variable-name) and this syntax to write a Lisp variable: SETQ lisp-variable-name value; E. Documentation generation A preprocessor would render make-docfile superfluous. It would generate the docfile as it processed the input file. This may actually be a good thing, due to the primitive structure of make-docfile. It is easily fooled (try naming a local variable DEFVAR, for example), and is somewhat fragile (e.g., leave out the documentation comment on a DEFUN and see what happens). 3. Solving the API problems How does changing the glue code solve the API problems? It gives us a uniform way of declaring and accessing Lisp-visible entities in C. Behind the scenes, the preprocessor can select the most efficient mechanism available for a given access, within the current implementation. Thus, a function can migrate from Lisp to C (or vice versa) and no calling code needs to be changed. The preprocessor will change the implementation of calls, but no human needs to be explicitly aware of this. A simple way of accomplishing this is to have the preprocessor automatically generate a list of C-visible Lisp functions and variables. Then accesses to anything on the list can be done in the direct C fashion. Accesses to anything not on the list have to go through the existing Lisp access mechanisms (e.g., call0, call1). This implies that the preprocessor must make at least 2 passes through all of the sources. 4. Pros and Cons Few changes to large systems are unequivocally good. This section presents the good points and the bad points about the proposed change, so that they can be balanced against one another. A. Pros 1. Greater modularity in the internals. That is, the various parts of XEmacs will be more loosely coupled, enabling future migrations between C and Lisp to occur more easily. 2. Ability to target both C and C++. If somebody figures out how to implement lrecords as C++ classes, for example, or error signalling using C++ throw/catch, the preprocessor could be extended to allow those entities to be specified more abstractly. Then a command-line switch could be used to generate either C or C++ code. 3. Meaningful argument lists for Lisp functions defined in C. See section 2A. 4. Subsume the documentation generator. See section 2E. B. Cons 1. Compatibility with FSF Emacs is severely reduced. This will make future synchs more difficult. 2. C/Lisp variable use more obtuse. Now, the C variable that is used as storage for the Lisp variable can be accessed like any normal C variable. The preprocessor would require it to be accessed using a more arcane syntax. 3. Syntax checking. The preprocessor would either have to deal with any possible C syntax error in a manner essentially equivalent to the C compiler itself, or be able to complete its work successfully in the presence of syntax errors. 5. Implementation Get a C compiler front end from somewhere. Michael Sperber hinted that he has something like that. Otherwise, look into cpplib from the gcc folks. Otherwise otherwise, get a lex/yacc (flex/bison) C grammar from somewhere (there are lots of them around) and write the rest ourselves. Extend the accepted syntax to accept the constructs given above. Use the list structure described in section 3 along with a 2-pass preprocessor to do the transformation. 6. About the Proposer This is the part where I try to inspire you with confidence in my ability to actually pull this off. My c.v. is available on my web page (), if that helps. Let me just say that I have a Ph.D. in Computer Science from the University of California, Santa Barbara of very recent vintage (March 2000). My work has largely been in the area of distributed systems. However, I have worked with parsers and source-to-source translators before. For example, I wrote the JParse Java translator and type checker () which I used as part of a source-to-source translator in the Kan distributed Java object system (). I also wrote a very large XEmacs external module, an interface to IBM's ViaVoice (). I am an assistant professor in the Electrical Engineering & Computer Science Department at the University of Kansas. My favorite vices are chocolate, 80's rock music, and philosophy (especially cosmology). 7. Conclusion This proposal actually dodges a fairly thorny problem: what about the non-Lisp-visible parts of the internals? Nevertheless, I think this proposal, if implemented, would represent a big step forward in managing the XEmacs APIs successfully. There are cons, but in my opinion they are outweighed by the pros. --=-=-=-- From jhar@tardis.ed.ac.uk Tue May 22 19:21:55 2001 Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA14623; Tue, 22 May 2001 19:21:54 -0400 Received: from marginal.demonadsltrial.co.uk ([193.195.64.136] helo=tardis.ed.ac.uk) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 152LTC-000Lwq-0K; Tue, 22 May 2001 23:21:42 +0000 Message-ID: <3B0AF486.ADAD4E25@tardis.ed.ac.uk> Date: Wed, 23 May 2001 00:21:42 +0100 From: Jonathan Harris X-No-Archive: Yes X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Mincy CC: Jay Levitt , 08.58016472@telia.com, "'Michael Sperber [Mr. Preprocessor]'" , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <01C0E25B.91743FB0.08.58016472@telia.com> <3B09B5A4.CEB137E7@tardis.ed.ac.uk> <002601c0e26f$607f3310$46fb000a@office> <15114.26434.540000.531175@antarres.muniversal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff Mincy wrote: > c:\WINDOWS\FTP.EXE on w98. > > I have a vague worry that using windows ftp.exe will be swapping > one set of problems for another... We shouldn't assume that users have cygwin's ftp.exe installed, so we ought to solve both cases (or insist that all users use Windows' ftp.exe). Michael, efs package 1.25 introduces a new error relative to 1.22 when used with the Windows' ftp program on Windows 98. Eg on login: ... quote syst 215 UNIX Type: L8 quote cwd /disk/home/users0/jhar/ 250 CWD command successful. ls "-al" C:/Temp/efsasvqD- 200 PORT command successful. quote site idle 150 Opening ASCII mode data connection for file list. 226 Transfer complete. ftp: 2489 bytes received in 0.00Seconds 2489000.00Kbytes/sec. quote cwd /disk/home/users0/ 500 'SITE IDLE' not understood. ... efs is not waiting for the "ls" to complete before moving on to "quote site idle", and is therefore getting very confused. I haven't figured what's going wrong yet. Jonathan. -- Jonathan Harris | jhar@tardis.ed.ac.uk London, England | Jonathan.Harris@symbian.com From steve@turnbull.sk.tsukuba.ac.jp Wed May 23 02:19:47 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA03019 for ; Wed, 23 May 2001 02:19:46 -0400 Received: by localhost id m152RzP-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 23 May 2001 15:19:23 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.22109.504469.30912@turnbull.sk.tsukuba.ac.jp> Date: Wed, 23 May 2001 15:19:09 +0900 To: "Hummel Family" Cc: Subject: (no subject) In-Reply-To: <000c01c0e294$fa647a60$72a6a1d1@g9e0c4> References: <000c01c0e294$fa647a60$72a6a1d1@g9e0c4> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hummel" == Hummel Family writes: Hummel> I would like to make my student class list appear in Hummel> kanji, so they can see what it would look like. How can I Hummel> download a font to do this? X11 distributions come with a few standard Asian fonts in BDF (bitmap distribution format) form. There are also the Wadalab Japanese fonts and some Chinese fonts available from the Ghostscript distribution http://ghostscript.sourceforge.net/, and some CID Postscript fonts based on the Wadalab fonts from Adobe, distributed by O'Reilly ftp://ftp.oreilly.com/published/oreilly/nutshell/cjkv, in the fonts subdirectory IIRC. TrueType/Windows, I don't know. You could try microsoft.com. Everybody I know uses fonts from their Windows system or buys them. I believe that there are programs to convert BDF or Postscript fonts to TrueType format. There is also the Mojikyo project. http://www.mojikyo.org/ -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Wed May 23 03:37:26 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA05677 for ; Wed, 23 May 2001 03:37:24 -0400 Received: by localhost id m152TCl-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 23 May 2001 16:37:15 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> Date: Wed, 23 May 2001 16:37:02 +0900 To: Hrvoje Niksic Cc: XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge In-Reply-To: References: <3B09E4EF.F70F890E@666.com> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> [ Why is this discussion not on xemacs-beta? ] It is now. Recap: Adrian suggests fixing up our "Descriptive Group Name" on SourceForge, in particular, to XEmacs Multi-Platform Open Source Editor Ben Wing proposes an amendment: Ben> why not just be specific about what we support? XEmacs, an Open Source Editor for MS Windows and Unix Steve Youngs writes: >> Adrian, I like your change, but I think it's a little bashful. >> How about: >> XEmacs - The Multi-Platform Open Source Editor. >> See the subtle difference? Yeah. I bet RMS will too. Don't be so competitive. ;-) Hrvoje> How about: XEmacs - the Multi-Platform Open Source Editor and Environment My two cents: XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor I'm really tempted by "More than just another pretty Emacs", but I've already gotten enough grief about my .sig. ;-) The floor is open... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From martin@m17n.org Wed May 23 04:05:03 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA06789; Wed, 23 May 2001 04:05:02 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4N85Ip02135; Wed, 23 May 2001 17:05:18 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id RAA06647; Wed, 23 May 2001 17:04:57 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4N84uO05931; Wed, 23 May 2001 17:04:56 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.28456.826611.66425@gargle.gargle.HOWL> Date: Wed, 23 May 2001 17:04:56 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: james@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: Preprocessor In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid I too have thought about the idea of a Lispifying preprocessor for C, to avoid all the kludges necessitated by CPP and the broken C language. I've been tempted to make changes similar to the ones you propose. James, you have looked at other implementations that have done this, right? I believe one of the free lisps (CLISP?) does something like this. In my opinion, the disadvantages outweigh the advantages, at least for the changes you are planning. When the changes are done, no end user will see any advantage from the changes, except that build times will be a little slower. And the advantages for the developer are smaller than you might think. Mostly cosmetic. I doubt that the changes will succeed in making the module API that much more stable. With or without the changes, the stability of the module API depends on the will of the future xemacs maintainers. People often underestimate the impact of huge changes like this. There will be a ton of documentation that needs to be aligned with the new world. Will you remember to fix up the "make TAGS" target in the top-level Makefile? Will xemacs still be debuggable? Will .gdbinit keep working? Will xemacs know to use cc-mode for editing those funky .xc files? Will cc-mode understand the DEFSPECIAL foo ... as a function definition? Will func-menu? Will etags? Etc, etc. And some things will break that you cannot fix, because they're not part of xemacs. Like some developer's function cgrep { find . -name '*.[ch]' -print | xargs grep "$@" ; } Many of these things are trivial, but for many of them, _others_ are paying the price. Everybody wants to change the world. But it's a lot harder to deal with _all_ the consequences. Now I didn't say we shouldn't have a preprocessor for C. But we better have a damn good reason. Getting rid of GCPROs seems to me a lot better reason than the "better API" reason. Curmudgeonly yours, Martin From rendhalver@users.sourceforge.net Wed May 23 04:43:03 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA08406 for ; Wed, 23 May 2001 04:42:59 -0400 Received: from ulthwe.dyndns.org (p3-tnt1.brs.ihug.com.au [203.173.188.3]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id SAA03330; Wed, 23 May 2001 18:42:38 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p3-tnt1.brs.ihug.com.au [203.173.188.3] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15115.30573.418697.6190@ulthwe.dyndns.org> Date: Wed, 23 May 2001 18:40:13 +1000 To: "Stephen J. Turnbull" Cc: Hrvoje Niksic , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge In-Reply-To: <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Stephen J. Turnbull writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> [ Why is this discussion not on xemacs-beta? ] > > It is now. Recap: Adrian suggests fixing up our "Descriptive Group > Name" on SourceForge, in particular, to > > XEmacs Multi-Platform Open Source Editor > > Ben Wing proposes an amendment: > > Ben> why not just be specific about what we support? > > XEmacs, an Open Source Editor for MS Windows and Unix > > Steve Youngs writes: > > >> Adrian, I like your change, but I think it's a little bashful. > >> How about: > > >> XEmacs - The Multi-Platform Open Source Editor. > > >> See the subtle difference? > > Yeah. I bet RMS will too. Don't be so competitive. ;-) > > Hrvoje> How about: > > XEmacs - the Multi-Platform Open Source Editor and Environment > > My two cents: > > XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor > > I'm really tempted by "More than just another pretty Emacs", but I've > already gotten enough grief about my .sig. ;-) > > The floor is open... > how about this XEmacs - Open Source, Multi-platform, Multi-Language, and _More_ Than Just an Editor to keep the Mule crowd or XEmacs - Open Source, Multi-platform, Multi-Language, and a Way Of Life (thanks to steve youngs .sig for this) we could add (and better then vi) but that we will get even more flak for that :) > I'm really tempted by "More than just another pretty Emacs", but I've > already gotten enough grief about my .sig. ;-) :) > The floor is open... but what happens if we fall thru ??? -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From hniksic@arsdigita.com Wed May 23 09:03:00 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA19021 for ; Wed, 23 May 2001 09:03:00 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152YHy-0005Jf-00 for ; Wed, 23 May 2001 15:02:58 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 23 May 2001 15:02:58 +0200 In-Reply-To: <15115.28456.826611.66425@gargle.gargle.HOWL> (Martin Buchholz's message of "Wed, 23 May 2001 17:04:56 +0900") Message-ID: Lines: 14 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Martin Buchholz writes: > In my opinion, the disadvantages outweigh the advantages, at least for > the changes you are planning. When the changes are done, no end user > will see any advantage from the changes, except that build times will > be a little slower. The *huge* disadvantage of using a custom preprocessor is that in that case your code is no longer C code, which means that it cannot be analyzed with the usual C tools such as lint or cflow, debugged with GDB, etc. If we're going through that route, then let's rather work on a full elisp-to-C translator and write as much stuff as possible in elisp. From martin@m17n.org Wed May 23 09:17:04 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA19770 for ; Wed, 23 May 2001 09:17:03 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4NDHDp05183; Wed, 23 May 2001 22:17:13 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id WAA08261; Wed, 23 May 2001 22:16:51 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4NDGpa13239; Wed, 23 May 2001 22:16:51 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.47171.280162.963844@gargle.gargle.HOWL> Date: Wed, 23 May 2001 22:16:51 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: References: <15115.28456.826611.66425@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Martin Buchholz writes: >> In my opinion, the disadvantages outweigh the advantages, at least for >> the changes you are planning. When the changes are done, no end user >> will see any advantage from the changes, except that build times will >> be a little slower. Hrvoje> The *huge* disadvantage of using a custom preprocessor is that in that Hrvoje> case your code is no longer C code, which means that it cannot be Hrvoje> analyzed with the usual C tools such as lint or cflow, debugged with Hrvoje> GDB, etc. Well, gdb can be taught (perhaps) about the source code through #line directives in the generated source. To solve the problem of printing lisp variables like bell-volume, when C only understands bell_volume, we would have to teach gdb how to turn lisp variable names into C variable names, but that strains the capabilities of gdb's command language. Anyways, yes, the resulting program will be much harder to debug. And this preprocessor is supposed to make the developer's life easier. From james@eecs.ku.edu Wed May 23 10:28:15 2001 Received: from stephens.ittc.ukans.edu (stephens.ittc.ukans.edu [129.237.125.220]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA23376; Wed, 23 May 2001 10:28:14 -0400 Received: from diannao.ittc.ukans.edu (IDENT:root@diannao.ittc.ukans.edu [129.237.126.112]) by stephens.ittc.ukans.edu (8.11.2/8.11.2/ITTC-NOSPAM-NOVIRUS-2.2) with ESMTP id f4NERsQ09139; Wed, 23 May 2001 09:27:54 -0500 Received: by diannao.ittc.ukans.edu (8.9.3/KU-4.0-client) id JAA18270; Wed, 23 May 2001 09:39:31 -0500 Sender: james@ittc.ukans.edu From: Jerry James To: Martin Buchholz Cc: Hrvoje Niksic , XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> Date: 23 May 2001 09:39:31 -0500 In-Reply-To: <15115.47171.280162.963844@gargle.gargle.HOWL> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Wed, 23 May 2001 at 22:16:51 +0900, Martin Buchholz wrote: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> The *huge* disadvantage of using a custom preprocessor is that in that > Hrvoje> case your code is no longer C code, which means that it cannot be > Hrvoje> analyzed with the usual C tools such as lint or cflow, debugged with > Hrvoje> GDB, etc. > > Well, gdb can be taught (perhaps) about the source code through #line > directives in the generated source. > > To solve the problem of printing lisp variables like bell-volume, when > C only understands bell_volume, we would have to teach gdb how to turn > lisp variable names into C variable names, but that strains the > capabilities of gdb's command language. I've hacked gdb internals before. You could teach gdb about the enhanced language, but then all the developers would have to used a custom gdb. > Anyways, yes, the resulting program will be much harder to debug. And > this preprocessor is supposed to make the developer's life easier. Yep. All good enough reasons to shoot this proposal down. I'll go sit back in my corner and stew some more on the module interface, then. Somewhat ironically, I actually considered this preprocessor a step towards an Elisp-to-C translator, using the source to be preprocessed as the target of that translator. I'll rethink that, too. -- Jerry James, who appreciates curmudgeons that prevent young hotheads from unnecessarily tilting with windmills From mac@watson.verisity.com Wed May 23 11:23:56 2001 Received: from watson.verisity.com (verisity41.verisity.com [216.216.10.41]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA26463 for ; Wed, 23 May 2001 11:23:55 -0400 Received: from mac.verisity.com (mac-adsl [209.233.26.169]) by watson.verisity.com (8.11.3/8.11.3/Verisity+Hesiod (SDM)) with ESMTP id f4NFM6r29783; Wed, 23 May 2001 08:22:07 -0700 (PDT) Received: (from mac@verisity.com) by mac.verisity.com (8.11.0/8.11.0) id f4NFMnZ01647; Wed, 23 May 2001 08:22:49 -0700 From: Michael McNamara MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15115.54751.503841.217389@mac.verisity.com> Date: Wed, 23 May 2001 08:22:49 -0700 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: References: <15115.28456.826611.66425@gargle.gargle.HOWL> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: mac@verisity.com Hrvoje Niksic writes: > Martin Buchholz writes: > > > In my opinion, the disadvantages outweigh the advantages, at least for > > the changes you are planning. When the changes are done, no end user > > will see any advantage from the changes, except that build times will > > be a little slower. > > The *huge* disadvantage of using a custom preprocessor is that in that > case your code is no longer C code, which means that it cannot be > analyzed with the usual C tools such as lint or cflow, debugged with > GDB, etc. You fail to mention the potentially very great difficulty that would be felt by other important C tools named Hrvoje, Martin, James, and others!!! Seriously, I had to support code written by a fellow that wrote his own preprocessor (for an assembly language, but that doesn't matter). Basically, I inherited like 10,000 lines of code that was essentially in its own language. There were great plusses of his preprocessor -- a single statement did all the work for a procedure call -- but it was his language, and so debugging it was impossible (no text books available!) A better way to change the world might be to write elisp skeleton macros (using skeleton.el) that makes it real easy to insert C procedure definitions frameworks with all the interface stuff for elisp calling there already. In my mode verilog-mode.el, I have a AUTO feature that does local analysis of verilog code and then updates declarations based on other data that is in the procedure definition. Perhaps something could be written in elisp that would look at a C procedure, that is written according to a defined structure (I.E., has comments inserted at key points that say /* AUTOARG */ ) and update the routine definition to make it conform to what is needed for the c - elisp interface. > > If we're going through that route, then let's rather work on a full > elisp-to-C translator and write as much stuff as possible in elisp. Also a good idea. -- //' Michael McNamara _ // Sr VP Technology 650-934-6888 \ // Verisity Design 650-934-6801 FAX \// 408-930-6875 Cell -------------------------------------------------------------- Get my verilog emacs mode from From toy@rtp.ericsson.se Wed May 23 13:56:58 2001 Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA01984 for ; Wed, 23 May 2001 13:56:53 -0400 Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4NHuj808511 for ; Wed, 23 May 2001 12:56:45 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4NHujp25417 for ; Wed, 23 May 2001 12:56:45 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Wed May 23 12:56:44 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id NAA03512 for ; Wed, 23 May 2001 13:56:53 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id NAA01629; Wed, 23 May 2001 13:56:42 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> From: Raymond Toy Date: 23 May 2001 13:56:42 -0400 In-Reply-To: Message-ID: <4nsnhwdk4l.fsf@rtp.ericsson.se> Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Jerry" == Jerry James writes: Jerry> Somewhat ironically, I actually considered this preprocessor a step Jerry> towards an Elisp-to-C translator, using the source to be preprocessed as Jerry> the target of that translator. I'll rethink that, too. What's wrong with an Elisp-to-C translator? That's how GCL and friends compile their Lisp code. (Of course, I'd rather that elisp were closer to common lisp with real lexical closures by default.) Ray From CraigL@Knology.net Wed May 23 14:30:42 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id OAA04065 for ; Wed, 23 May 2001 14:30:41 -0400 Received: (qmail 29481 invoked from network); 23 May 2001 18:30:38 -0000 Received: from user-24-214-46-158.knology.net (HELO craigl.lanning.net.knology.net) (24.214.46.158) by user-24-214-63-14.knology.net with SMTP; 23 May 2001 18:30:38 -0000 From: Craig Lanning Message-ID: <15116.237.987151.376189@craigl.lanning.net> Date: Wed, 23 May 2001 14:26:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Raymond Toy Cc: XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: <4nsnhwdk4l.fsf@rtp.ericsson.se> References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid Raymond Toy writes: > >>>>> "Jerry" == Jerry James writes: > > Jerry> Somewhat ironically, I actually considered this preprocessor a step > Jerry> towards an Elisp-to-C translator, using the source to be preprocessed as > Jerry> the target of that translator. I'll rethink that, too. > > What's wrong with an Elisp-to-C translator? That's how GCL and > friends compile their Lisp code. (Of course, I'd rather that elisp > were closer to common lisp with real lexical closures by default.) Several years ago there was a project over at one of the German universities to write a Common Lisp to C Compiler (CLiCC). The last version (v0.6.5) claimed that it conformed to the Common Lisp specification in CLtL1 plus CLOS. The web site for the compiler is still active: http://www.informatik.uni-kiel.de/~wg/clicc.html A couple of years ago I used it to compile several small stand alone apps. I think that if someone were to pick up CLiCC and finish it (bring it up to ANSI Common Lisp compliance), it would probably make a good mechanism for developing something like XEmacs almost completely in Common Lisp. I intend to do something like this eventually. I would have already started, but all the inline comments are in German and I don't have the time to learn German just so that I can read the comments. Craig From mlivshin@bigfoot.com Wed May 23 14:45:36 2001 Received: from smtp.verisity.com (carmel.verisity.com [212.150.223.1]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA04845 for ; Wed, 23 May 2001 14:45:32 -0400 Received: from alps.verisity.com (alps [212.150.223.27]) by smtp.verisity.com (8.9.3/npuexaJIu?) with ESMTP id VAA16116; Wed, 23 May 2001 21:40:56 +0300 (IDT) To: Craig Lanning Cc: Raymond Toy , XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> In-Reply-To: <15116.237.987151.376189@craigl.lanning.net> From: Michael Livshin Organization: The Church of God the Utterly Indifferent Date: 23 May 2001 21:40:55 +0300 Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Craig Lanning writes: > Raymond Toy writes: > > What's wrong with an Elisp-to-C translator? That's how GCL and > > friends compile their Lisp code. (Of course, I'd rather that elisp > > were closer to common lisp with real lexical closures by default.) > > Several years ago there was a project over at one of the German > universities to write a Common Lisp to C Compiler (CLiCC). there are several (more or less compliant) Common Lisp implementations that can compile to C. there's also a Common Lisp package that implements Emacs Lisp in Common Lisp (mostly through macrology). the main problem being, of course, that you'd have to somehow fit the backend to the current Emacs runtime. -- The only complaint I have against WinDoze is that it doesn't always fail at install time. -- Mike Andrews, in s.d.m From toy@rtp.ericsson.se Wed May 23 14:51:23 2001 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA05213 for ; Wed, 23 May 2001 14:51:22 -0400 Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f4NIpLa24133 for ; Wed, 23 May 2001 13:51:22 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4NIpLp27215 for ; Wed, 23 May 2001 13:51:21 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Wed May 23 13:51:21 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id OAA04973; Wed, 23 May 2001 14:51:32 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id OAA02603; Wed, 23 May 2001 14:51:19 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: Craig Lanning Cc: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> From: Raymond Toy Date: 23 May 2001 14:51:19 -0400 In-Reply-To: <15116.237.987151.376189@craigl.lanning.net> Message-ID: <4npuczzyoo.fsf@rtp.ericsson.se> Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Craig" == Craig Lanning writes: Craig> Raymond Toy writes: >> >>>>> "Jerry" == Jerry James writes: >> Jerry> Somewhat ironically, I actually considered this preprocessor a step Jerry> towards an Elisp-to-C translator, using the source to be preprocessed as Jerry> the target of that translator. I'll rethink that, too. >> >> What's wrong with an Elisp-to-C translator? That's how GCL and >> friends compile their Lisp code. (Of course, I'd rather that elisp >> were closer to common lisp with real lexical closures by default.) Craig> http://www.informatik.uni-kiel.de/~wg/clicc.html Craig> A couple of years ago I used it to compile several small stand alone Craig> apps. I think that if someone were to pick up CLiCC and finish it (bring Craig> it up to ANSI Common Lisp compliance), it would probably make a good Craig> mechanism for developing something like XEmacs almost completely in Craig> Common Lisp. I intend to do something like this eventually. Craig> I would have already started, but all the inline comments are in Craig> German and I don't have the time to learn German just so that I can Craig> read the comments. Then why not use gcl then? It's still being actively worked on (probably in the context of maxima, though). And comments are in English. (This is what keeps me from hacking on clisp: German comments.) Making it fit with xemacs might not be so easy.... Ray From CraigL@Knology.net Wed May 23 15:01:23 2001 Received: from smtp3.knology.net (user-24-214-63-13.knology.net [24.214.63.13]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id PAA05758 for ; Wed, 23 May 2001 15:01:19 -0400 Received: (qmail 21688 invoked from network); 23 May 2001 18:57:43 -0000 Received: from user-24-214-46-158.knology.net (HELO craigl.lanning.net.knology.net) (24.214.46.158) by user-24-214-63-13.knology.net with SMTP; 23 May 2001 18:57:43 -0000 From: Craig Lanning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.2076.279253.644791@craigl.lanning.net> Date: Wed, 23 May 2001 14:57:32 -0400 To: Raymond Toy Cc: Craig Lanning , XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: <4npuczzyoo.fsf@rtp.ericsson.se> References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid Raymond Toy writes: > >>>>> "Craig" == Craig Lanning writes: > > Craig> A couple of years ago I used it to compile several small stand alone > Craig> apps. I think that if someone were to pick up CLiCC and finish it (bring > Craig> it up to ANSI Common Lisp compliance), it would probably make a good > Craig> mechanism for developing something like XEmacs almost completely in > Craig> Common Lisp. I intend to do something like this eventually. > > Craig> I would have already started, but all the inline comments are in > Craig> German and I don't have the time to learn German just so that I can > Craig> read the comments. > > Then why not use gcl then? It's still being actively worked on > (probably in the context of maxima, though). And comments are in > English. (This is what keeps me from hacking on clisp: German > comments.) > > Making it fit with xemacs might not be so easy.... The last time I tried gcl it claimed CLtL1 compatibility which doesn't include CLOS. Has it moved closer to ANSI Common Lisp? I already have some ideas for how to improve CLiCC (I just don't know where in the code to put them). Craig From toy@rtp.ericsson.se Wed May 23 15:07:21 2001 Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA06068 for ; Wed, 23 May 2001 15:07:21 -0400 Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4NJ7K811360 for ; Wed, 23 May 2001 14:07:20 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4NJ7Kp05381 for ; Wed, 23 May 2001 14:07:20 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Wed May 23 14:07:19 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id PAA05359; Wed, 23 May 2001 15:07:30 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id PAA02628; Wed, 23 May 2001 15:07:18 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: Craig Lanning Cc: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <15116.2076.279253.644791@craigl.lanning.net> From: Raymond Toy Date: 23 May 2001 15:07:18 -0400 In-Reply-To: <15116.2076.279253.644791@craigl.lanning.net> Message-ID: <4nlmnnzxy1.fsf@rtp.ericsson.se> Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Craig" == Craig Lanning writes: Craig> The last time I tried gcl it claimed CLtL1 compatibility which doesn't Craig> include CLOS. Has it moved closer to ANSI Common Lisp? I already I don't follow gcl but I don't think it's any closer. It's certainly still missing lots of ANSI stuff like defpackage, loop, etc. CLOS is still implemented with PCL (but then CMUCL uses PCL too). However as a backend for xemacs it's probably doesn't matter since xemacs code probably wouldn't use any of missing ANSI things. :-) Ray From CraigL@Knology.net Wed May 23 15:48:02 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id PAA08030 for ; Wed, 23 May 2001 15:48:01 -0400 Received: (qmail 1105 invoked from network); 23 May 2001 19:41:20 -0000 Received: from user-24-214-46-158.knology.net (HELO craigl.lanning.net.knology.net) (24.214.46.158) by user-24-214-63-14.knology.net with SMTP; 23 May 2001 19:41:20 -0000 From: Craig Lanning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.4480.267088.189134@craigl.lanning.net> Date: Wed, 23 May 2001 15:37:36 -0400 To: Raymond Toy Cc: Craig Lanning , XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: <4nlmnnzxy1.fsf@rtp.ericsson.se> References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <15116.2076.279253.644791@craigl.lanning.net> <4nlmnnzxy1.fsf@rtp.ericsson.se> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid Raymond Toy writes: > >>>>> "Craig" == Craig Lanning writes: > > Craig> The last time I tried gcl it claimed CLtL1 compatibility which doesn't > Craig> include CLOS. Has it moved closer to ANSI Common Lisp? I already > > I don't follow gcl but I don't think it's any closer. Then I would have a difficult time calling it "actively maintained". > It's certainly > still missing lots of ANSI stuff like defpackage, loop, etc. CLOS is > still implemented with PCL (but then CMUCL uses PCL too). However as > a backend for xemacs it's probably doesn't matter since xemacs code > probably wouldn't use any of missing ANSI things. :-) If those things were available in the development environment then XEmacs might use them :-) Modes are much easier to implement with an object system. Zmacs implements each mode (both major and minor) as flavors (Zetalisp object system). It makes it easier to inherit things that are common to all modes. Packages would be helpful in segregating the different lisp packages. Craig From hniksic@arsdigita.com Wed May 23 16:03:35 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA08835 for ; Wed, 23 May 2001 16:03:34 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152eqs-0006ff-00 for ; Wed, 23 May 2001 22:03:26 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 23 May 2001 22:03:26 +0200 In-Reply-To: <4npuczzyoo.fsf@rtp.ericsson.se> (Raymond Toy's message of "23 May 2001 14:51:19 -0400") Message-ID: Lines: 30 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Raymond Toy writes: > Then why not use gcl then? Because it's highly questionable how useful Gcl is. To be useful in short-term future, an elisp-to-C translator should not try to reimplement XEmacs from scratch or to turn Elisp into Common Lisp (or, for that matter, CLtL1). My favorite strategy for elisp-to-C is the one (I think) originally proposed by Kyle Jones some time ago: look at the opcodes that our current compiler generates. Now look at the code in bytecode.c that interprets it. A simple translator would simply take byte-compiled code and translate it into C that looks like bytecode.c, but inlined to directly *do* the stuff that P-code wants to do instead of interpreting the P-code. Although this looks simple-minded, I believe it would be a *huge* speed win over the current virtual machine. First, the cost of interpretation would be removed, which is by itself a big win -- the huge `case' statement would finally be eliminated. Secondly, such "unwound" C code would be processed by the C optimizer which would remove the many many redundant checks and thus make the code run really fast. The advantage of this strategy is that it opts for huge speedup in a *realistic* environment, i.e. it doesn't require rebuilding 100% of XEmacs to work. Furthermore, it builds on the work already invested in the byte-code compiler. From qtmstr@optonline.net Wed May 23 16:08:15 2001 Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA09061 for ; Wed, 23 May 2001 16:08:15 -0400 Received: from ool-18b88ad6.dyn.optonline.net (ool-18b88ad6.dyn.optonline.net [24.184.138.214]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with SMTP id <0GDT005P619QVZ@mta6.srv.hcvlny.cv.net> for xemacs-beta@xemacs.org; Wed, 23 May 2001 16:08:14 -0400 (EDT) Received: by ool-18b88ad6.dyn.optonline.net (sSMTP sendmail emulation); Wed, 23 May 2001 16:08:12 -0400 Date: Wed, 23 May 2001 16:08:12 -0400 From: QuoteMstr - Danny Colascione Subject: Re: Preprocessor In-reply-to: <"from hniksic"@arsdigita.com> To: XEmacs Beta List Mail-followup-to: XEmacs Beta List Message-id: <20010523160812.A5127@ool-18b88ad6.dyn.optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.2.5i References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> On Wed, May 23, 2001 at 10:03:26PM +0200, Hrvoje Niksic wrote: > Although this looks simple-minded, I believe it would be a *huge* > speed win over the current virtual machine. First, the cost of > interpretation would be removed, which is by itself a big win -- > the huge `case' statement would finally be eliminated. Secondly, such > "unwound" C code would be processed by the C optimizer which would > remove the many many redundant checks and thus make the code run > really fast. > > The advantage of this strategy is that it opts for huge speedup in a > *realistic* environment, i.e. it doesn't require rebuilding 100% of > XEmacs to work. Furthermore, it builds on the work already invested > in the byte-code compiler. I like this. I like it a lot. Just a question --- do you think it could be done in such a way that code could be loaded from shared libraries and, with a (supported) compiler, .el files could be compiled and loaded on the fly, just as .elc files are now? If so, it could provide a nice, fast (optional, as not everyone has a compiler) for .elc files themselves. -- "People are unlikely to become well- functioning, independent-minded adults and responsible citizens if they are raised in an intellectual bubble." From alexm@hsys.msk.ru Wed May 23 16:16:13 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA09432 for ; Wed, 23 May 2001 16:16:10 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.6) with ESMTP id 8684371 for xemacs-beta@xemacs.org; Wed, 23 May 2001 17:16:04 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp136-157.dialup.mtu-net.ru [62.118.136.157]) by mtu.ru (Postfix) with ESMTP id A72897376 for ; Thu, 24 May 2001 00:16:05 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 9993 invoked by uid 1000); 23 May 2001 20:09:33 -0000 From: Alexey Mahotkin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.6397.651561.268146@tyranny.hsys.msk.ru> Date: Thu, 24 May 2001 00:09:33 +0400 (MSD) To: xemacs-beta@xemacs.org Subject: RFC: generic support for single-byte encodings in non-Mule XEmacs X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Salam, [this proposal is a rethought and refined version of the "RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs". Thanks to everyone for their comments, especially to Hrvoje for 'ascii-character, and to Martin for ideas about not bothering with C and the need of "many more thinking", you were right :) ] I will speak of "single-byte encodings", using mostly Cyrillic ones as an example. It seems like 'ascii-character property could be renamed to 'single-byte-equivalent for clarity and formal correctness, if it wasn't for the compatibility (although it could be considered to declare 'ascii-character obsolete and consult it only if 'single-byte-equivalent is not defined. Renamed property should be properly documented, as everything else discussed here, of course). There are three primary things that should be modified when switching single-byte encoding: mapping of X keysyms to single-byte codes; case-tables; syntax-tables. 1. Mapping of keysyms was the primary subject of previous discussion and the best practice seems to be (put 'Keysym 'single-byte-equivalent ?\xXX) All possible keysyms that are subject to this mapping are tracked and bound to nil if they do not have an equivalent in the encoding that is being switched to. E.g., when we are using "latin-1" encoding, we have (global-set-key 'ntilde 'self-insert-command) (put 'ntilde 'single-byte-equivalent ?\xXX) When we're switching to "koi8-r" encoding, we have to (global-unset-key 'ntilde) because it does not have koi8-r equivalent. (Or, otherwise, we could bind it to some `no-single-byte-equivalent' function, that does just (message "last typed character has no CURRENT-ENCODING equivalent") (instead of "ASCII", which is not always true). Sure, if user redefined 'ntilde to something like (insert "\~n"), it will be left alone. 2. case-tables. It's a rather minor and straightforward issue, except that it effectively does not work in 21.1.x. Is the change in 21.4.x that enabled this feature small enough to be somehow backported to 21.1? It'd be good to be able to make a patch that brings it all together to one more release of 21.1. 3. syntax-tables (mostly for "word constituent" syntax class). That's as minor and straightforward issue as the previous one, and without bugs. It just needs to be carefully checked for various major modes that change syntax tables so that they all live together. I propose that generic implementation of all this be put in "single-byte.el", while particular encoding descriptions be put in e.g. "cyrillic.el" and "x-cyrillic.el" (different from "mule/cyrillic.el"), a-la "iso8859-1.el" and "x-iso8859-1.el". Previous implementations: koi8-r-only support for all of this based on results of previous discussion in xemacs-beta is written by "Andrew W. Nosenko" and seems to be successfully used around. There is also a widely used .el-files by Ilya Perminov to support most popular Cyrillic encodings: it also features automatic detection of encoding and recoding of buffers. There are also several more issues, like choosing the correct ispell dictionary, but they probably could be done in hooks or just discussed later. Any comments? I mostly do not see any unresolved issues and plan to start developing in couple more days. --alexm From hniksic@arsdigita.com Wed May 23 16:16:43 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA09466 for ; Wed, 23 May 2001 16:16:42 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152f3X-0006io-00 for ; Wed, 23 May 2001 22:16:31 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <20010523160812.A5127@ool-18b88ad6.dyn.optonline.net> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 23 May 2001 22:16:30 +0200 In-Reply-To: <20010523160812.A5127@ool-18b88ad6.dyn.optonline.net> (QuoteMstr - Danny Colascione's message of "Wed, 23 May 2001 16:08:12 -0400") Message-ID: Lines: 23 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii QuoteMstr - Danny Colascione writes: > I like this. I like it a lot. Just a question --- do you think it > could be done in such a way that code could be loaded from shared > libraries I believe that would be a very natural extension. In fact, now that we have dynamic loading infrastructure, it would be silly not to use it! (This raises issues of having a compiler, optimizer switches, etc., but given the benefits, those issues are minor.) > and, with a (supported) compiler, .el files could be compiled and > loaded on the fly, just as .elc files are now? `.el' files are not compiled and loaded on the fly. You have to compile them manually. I would like to see another "level" of this compilation that turns `.elc' files into `.ell' (by way of .c), which you can proceed to load as usual. Of course, the whole thing, being an optimization, would be entirely optional. From qtmstr@optonline.net Wed May 23 16:27:41 2001 Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA10065 for ; Wed, 23 May 2001 16:27:41 -0400 Received: from ool-18b88ad6.dyn.optonline.net (ool-18b88ad6.dyn.optonline.net [24.184.138.214]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with SMTP id <0GDT0070D261T4@mta6.srv.hcvlny.cv.net> for xemacs-beta@xemacs.org; Wed, 23 May 2001 16:27:37 -0400 (EDT) Received: by ool-18b88ad6.dyn.optonline.net (sSMTP sendmail emulation); Wed, 23 May 2001 16:26:51 -0400 Date: Wed, 23 May 2001 16:26:51 -0400 From: QuoteMstr - Danny Colascione Subject: Re: Preprocessor In-reply-to: <"from hniksic"@arsdigita.com> To: XEmacs Beta List Mail-followup-to: XEmacs Beta List Message-id: <20010523162651.A5286@ool-18b88ad6.dyn.optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.2.5i References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <20010523160812.A5127@ool-18b88ad6.dyn.optonline.net> On Wed, May 23, 2001 at 10:16:30PM +0200, Hrvoje Niksic wrote: > `.el' files are not compiled and loaded on the fly. You have to > compile them manually. I would like to see another "level" of this > compilation that turns `.elc' files into `.ell' (by way of .c), which > you can proceed to load as usual. That's what I meant, yes. That would be great. Can non-special DLLs (special ones are scr, cpl, etc.) have an extension other than .dll on win32, btw? -- "Understanding is a three-edged sword: Your side, their side, and the truth." --- Kosh From CraigL@Knology.net Wed May 23 16:40:58 2001 Received: from smtp2.knology.net (user-24-214-63-14.knology.net [24.214.63.14]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id QAA10724 for ; Wed, 23 May 2001 16:40:58 -0400 Received: (qmail 5105 invoked from network); 23 May 2001 20:40:54 -0000 Received: from user-24-214-46-158.knology.net (HELO craigl.lanning.net.knology.net) (24.214.46.158) by user-24-214-63-14.knology.net with SMTP; 23 May 2001 20:40:54 -0000 From: Craig Lanning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.8055.102676.553191@craigl.lanning.net> Date: Wed, 23 May 2001 16:37:11 -0400 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid Hrvoje Niksic writes: > Raymond Toy writes: > > > Then why not use gcl then? > > Because it's highly questionable how useful Gcl is. > > To be useful in short-term future, an elisp-to-C translator should not > try to reimplement XEmacs from scratch or to turn Elisp into Common > Lisp (or, for that matter, CLtL1). > > My favorite strategy for elisp-to-C is the one (I think) originally > proposed by Kyle Jones some time ago: look at the opcodes that our > current compiler generates. Now look at the code in bytecode.c that > interprets it. A simple translator would simply take byte-compiled > code and translate it into C that looks like bytecode.c, but inlined > to directly *do* the stuff that P-code wants to do instead of > interpreting the P-code. CLiCC was designed to do something like this. The web site references a PostScript file that describes their method better than I am about to attempt. CLiCC actually compiles the Lisp to a set of specialized C macros which are then compiled by a normal C compiler. Perhaps CLiCC could be adapted to use the (X)Emacs bytecode C code. One major advantage of CLiCC is that it is designed to do global optimization for the entire application. This is something that C compilers rarely (if ever) do. > Although this looks simple-minded, I believe it would be a *huge* > speed win over the current virtual machine. First, the cost of > interpretation would be removed, which is by itself a big win -- > the huge `case' statement would finally be eliminated. Secondly, such > "unwound" C code would be processed by the C optimizer which would > remove the many many redundant checks and thus make the code run > really fast. I have found that simple is usually best. Craig > The advantage of this strategy is that it opts for huge speedup in a > *realistic* environment, i.e. it doesn't require rebuilding 100% of > XEmacs to work. Furthermore, it builds on the work already invested > in the byte-code compiler. > > From hniksic@arsdigita.com Wed May 23 16:41:56 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA10783 for ; Wed, 23 May 2001 16:41:55 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152fS6-0006o7-00 for ; Wed, 23 May 2001 22:41:54 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 23 May 2001 22:41:54 +0200 In-Reply-To: <15116.6397.651561.268146@tyranny.hsys.msk.ru> (Alexey Mahotkin's message of "Thu, 24 May 2001 00:09:33 +0400 (MSD)") Message-ID: Lines: 44 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > It seems like 'ascii-character property could be renamed to > 'single-byte-equivalent for clarity and formal correctness, That cannot by right because the value of that property is a character, not a byte. For instance, under Mule, it works perfectly for Japanese characters. The name `ascii-character' sucks for the same reason -- it's not necessarily ASCII. Historically it was ASCII, and that property was used to communicate that TAB should insert ?\t, etc. > 1. Mapping of keysyms was the primary subject of previous discussion > and the best practice seems to be [...] I take it that you would like to automatize these mappings according to a new concept of "single-byte encodings", present in the absence of Mule? The one thing that bugs me about this is that it's introducing yet another abstraction ("single-byte"), and one which has no equivalent in Mule whatsoever. That's IMHO a very bad thing, which will undoubtedly lead to maintenance and documentation problems. ("I compiled XEmacs with Mule, and my single-byte stuff no longer works!") Now that Mule has been hacked into something close to usability, I must admit I doubt that what you propose it worth the maintenance pain. Can you remind me why exactly Mule fails to work for you? Also, all of this sounds like an idea for a first-class external package. Write it and distribute it to all your friends. If it becomes immensely popular and all of Russia starts using it, we'll include it too. It's as simple as that. > 2. case-tables. It's a rather minor and straightforward issue, except > that it effectively does not work in 21.1.x. Is the change in 21.4.x > that enabled this feature small enough to be somehow backported to > 21.1? It's not, and even if it were, such a patch would be totally inappropriate for 21.1. If you want the new features, switch to 21.4. That's why it's there! From hniksic@arsdigita.com Wed May 23 16:43:56 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA10882 for ; Wed, 23 May 2001 16:43:54 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152fU1-0006oi-00 for ; Wed, 23 May 2001 22:43:53 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <20010523160812.A5127@ool-18b88ad6.dyn.optonline.net> <20010523162651.A5286@ool-18b88ad6.dyn.optonline.net> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 23 May 2001 22:43:52 +0200 In-Reply-To: <20010523162651.A5286@ool-18b88ad6.dyn.optonline.net> (QuoteMstr - Danny Colascione's message of "Wed, 23 May 2001 16:26:51 -0400") Message-ID: Lines: 8 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii QuoteMstr - Danny Colascione writes: > Can non-special DLLs (special ones are scr, cpl, etc.) have an > extension other than .dll on win32, btw? You'll have to ask the Windows people. I believe that our DLL architecture was designed, among other things, with Windows in mind, so the answer is probably "yes". From alexm@hsys.msk.ru Wed May 23 16:47:11 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA11057 for ; Wed, 23 May 2001 16:47:10 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.6) with ESMTP id 8687328 for xemacs-beta@xemacs.org; Wed, 23 May 2001 17:46:55 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp138-163.dialup.mtu-net.ru [62.118.138.163]) by mtu.ru (Postfix) with ESMTP id 93DDE7342 for ; Thu, 24 May 2001 00:46:56 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 10213 invoked by uid 1000); 23 May 2001 20:31:36 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: "Stephen J. Turnbull" To: "Stephen J. Turnbull" Cc: xemacs-beta@xemacs.org Subject: Re: Non-english discussion channels References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15096.49407.763993.21009@turnbull.sk.tsukuba.ac.jp> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 24 May 2001 00:31:35 +0400 In-Reply-To: "Stephen J. Turnbull"'s message of "Wed, 9 May 2001 13:01:03 +0900" Message-ID: <873d9vq02g.fsf@tyranny.hsys.msk.ru> Lines: 33 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "SJT" == Stephen J Turnbull writes: SJT> BTW, Alexey, the xemacs-mule@xemacs.org list is chartered to be SJT> multi-lingual. If for some reason it would be convenient, you and SJT> others are welcome to hold development-related discussions in Russian SJT> on that list. They need not be restricted specifically to Mule; any SJT> topic related to using XEmacs for non-English languages is welcome. SJT> I and other developers do monitor that list. I don't read Russian, SJT> but if a Russian thread should suddenly break into English, I would SJT> certainly consider that a request for my attention. This model has SJT> worked fairly well for Japanese There is already a de-facto forum for XEmacs discussions in Russian (fido7.ru.gnu newsgroup). And I for the recent time try to serve as a mediator between it and xemacs-beta :) SJT> (until now, the main non-Latin-X constituency for XEmacs). Yes, there is an idea around that if that wasn't for the Japanese, various locale issues were just not so well supported as they are now. Russian seems so easy in comparison with Japanese :) SJT> We could also create an xemacs-users-ru list to parallel c.e.x and SJT> xemacs-beta, but specifically chartered for Russian discussion. SJT> Again, this has worked for Japanese (although traffic has gone to zero SJT> on xemacs-users-ja recently). I hope that xemacs-ru mailing list will be created soon by friendly sysadmins. Most worthy questions from there will be brought to your attention, don't worry :) --alexm From alexm@hsys.msk.ru Wed May 23 16:47:16 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA11062 for ; Wed, 23 May 2001 16:47:12 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.6) with ESMTP id 8687331 for xemacs-beta@xemacs.org; Wed, 23 May 2001 17:46:58 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp138-163.dialup.mtu-net.ru [62.118.138.163]) by mtu.ru (Postfix) with ESMTP id E12D973A9 for ; Thu, 24 May 2001 00:46:57 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 10223 invoked by uid 1000); 23 May 2001 20:45:58 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Didier Verna To: xemacs-beta@xemacs.org Cc: morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 24 May 2001 00:45:58 +0400 In-Reply-To: Didier Verna's message of "14 May 2001 11:03:06 +0200" Message-ID: <87zoc3oku1.fsf@tyranny.hsys.msk.ru> Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "drv" == Didier Verna writes: >> Suppose there is a (desktop-read) in init.el, and >> >> (custom-set-variables '(user-mail-address "morozov@novosoft.ru")), >> >> in custom.el. Now if desktop being read contains .html file then >> html-mode asks again and again: "Your mail address: alex@localhost" or >> something like that, because it is not yet customized. >> >> Surely one can move (setq user-mail-address "") to init.el, before >> (desktop-read), but there must be a more generic way to address that >> issue, what do you think? drv> You can try to swap the order of custom / init files drv> reading. That's what I do at the top of my init file: Ok, the thread seems to be petered out, but the conclusion and some action probably has to be made. I have seen real reasons to swap the order and at the same time there were mostly no reasons to not to swap the order (and those that were are easily worked around). Am I right? Could we all hope that it'll be fixed by swapping the loading order in 21.4.next and 21.5? Stephen, please notify current Cc: list when you'll do that :) --alexm From nix@esperi.demon.co.uk Wed May 23 17:00:34 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA11847; Wed, 23 May 2001 17:00:24 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id VAA16283; Wed, 23 May 2001 21:52:59 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id VAA00691; Wed, 23 May 2001 21:52:59 +0100 Sender: nix@esperi.demon.co.uk To: Martin Buchholz Cc: Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> X-Emacs: it's not slow --- it's stately. From: Nix Date: 23 May 2001 21:52:50 +0100 In-Reply-To: <15114.13741.708870.454969@gargle.gargle.HOWL> Message-ID: <87zoc3hjod.fsf@loki.wkstn.nix> Lines: 213 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii [Sorry for the delay; a cold. I didn't feel I could respond to this until I was capable of thinking again...] On Tue, 22 May 2001, Martin Buchholz said: > The alloc routines know what they're allocating, but they don't know > about the references to the memory being allocated. Unless you do > something very radical, you have to gcpro the address of the > Lisp_Object on the stack that is about to receive the pointer to the > allocated memory. This means that Fcons can't gcpro anything. Gaah. You're right, of course. (Stupid of me.) > Perhaps I'm missing something. No, of course not; but this doesn't add much complexity to what I'm planning --- which probably indicates that it's hugely overcomplicated already :) > The standard tricky thing about implementing a preprocessor that adds > gcpros automatically is that sometimes the Lisp_Objects that have to > be protected aren't even declared - they're temporaries. Absolutely. > For example > > return Fcons_user1 (Fcons_user2 (Fcons (Qnil, Qnil))); > > This has to be expanded into > > { > Lisp_Object x = Qnil, y = Qnil, z = Qnil; > struct gcpro gcpro1, gcpro2, gcpro3; > GCPRO3 (x, y, z); > x = Fcons (Qnil, Qnil); > y = Fcons_user2 (x); > z = Fcons_user3 (y); > UNGCPRO; > return z; > } This was almost exactly the transformation I was expecting to have to apply, although I intend that the GCPRO and UNGCPRO macros don't survive in their current form with this preprocessor; the limits on the numbers of objects that can be GCPROed in one block *will* go away, for instance; it irks me. (Of course their replacements will do the same thing, and will probably be the same code, just emitted already expanded.) > (this example could of course be optimized - but this is the obvious translation) ... and probably the one I'd apply. > (this example also shows how incredibly ugly gcpros are) A good reason to automate away their creation then, so no humans have to look at them :) > The current source code does a lot fewer GCPROs than the above, > because of detailed knowledge of various functions (can they gc, or This is a very bad idea, I think. It means that much of the XEmacs source code has detailed knowledge of the internal implementation details of other parts of the source code; this reduces stability ('cos some *will* be missed) and drastically increases the difficulty of changing anything. I think this should be handled in a similar way to the way GCC works out what registers are going to be used in subfunctions; assume they'll all be clobbered. The expenditure of time is minimal, in any case. (If the time wastage gets extreme in some hot spots, we can optimize the hot spots; but in general I think that every stack slot that holds a Lisp_Object should be protected. XEmacs isn't GCPRO-bound, it's GC-bound ;) ) > could they return a fresh object). It is possible to determine this > kind of information from a global analysis of the source code, but it I'm not even going to *try* to do that. It's probably impossible in the general case, anyway (I'd need to think about it, but I'd be surprised if that kind of detail of global analysis didn't reduce to the halting problem.) > won't be easy. In particular, the C preprocessor will tend to make > the source more resistant to automated understanding by your gcpro > preprocessor. E.g. I'm going to stitch this in after the preprocessor has run on a given source file. (I'd have to preprocess it anyway, so it seems sensible to only preprocess it once!) Oh, FWIW the preprocessor should be able to handle just about anything, 'cos I'm cheating. I'm taking c-parse.y and cpplex.c from GCC, and tearing them down into something that can unambiguously spot C blocks (`stmts_and_decls'), assignments (`expr_no_commas'), Lisp_Object variable declarations (`decl' nodes), and temporaries. Everything else that I can throw away I will; we don't need a complete C parser, let alone the Objective C parts (sorry, Ovidiu ;) ). In one respect it'll be more complicated than GCC's parser; it needs to maintain knowledge of where in the pre-lexed sources a given lexical component comes from, so we can rewrite the temporaries; but it shouldn't be terribly hard. (I think GCC also contains some temporary-rewriting stuff I can pinch from; building a temporary is an RTL-level equivalent of what this preprocessor would have to do on the source code level. Fun. (But if this were C++ it would not be fun, it would be torment...) > Sorry, I meant there's little scope for a Boehm mark() to be better > than the existing mark() because the existing one, via lisp object > type mark methods, already knows exactly which object components might > contain other Lisp_Objects. The mark bitmap won't help you much > during the mark phase, in fact it ought to make things worse. Hmm. Why is that? The current garbage collector has appalling VM behaviour; every Lisp_Object is sucked back into memory, even if they cannot contain other Lisp_Objects. If a mark bitmap is used, a Lisp_Object will only be accessed for pointer tracing; if it cannot contain another Lisp_Object, it won't be touched. I'll admit that I haven't instrumented the existing gc to find out what percentage of objects are accessed only to set the mark bit; I'll do so as soon as this cold has worn off. (I'll feel a right idiot if the answer is something like 1%, too...) > The place where the Boehm gc shines performance wise is not during gc > at all, but in the fact that gcpros can be dispensed with entirely > while the mutator runs. Normally the advantage of mark&sweep over > reference counting is: not slowing down the mutator. But gcproing does > slow down the mutator. But I really don't know how much overhead we > have from GCPROing, and it's hard to measure. My random guess is that > 10% of the runtime of lisp function calls that do no work (i.e. return > immediately) is taken up with gcproing. However, a (not huge) general slowdown like that is hard for humans to spot. What humans definitely *do* spot (well, I know I've spotted it, and so have friends of mine, new XEmacs hands and old) is the total stoppage we get whenever GCing runs and the world freezes except for the hammering of the disk :( if XEmacs is totally in swap, it can be frozen for a minute or more while GC runs. GCPROs suck, but the only ways we can eliminate them are conservative collection (not very portable and can leave cruft around, as you said), some really hefty global analysis (I'll leave that for a braver soul), or a compiler that knows how to emit typing information (and while we could probably get an option added to GCC that would emit such information, I don't think we can decree that XEmacs can only be built by GCC-3.1 and above...) Given Moore's Law and the fact that machines with small amounts of memory are getting steadily harder to find and steadily harder to run late versions of XEmacs on (and probably don't see many upgrades anyway), I am happy to *increase* the number of GCPROs substantially, to ensure that we can freely modify arbitrary functions without triggering GC hell. After all, GCPROs are really quite efficiently implemented; it's not as if they call malloc() or something like that. (As a *structure*, the gcprolist is praiseworthy. It's just the manual way it's kept updated that's disgusting and restrictive.) > Nix> -- and, if I can get it to work --- and I damned well will ;) --- a > Nix> GCPROizing preprocessor, so we can dump *visible* evidence of GCPRO > Nix> (that being what does the harm; we can forget it exists completely > Nix> if it is automatically maintained!) > > Harder than it looks, as I try to point out above. I'll be very > impressed if you can produce a reliable GCPROizing preprocessor. We have the advantage of a pre-existing free software project that is quite capable of understanding C code (GCC), and which does far more elaborate transformations than this preprocessor will have to; and I'm happy to nick code from it. (I'll probably mention such large-scale borrowing on the GCC list if I do it, if Ovidiu doesn't beat me to it...) The GCC C parser is actually quite neat, as such things go... > I think you'll have to run the source through the C preprocessor > first, which means your gcproizer has to run every build. Using the Yes. > standard Unix utilities, this will be hard (i.e. you'll want to use > something like perl or python). Most free software projects don't Not a chance; this'll be in C. Parsing is what yacc is good for, and as usual we'd ship the results of running yacc on the preprocessor's .y files, so the builders won't need yacc. (Plus, GCC is already written in C, and while I'm willing to attack c-parse.y and cpplex with a stone axe to form the core of this preprocessor, I'm really not willing to translate them into Perl; I have more taste than that ;) ) > have such dependencies for non-maintainer-mode, but I think the time > might be right to introduce such a dependency for xemacs. No need. (I wouldn't want that dependency for purely personal reasons; one of the sites I run xemacs on has no perl or python, and I can't install either because I just barely have the space for xemacs. I know where *my* priorities lie ;) ) > ObAdvice: Have you read the internals manual section that deals with gc? Yes, of course, long before I mentioned this plan here, when I harboured the secret desire that the fix to XEmacs's GC performance would be simple. (Then I read of GCPRO and felt quite ill...) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From toy@rtp.ericsson.se Wed May 23 17:29:17 2001 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA13276 for ; Wed, 23 May 2001 17:29:12 -0400 Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f4NLT1a11047 for ; Wed, 23 May 2001 16:29:11 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4NLT0p19571 for ; Wed, 23 May 2001 16:29:00 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Wed May 23 16:28:59 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id RAA08158; Wed, 23 May 2001 17:29:09 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id RAA02751; Wed, 23 May 2001 17:28:58 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: Craig Lanning Cc: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <15116.2076.279253.644791@craigl.lanning.net> <4nlmnnzxy1.fsf@rtp.ericsson.se> <15116.4480.267088.189134@craigl.lanning.net> From: Raymond Toy Date: 23 May 2001 17:28:58 -0400 In-Reply-To: <15116.4480.267088.189134@craigl.lanning.net> Message-ID: <4nheybzrdx.fsf@rtp.ericsson.se> Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Craig" == Craig Lanning writes: Craig> Raymond Toy writes: >> >>>>> "Craig" == Craig Lanning writes: >> Craig> The last time I tried gcl it claimed CLtL1 compatibility which doesn't Craig> include CLOS. Has it moved closer to ANSI Common Lisp? I already >> >> I don't follow gcl but I don't think it's any closer. Craig> Then I would have a difficult time calling it "actively maintained". Well, Clisp claims CLtL2 and ANSI compatibility but I think there are some things that are specified by ANSI that will never be done because they think it's wrong. So is clisp not actively maintained? Even though there have been 2 releases in the last couple of months? >> It's certainly still missing lots of ANSI stuff like >> defpackage, loop, etc. CLOS is still implemented with PCL (but >> then CMUCL uses PCL too). However as a backend for xemacs it's >> probably doesn't matter since xemacs code probably wouldn't use >> any of missing ANSI things. :-) Craig> If those things were available in the development environment then Craig> XEmacs might use them :-) Craig> Modes are much easier to implement with an object system. Craig> Zmacs implements each mode (both major and minor) as Craig> flavors (Zetalisp object system). It makes it easier to Craig> inherit things that are common to all modes. But if modes are required to use the object system who's going to port over all the old code? Not me. Craig> Packages would be helpful in segregating the different lisp packages. People already do this by prefixing stuff. Having packages won't change existing code. That's why CLtL1 isn't so bad. There's so much old stuff that no one really wants to port it all over, and no one wants to maintain a version for XEmacs and Emacs. I think that's hard enough already. Besides, Hvroje's message about Kyle's approach is the right solution to me. No user-visible changes to the lisp code, but potentially major changes in speed. (That's why I stopped using VM. Too slow to load up my 100 MB mail files. If VM becomes fast, I might switch back.) Ray From Adrian.Aichner@t-online.de Wed May 23 17:34:00 2001 Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA13477 for ; Wed, 23 May 2001 17:33:59 -0400 Received: from fwd06.sul.t-online.de by mailout03.sul.t-online.de with smtp id 152gGT-0001yR-07; Wed, 23 May 2001 23:33:57 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.95]) by fwd06.sul.t-online.com with esmtp id 152gH4-15PjOKC; Wed, 23 May 2001 23:34:34 +0200 To: "Stephen J. Turnbull" Cc: Hrvoje Niksic , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 93 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Stephen" == Stephen J Turnbull writes: Thanks for the recap, Stephen. Whatever we come up with should ideally be short enough for a headline. See https://sourceforge.net/projects/xemacs/ I have also changed the homepage link on SF from http://xemacs.sourceforge.net/ to http://www.us.xemacs.org/ to provide more of a corporate (or should I say orgic) identity. That's non-controversial, I hope. I agree that we should convey that XEmacs is more than an Editor. We probably don't need to stress the Open Source part on the SourceForge site. How about the following? The XEmacs Multi-OS Editing & Development Environment Should we take a vote on these? Here they are: The XEmacs Multi-OS Editing & Development Environment XEmacs - Open Source, Multi-platform, Multi-Language, and _More_ Than Just an Editor XEmacs - Open Source, Multi-platform, Multi-Language, and a Way Of Life XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor XEmacs - The Multi-Platform Open Source Editor. XEmacs - the Multi-Platform Open Source Editor and Environment XEmacs - the Multi-Platform Platform XEmacs Multi-Platform Open Source Editor XEmacs, an Open Source Editor for MS Windows and Unix Adrian >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> [ Why is this discussion not on xemacs-beta? ] Stephen> It is now. Recap: Adrian suggests fixing up our "Descriptive Group Stephen> Name" on SourceForge, in particular, to Stephen> XEmacs Multi-Platform Open Source Editor Stephen> Ben Wing proposes an amendment: Ben> why not just be specific about what we support? Stephen> XEmacs, an Open Source Editor for MS Windows and Unix Stephen> Steve Youngs writes: >>> Adrian, I like your change, but I think it's a little bashful. >>> How about: >>> XEmacs - The Multi-Platform Open Source Editor. >>> See the subtle difference? Stephen> Yeah. I bet RMS will too. Don't be so competitive. ;-) Hrvoje> How about: Stephen> XEmacs - the Multi-Platform Open Source Editor and Environment Stephen> My two cents: Stephen> XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor Stephen> I'm really tempted by "More than just another pretty Emacs", but I've Stephen> already gotten enough grief about my .sig. ;-) Stephen> The floor is open... Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From hniksic@arsdigita.com Wed May 23 17:40:52 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA13756 for ; Wed, 23 May 2001 17:40:49 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152gMu-00070s-00; Wed, 23 May 2001 23:40:36 +0200 Sender: hniksic@florida.arsdigita.de To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: "Stephen J. Turnbull" , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 23 May 2001 23:40:36 +0200 In-Reply-To: (Adrian.Aichner@t-online.de's message of "23 May 2001 23:33:49 +0200") Message-ID: Lines: 11 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian.Aichner@t-online.de (Adrian Aichner) writes: > The XEmacs Multi-OS Editing & Development Environment It's OK, except for the fact that XEmacs allows more than "editing & development". The application I most use is a news/mail-reader! > Should we take a vote on these? Maybe we should take the silly ones out of the competition. I guess it depends on what kind of impression we want to make... From jhar@tardis.ed.ac.uk Wed May 23 17:40:58 2001 Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA13755 for ; Wed, 23 May 2001 17:40:48 -0400 Received: from marginal.demonadsltrial.co.uk ([193.195.64.136] helo=tardis.ed.ac.uk) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 152gMv-0005OD-0U; Wed, 23 May 2001 22:40:37 +0100 Message-ID: <3B0C2E55.510FC075@tardis.ed.ac.uk> Date: Wed, 23 May 2001 22:40:37 +0100 From: Jonathan Harris X-No-Archive: Yes X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <20010523160812.A5127@ool-18b88ad6.dyn.optonline.net> <20010523162651.A5286@ool-18b88ad6.dyn.optonline.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hrvoje Niksic wrote: > > QuoteMstr - Danny Colascione writes: > > > Can non-special DLLs (special ones are scr, cpl, etc.) have an > > extension other than .dll on win32, btw? > > You'll have to ask the Windows people. I believe that our DLL > architecture was designed, among other things, with Windows in mind, > so the answer is probably "yes". Yes. Jonathan. -- Jonathan Harris | jhar@tardis.ed.ac.uk London, England | Jonathan.Harris@symbian.com From mta@arbortext.com Wed May 23 17:59:07 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA14622; Wed, 23 May 2001 17:59:06 -0400 Date: Wed, 23 May 2001 17:59:12 -0400 From: Mike Alexander To: Nix , Martin Buchholz cc: Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack Message-ID: <2798274265.990640752@[172.27.6.51]> In-Reply-To: <87zoc3hjod.fsf@loki.wkstn.nix> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit --On Wednesday, May 23, 2001 9:52 PM +0100 Nix wrote: > I'm going to stitch this in after the preprocessor has run on a given > source file. (I'd have to preprocess it anyway, so it seems sensible > to only preprocess it once!) > > Oh, FWIW the preprocessor should be able to handle just about > anything, 'cos I'm cheating. I'm taking c-parse.y and cpplex.c from > GCC, and tearing them down into something that can unambiguously spot > C blocks (`stmts_and_decls'), assignments (`expr_no_commas'), > Lisp_Object variable declarations (`decl' nodes), and temporaries. > Everything else that I can throw away I will; we don't need a > complete C parser, let alone the Objective C parts (sorry, Ovidiu ;) > ). > > In one respect it'll be more complicated than GCC's parser; it needs > to maintain knowledge of where in the pre-lexed sources a given > lexical component comes from, so we can rewrite the temporaries; but > it shouldn't be terribly hard. (I think GCC also contains some > temporary-rewriting stuff I can pinch from; building a temporary is an > RTL-level equivalent of what this preprocessor would have to do on the > source code level. > > Fun. (But if this were C++ it would not be fun, it would be > torment...) > Yes, I can imagine it would be. I would certainly hate to do anything that would heavily penalize the use of C++ in XEmacs or worse yet, make it impossible. Also don't forget about the native Windows build using MSVC while thinking about this. Nothing you've said so far jumps out as being impossible, but that's a rather different environment with a different C compiler and preprocessor to worry about. Mike Alexander mailto:mta@arbortext.com Arbortext, Inc. +1-734-997-0200 From nix@esperi.demon.co.uk Wed May 23 18:00:26 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA14716 for ; Wed, 23 May 2001 18:00:23 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id WAA16527; Wed, 23 May 2001 22:54:59 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id WAA00842; Wed, 23 May 2001 22:54:58 +0100 Sender: nix@esperi.demon.co.uk To: Robert Pluim Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <15114.6040.683679.924905@europe.nortel.com> X-Emacs: because you deserve a brk today. From: Nix Date: 23 May 2001 22:54:50 +0100 In-Reply-To: <15114.6040.683679.924905@europe.nortel.com> Message-ID: <87eltfhgt1.fsf@loki.wkstn.nix> Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Tue, 22 May 2001, Robert Pluim spake: > Michael Sperber writes: > > - Robert Pluim at one time did hook up the Boehm > > collector to XEmacs in 1999 with rather disappointing results. > > That's a mild way of putting it. My notes from that attempt say > "Leaks like a piece of string" ;-) The investigation I did seemed to > indicate that the incidence of false positives on the stack was rather > high Was ALL_INTERIOR_POINTERS turned off? (If it wasn't, I'd expect to see lots of leakage). > > - I rather doubt that Richard will have enough time to integrate the > > changes of the NewGC branch into the trunk. This would be a very > > worthwhile goal for anyone working on the GC, no matter which one. > > Cool. I might tinker with this again if I have time. Too late :) the integration doesn't seem to be very difficult (not *that* much of XEmacs has changed in the interim); before the cold struck I was about 30% of the way through it. I expect to finish it off this weekend. -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From nix@esperi.demon.co.uk Wed May 23 18:30:19 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA16151; Wed, 23 May 2001 18:30:15 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id XAA16667; Wed, 23 May 2001 23:24:31 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id XAA00935; Wed, 23 May 2001 23:24:29 +0100 Sender: nix@esperi.demon.co.uk To: Mike Alexander Cc: Martin Buchholz , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <2798274265.990640752@[172.27.6.51]> X-Emacs: ed :: 20-megaton hydrogen bomb : firecracker From: Nix Date: 23 May 2001 23:24:19 +0100 In-Reply-To: <2798274265.990640752@[172.27.6.51]> Message-ID: <878zjnhffw.fsf@loki.wkstn.nix> Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Wed, 23 May 2001, Mike Alexander stipulated: > --On Wednesday, May 23, 2001 9:52 PM +0100 Nix wrote: >> Fun. (But if this were C++ it would not be fun, it would be >> torment...) >> > > Yes, I can imagine it would be. I would certainly hate to do anything > that would heavily penalize the use of C++ in XEmacs or worse yet, > make it impossible. The CodeSourcery folks are rewriting the C++ parser into something that's actually maintainable; when that's done I could produce a C++ variant of the preprocessor (let's give it a name: gcpp. The C++ variant would presumably be gcpppp...) > Also don't forget about the native Windows build using MSVC while > thinking about this. Nothing you've said so far jumps out as being > impossible, but that's a rather different environment with a different > C compiler and preprocessor to worry about. That's irrelevant; this preprocessor's not trying to compile the code, just to pick out declarations and function calls and do a little simple rewriting. As long as the C used in the MSVC build (and headers) isn't gratutiously nonstandard, the parser should be happy. (And if it isn't I can rejig it until it is; MS's changes to C can't be *that* bad, can they? Unless they've broken block structure or declarations...) (Aside: I'm getting a little worried by the length of this cc list...) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD From rendhalver@users.sourceforge.net Wed May 23 18:30:23 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA16158 for ; Wed, 23 May 2001 18:30:21 -0400 Received: from ulthwe.dyndns.org (p25-tnt1.brs.ihug.com.au [203.173.188.25]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id IAA16712; Thu, 24 May 2001 08:30:04 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p25-tnt1.brs.ihug.com.au [203.173.188.25] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15116.14683.528468.483722@ulthwe.dyndns.org> Date: Thu, 24 May 2001 08:27:39 +1000 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: "Stephen J. Turnbull" , Hrvoje Niksic , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge In-Reply-To: References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Adrian Aichner writes: > >>>>> "Stephen" == Stephen J Turnbull writes: im going away for a few days so i will cast my vote now its so hard to decide but i agree with adrian about not needing Open Source on sourceforge > The XEmacs Multi-OS Editing & Development Environment > XEmacs - Open Source, Multi-platform, Multi-Language, and _More_ Than Just an Editor > XEmacs - Open Source, Multi-platform, Multi-Language, and a Way Of Life > XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor > XEmacs - The Multi-Platform Open Source Editor. > XEmacs - the Multi-Platform Open Source Editor and Environment > XEmacs - the Multi-Platform Platform > XEmacs Multi-Platform Open Source Editor > XEmacs, an Open Source Editor for MS Windows and Unix and i do like the Multi-Language bit (not just cause i suggested it) um maybe we could nail something together from the good bits of each so maybe XEmacs - Multi-platform, Multi-Language, Environment um what *does* the X stand for anyway eXtensible ?? -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From steve@turnbull.sk.tsukuba.ac.jp Wed May 23 21:12:08 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA23804 for ; Wed, 23 May 2001 21:12:07 -0400 Received: by localhost id m152jfI-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 24 May 2001 10:11:48 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.24511.396415.259544@turnbull.sk.tsukuba.ac.jp> Date: Thu, 24 May 2001 10:11:27 +0900 To: Alexey Mahotkin Cc: xemacs-beta@xemacs.org, morozov@novosoft.ru Subject: Re: order of ~/.xemacs/init.el and ~/.xemacs/custom.el In-Reply-To: <87zoc3oku1.fsf@tyranny.hsys.msk.ru> References: <15102.36143.240455.718548@tyranny.hsys.msk.ru> <87zoc3oku1.fsf@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Alexey" == Alexey Mahotkin writes: Alexey> I have seen real reasons to swap the order and at the same Alexey> time there were mostly no reasons to not to swap the order Alexey> (and those that were are easily worked around). Am I Alexey> right? This is theory, which I believe to be correct. However, untested. Alexey> Could we all hope that it'll be fixed by swapping the Alexey> loading order in 21.4.next and 21.5? Stephen, please Alexey> notify current Cc: list when you'll do that :) As usual, my policy for 21.4 is to wait for 21.5 to try it, and listen for the lack of screams of outrage. I'm about ready to apply Didier's patches to make the "rename custom.el" hack work correctly. But that should be transparent to current users who don't use it. I would very much like to see a patch to 21.5 to reverse the default order, but it has a lot more potential to surprise users. Eg, it will definitely _surprise_, albeit pleasantly, those who have gotten used to the ugliness of first frame in default 'default face, later frames in customized 'default face. There may be unpleasant surprises of that type lurking as well. Stability first for 21.4. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From martin@m17n.org Wed May 23 21:44:51 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA26243 for ; Wed, 23 May 2001 21:44:46 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4O1ivp11581; Thu, 24 May 2001 10:44:58 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id KAA12501; Thu, 24 May 2001 10:44:36 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4O1iYc23993; Thu, 24 May 2001 10:44:34 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.26498.781814.315964@gargle.gargle.HOWL> Date: Thu, 24 May 2001 10:44:34 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: mac@verisity.com Cc: Hrvoje Niksic , XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: <15115.54751.503841.217389@mac.verisity.com> References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.54751.503841.217389@mac.verisity.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "M" == Michael McNamara writes: M> A better way to change the world might be to write elisp skeleton M> macros (using skeleton.el) that makes it real easy to insert C M> procedure definitions frameworks with all the interface stuff for M> elisp calling there already. In the past, I used such tools, but because so much of software maintenance involves reading and fixing, not writing code, the added convenience of automated code insertion is minimal, unless you have hand problems and you want to make every keystroke count. Magic always has a price. The electricity of { and } are enough for me. Here's my favorite code maintenance tool: (defun kill-whole-line (count) "Kill an entire line, or ARG lines if prefix specified" (interactive "*p") (beginning-of-line) (kill-line count)) From martin@m17n.org Wed May 23 22:03:36 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA27650 for ; Wed, 23 May 2001 22:03:30 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4O21Ep11683; Thu, 24 May 2001 11:01:14 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id LAA12602; Thu, 24 May 2001 11:00:53 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4O20rG24064; Thu, 24 May 2001 11:00:53 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.27476.989838.639409@gargle.gargle.HOWL> Date: Thu, 24 May 2001 11:00:52 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Preprocessor In-Reply-To: References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> My favorite strategy for elisp-to-C is the one (I think) originally Hrvoje> proposed by Kyle Jones some time ago: look at the opcodes that our Hrvoje> current compiler generates. Now look at the code in bytecode.c that Hrvoje> interprets it. A simple translator would simply take byte-compiled Hrvoje> code and translate it into C that looks like bytecode.c, but inlined Hrvoje> to directly *do* the stuff that P-code wants to do instead of Hrvoje> interpreting the P-code. Hrvoje> Although this looks simple-minded, I believe it would be a *huge* Hrvoje> speed win over the current virtual machine. First, the cost of Hrvoje> interpretation would be removed, which is by itself a big win -- Hrvoje> the huge `case' statement would finally be eliminated. Secondly, such Hrvoje> "unwound" C code would be processed by the C optimizer which would Hrvoje> remove the many many redundant checks and thus make the code run Hrvoje> really fast. Hrvoje> The advantage of this strategy is that it opts for huge speedup in a Hrvoje> *realistic* environment, i.e. it doesn't require rebuilding 100% of Hrvoje> XEmacs to work. Furthermore, it builds on the work already invested Hrvoje> in the byte-code compiler. I've done some thinking about this in the past. This is a very EASY translator to write compared to some of the other projects being considered. The hard part is integrating this into xemacs. Like figuring out the shared object loading mechanism across platforms. Should all the package lisp be compiled to .so at installation time, or should there be a JIT that optimizes hotspots at run-time (it would have to call the compiler transparently to do so, however). Don't expect it to be a huge win, however. All the optimized machine code will take up more memory than the bytecodes. And many elisp operations like (setq i (1+ i)) will not be compilable to C i++, but instead will still require expensive frobbing of the lisp symbol `i'. A function call like (foo) will still require the notoriously slow Ffuncall, even if foo is a subr, due to the dynamic nature of lisp. But this is a great hack. From martin@m17n.org Wed May 23 22:18:23 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA28845 for ; Wed, 23 May 2001 22:18:14 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4O2Hop11790; Thu, 24 May 2001 11:17:51 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id LAA12692; Thu, 24 May 2001 11:17:29 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4O2HTu24155; Thu, 24 May 2001 11:17:29 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.28473.282824.897930@gargle.gargle.HOWL> Date: Thu, 24 May 2001 11:17:29 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Alexey Mahotkin Cc: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs In-Reply-To: References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Alexey Mahotkin writes: >> It seems like 'ascii-character property could be renamed to >> 'single-byte-equivalent for clarity and formal correctness, Hrvoje> That cannot by right because the value of that property is a Hrvoje> character, not a byte. For instance, under Mule, it works perfectly Hrvoje> for Japanese characters. Hrvoje> The name `ascii-character' sucks for the same reason -- it's not Hrvoje> necessarily ASCII. Historically it was ASCII, and that property was Hrvoje> used to communicate that TAB should insert ?\t, etc. Agreed. Hrvoje> The one thing that bugs me about this is that it's introducing yet Hrvoje> another abstraction ("single-byte"), and one which has no equivalent Hrvoje> in Mule whatsoever. That's IMHO a very bad thing, which will Hrvoje> undoubtedly lead to maintenance and documentation problems. ("I Hrvoje> compiled XEmacs with Mule, and my single-byte stuff no longer works!") Agreed. Hrvoje> Now that Mule has been hacked into something close to usability, I Hrvoje> must admit I doubt that what you propose it worth the maintenance Hrvoje> pain. Can you remind me why exactly Mule fails to work for you? Agreeed. Hrvoje> Also, all of this sounds like an idea for a first-class external Hrvoje> package. Write it and distribute it to all your friends. If it Hrvoje> becomes immensely popular and all of Russia starts using it, we'll Hrvoje> include it too. It's as simple as that. Alexey: In any case, it is not obvious exactly what the user will want. Perhaps users will want to use koi8 in one buffer, alternativnij in another. Then your `global-set-key's need to change to `local-set-key'. (Unfortunately, the `ascii-character' property is a global thing, which would tend to hinder implementing this kind of functionality.) This again suggests that everything should be implemented in elisp. From steve@turnbull.sk.tsukuba.ac.jp Wed May 23 22:51:50 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA30881 for ; Wed, 23 May 2001 22:51:49 -0400 Received: by localhost id m152lBj-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 24 May 2001 11:49:23 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.30387.499474.132641@turnbull.sk.tsukuba.ac.jp> Date: Thu, 24 May 2001 11:49:23 +0900 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs In-Reply-To: References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Alexey Mahotkin writes: >> It seems like 'ascii-character property could be renamed to >> 'single-byte-equivalent for clarity and formal correctness, Hrvoje> That cannot by right because the value of that property is Hrvoje> a character, not a byte. For instance, under Mule, it Hrvoje> works perfectly for Japanese characters. How about 'buffer-representation? Yes, the elements of a buffer are always characters, but using "character" drags a lot of stuff (coded character sets, in particular) with it. >> 1. Mapping of keysyms was the primary subject of previous >> discussion and the best practice seems to be Hrvoje> [...] Hrvoje> I take it that you would like to automatize these mappings Hrvoje> according to a new concept of "single-byte encodings", Hrvoje> present in the absence of Mule? [...] Hrvoje> Also, all of this sounds like an idea for a first-class Hrvoje> external package. Write it and distribute it to all your Hrvoje> friends. If it becomes immensely popular and all of Hrvoje> Russia starts using it, we'll include it too. It's as Hrvoje> simple as that. I agree with this. I think that probably you can and should do all of this with a package. The package could work with Mule by simply forcing all file I/O to 'binary, I bet. If the package fails in some boundary cases (which I think is highly likely, for the reasons Hrvoje gives among others), well, that's the way packages (don't) work. The core has to do better. Except for one thing. There's no reason to wait for your package to become immensely popular; we can include it immediately. :-) The various changes that you are talking about are surely not going to get in to 21.1 any other way, and not 21.4, either. They are not bug fixes to implementation, they are design changes at least, and arguably new features. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From martin@m17n.org Wed May 23 22:58:50 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA31190; Wed, 23 May 2001 22:58:45 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4O2wjp12030; Thu, 24 May 2001 11:58:45 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id LAA12850; Thu, 24 May 2001 11:58:24 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4O2wOM24545; Thu, 24 May 2001 11:58:24 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15116.30928.39045.556655@gargle.gargle.HOWL> Date: Thu, 24 May 2001 11:58:24 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Nix Cc: Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: <87zoc3hjod.fsf@loki.wkstn.nix> References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> <87zoc3hjod.fsf@loki.wkstn.nix> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Nix" == nix writes: Nix> Oh, FWIW the preprocessor should be able to handle just about anything, Nix> 'cos I'm cheating. I'm taking c-parse.y and cpplex.c from GCC, and Nix> tearing them down into something that can unambiguously spot C blocks Nix> (`stmts_and_decls'), assignments (`expr_no_commas'), Lisp_Object Nix> variable declarations (`decl' nodes), and temporaries. Everything else Nix> that I can throw away I will; we don't need a complete C parser, let Nix> alone the Objective C parts (sorry, Ovidiu ;) ). We already have a makefile rule for running the C preprocessor: make foo.i should work (the rule might not be portable to every C compiler). You'll want to run your C parser on the output of that. Nix> Fun. (But if this were C++ it would not be fun, it would be torment...) Ahhh, but this _is_ C++. The production xemacs I use is compiled by a C++ compiler. And the road is open to someone to take xemacs in a purely C++ direction, for example to create Qt-xemacs. >> Sorry, I meant there's little scope for a Boehm mark() to be better >> than the existing mark() because the existing one, via lisp object >> type mark methods, already knows exactly which object components might >> contain other Lisp_Objects. The mark bitmap won't help you much >> during the mark phase, in fact it ought to make things worse. Nix> Hmm. Why is that? The current garbage collector has appalling VM Nix> behaviour; every Lisp_Object is sucked back into memory, even if they Nix> cannot contain other Lisp_Objects. If a mark bitmap is used, a Nix> Lisp_Object will only be accessed for pointer tracing; if it cannot Nix> contain another Lisp_Object, it won't be touched. Oh, you mean that Lisp object types not containing any Lisp_Objects as members are accessed by the current gc to access the mark bit in the lrecord_header? That's true, but currently, also the type and the c_readonly members need to be accessed. If you move *only* the mark bits to a separate bitmap, you still need to determine the type of each object. And even if you don't have to read the lrecord_header of lisp objects that don't reference other lisp objects, I think you won't win very much, because MOST lisp objects do reference other lisp objects. You can look at the output of (garbage-collect) to figure out what the potential savings are. Nix> I'll admit that I haven't instrumented the existing gc to find out what Nix> percentage of objects are accessed only to set the mark bit; I'll do so Nix> as soon as this cold has worn off. (I'll feel a right idiot if the Nix> answer is something like 1%, too...) Programmers are notoriously poor at estimating performance questions. That also means you shouldn't trust my pessimism above. >> The place where the Boehm gc shines performance wise is not during gc >> at all, but in the fact that gcpros can be dispensed with entirely >> while the mutator runs. Normally the advantage of mark&sweep over >> reference counting is: not slowing down the mutator. But gcproing does >> slow down the mutator. But I really don't know how much overhead we >> have from GCPROing, and it's hard to measure. My random guess is that >> 10% of the runtime of lisp function calls that do no work (i.e. return >> immediately) is taken up with gcproing. Nix> However, a (not huge) general slowdown like that is hard for humans to Nix> spot. What humans definitely *do* spot (well, I know I've spotted it, Nix> and so have friends of mine, new XEmacs hands and old) is the total Nix> stoppage we get whenever GCing runs and the world freezes except for the Nix> hammering of the disk :( if XEmacs is totally in swap, it can be frozen Nix> for a minute or more while GC runs. I don't see this happen. Your machine has to have enough memory to run xemacs - it's a memory hog. Better ways to fix this (the "resident set size problem") are: - load less lisp. - load lisp more lazily. (or gasp, unload lisp after it's not been used for a while... think of loading lisp as "paging in") - generational gc. Nix> Given Moore's Law and the fact that machines with small amounts of Nix> memory are getting steadily harder to find and steadily harder to run Nix> late versions of XEmacs on (and probably don't see many upgrades Nix> anyway), I am happy to *increase* the number of GCPROs substantially, to Nix> ensure that we can freely modify arbitrary functions without triggering Nix> GC hell. After all, GCPROs are really quite efficiently implemented; You're complaining about how slow xemacs is, and also "it's ok for me to make it a little slower". Nix> it's not as if they call malloc() or something like that. (As a Nix> *structure*, the gcprolist is praiseworthy. It's just the manual way Nix> it's kept updated that's disgusting and restrictive.) Offhand, it bothers me that most struct gcpro protect just one variable, so much of the time the initialization and reading of the nvars member is wasted. But I don't know whether this can be easily optimized away. Could one have a gcprolist with only `simple' variables, and a multiple_gcprolist that can protect arrays of variables? Nix> (Then I read of GCPRO and felt quite ill...) There are other health-sapping critters lurking in the xemacs source code... From youngs@xemacs.org Wed May 23 23:38:21 2001 Received: from mail002.syd.optusnet.com.au (mail002.syd.optusnet.com.au [203.2.75.245]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA01904 for ; Wed, 23 May 2001 23:38:20 -0400 Received: from slackware.mynet.pc (wdcax13-070.dialup.optusnet.com.au [198.142.220.70]) by mail002.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4O3cDM06704 for ; Thu, 24 May 2001 13:38:17 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4O3WYI8025504; Thu, 24 May 2001 13:32:34 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: In Search for better Descriptive Group Name on SourceForge References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 24 May 2001 13:32:33 +1000 In-Reply-To: <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Wed, 23 May 2001 16:37:02 +0900") Message-ID: Lines: 19 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "SJT" == Stephen J Turnbull writes: SJT> Steve Youngs writes: >>>XEmacs - The Multi-Platform Open Source Editor. >>>See the subtle difference? SJT> Yeah. I bet RMS will too. Don't be so competitive. ;-) I prefer the term, "assertive", or perhaps "confident". :-) -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From yoshiki@xemacs.org Thu May 24 01:54:40 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA08853; Thu, 24 May 2001 01:54:38 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4O5sZZ07158; Thu, 24 May 2001 14:54:35 +0900 Mail-Copies-To: nobody To: Martin Buchholz Cc: Nix , Richard Reingruber , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> <87zoc3hjod.fsf@loki.wkstn.nix> <15116.30928.39045.556655@gargle.gargle.HOWL> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 24 May 2001 14:54:35 +0900 In-Reply-To: <15116.30928.39045.556655@gargle.gargle.HOWL> (Martin Buchholz's message of "Thu, 24 May 2001 11:58:24 +0900") Message-ID: <87n18370mc.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 19 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Martin Buchholz writes: > Nix> Given Moore's Law and the fact that machines with small amounts of > Nix> memory are getting steadily harder to find and steadily harder to run > Nix> late versions of XEmacs on (and probably don't see many upgrades > Nix> anyway), I am happy to *increase* the number of GCPROs substantially, to > Nix> ensure that we can freely modify arbitrary functions without triggering > Nix> GC hell. After all, GCPROs are really quite efficiently implemented; > > You're complaining about how slow xemacs is, and also "it's ok for me > to make it a little slower". It's OK to make XEmacs a little bit slower but eliminate disruptive pause is the reason behind adopting incremental GC. -- Yoshiki Hayashi From yoshiki@xemacs.org Thu May 24 02:00:07 2001 Received: from iruka.sanpo.t.u-tokyo.ac.jp (sanpo-gw.t.u-tokyo.ac.jp [133.11.74.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA09117; Thu, 24 May 2001 02:00:05 -0400 Received: from u.sanpo.t.u-tokyo.ac.jp.buck.sodan.org (u.sanpo.t.u-tokyo.ac.jp [10.2.0.15]) by mail.sanpo.t.u-tokyo.ac.jp (8.11.1+3.4W/3.7W/smtpfeed-1.07.1) with ESMTP id f4O600Z07305; Thu, 24 May 2001 15:00:00 +0900 Mail-Copies-To: nobody To: Alexey Mahotkin Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org, "Jason R. Mastaler" Subject: Re: Non-english discussion channels References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15096.49407.763993.21009@turnbull.sk.tsukuba.ac.jp> <873d9vq02g.fsf@tyranny.hsys.msk.ru> From: Yoshiki Hayashi MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Date: 24 May 2001 15:00:00 +0900 In-Reply-To: <873d9vq02g.fsf@tyranny.hsys.msk.ru> (Alexey Mahotkin's message of "24 May 2001 00:31:35 +0400") Message-ID: <87k83770db.fsf@u.sanpo.t.u-tokyo.ac.jp> Lines: 15 User-Agent: T-gnus/6.15.2 (based on Oort Gnus v0.02) Alexey Mahotkin writes: > SJT> We could also create an xemacs-users-ru list to parallel c.e.x and > SJT> xemacs-beta, but specifically chartered for Russian discussion. > SJT> Again, this has worked for Japanese (although traffic has gone to zero > SJT> on xemacs-users-ja recently). > > I hope that xemacs-ru mailing list will be created soon by friendly > sysadmins. Most worthy questions from there will be brought to your > attention, don't worry :) Then you need to ask Jason (Cc: added). -- Yoshiki Hayashi From mta@arbortext.com Thu May 24 03:25:36 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA12795; Thu, 24 May 2001 03:25:35 -0400 Date: Thu, 24 May 2001 03:25:24 -0400 From: Mike Alexander To: "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS Message-ID: <37013768.3199663524@mta-1.pnet.msen.com> In-Reply-To: X-Mailer: Mulberry/2.0.6 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA12795 I've been having trouble with this on a machine running the native build of XEmacs (from the current CVS trunk) on Windows NT 4.0 using the cygwin ftp client. When I try to open a file on an FTP server (I've tried several and it doesn't seem to matter which server) the file is truncated at a random location a few thousand bytes into the file. If you look at the ftp log everything seems to be ok, but efs doesn't seem to wait for the file to be transfered before using the result. I've tried to debug this a bit, but haven't learned very much. Has anyone else seen problems like this? I'm connected via an ISDN line so ftp transfers are not too fast. This might have something to do with it. I'll try it on other machines with faster net connections and see if that affects things. If I can provide any more information let me know. Mike Alexander Arbortext, Inc. +1-734-997-0200 --On Friday, May 18, 2001 8:37 AM +0200 "Michael Sperber [Mr. Preprocessor]" wrote: > > Steve Youngs has just released EFS package version 1.25. This is an > experimental prerelease of EFS available as > > /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/efs-1.25-pkg.tar.gz > > In order to turn this into an official package release, I urgently > need your help in testing it. I've tested EFS on a number of servers, > but I only have access to Unix machines for client testing. So I > especially need some reports from Windows users, connecting to both > Unix and Windows ftp servers. This is especially as some subtle but > possibly crucial aspects of the EFS<->client interactions have > changed. > > I'm slowly working towards a testing suite, but it is not yet done and > the urgency of the XEmacs/Cygwin situation has prompted me to try to > release earlier. > > Let me emphasize that, if I cannot get some testing done by the > community, the release will be significantly delayed, as we cannot > risk putting out a faulty EFS to the general user community, given its > current prominent role in the XEmacs package system. > > I appreciate your help. > > -- > Cheers =8-} Mike > Friede, Völkerverständigung und überhaupt blabla > From 08.58016472@telia.com Thu May 24 04:08:28 2001 Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA14944; Thu, 24 May 2001 04:08:24 -0400 Received: from d1o891.telia.com (d1o891.telia.com [213.66.124.241]) by mailf.telia.com (8.11.2/8.11.0) with ESMTP id f4O88B822136; Thu, 24 May 2001 10:08:11 +0200 (CEST) Received: from blixten2 (h122n1fls33o891.telia.com [213.66.126.122]) by d1o891.telia.com (8.10.2/8.10.1) with SMTP id f4O88BU10245; Thu, 24 May 2001 10:08:11 +0200 (CEST) Received: by localhost with Microsoft MAPI; Thu, 24 May 2001 10:10:49 +0200 Message-ID: <01C0E439.CE4C2760.08.58016472@telia.com> From: Jerker Haglund <08.58016472@telia.com> Reply-To: "08.58016472@telia.com" <08.58016472@telia.com> To: "'Mike Alexander'" , "Michael Sperber [Mr. Preprocessor]" Cc: Thomas Nichols , Mats Lidell , "xemacs-beta@xemacs.org" , "xemacs-nt@xemacs.org" Subject: RE: Help test EFS Date: Thu, 24 May 2001 10:10:48 +0200 Organization: GigaSoft X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I've been having trouble with this on a machine running the native > build of XEmacs (from the current CVS trunk) on Windows NT 4.0 using > the cygwin ftp client. When I try to open a file on an FTP server > (I've tried several and it doesn't seem to matter which server) the > file is truncated at a random location a few thousand bytes into the > file. If you look at the ftp log everything seems to be ok, but efs > doesn't seem to wait for the file to be transfered before using the > result. I've tried to debug this a bit, but haven't learned very > much. Has anyone else seen problems like this? I've noticed that EFS says 'Done' long before the result is visible. That's with an ADSL connection, native 21.4.3 on Win2k. If it doesn't wait properly, this could explain why the experimental EFS seems shaky, with both cygwin and windows ftp. Things fail 1st time, try again (when things are cached) and it works. /J. Haglund > > I'm connected via an ISDN line so ftp transfers are not too fast. > This might have something to do with it. I'll try it on other > machines with faster net connections and see if that affects things. > If I can provide any more information let me know. From Adrian.Aichner@t-online.de Thu May 24 04:33:09 2001 Received: from mailout00.sul.t-online.de (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA16028; Thu, 24 May 2001 04:33:07 -0400 Received: from fwd01.sul.t-online.de by mailout00.sul.t-online.de with smtp id 152qYL-0001ic-0C; Thu, 24 May 2001 10:33:05 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.39]) by fwd01.sul.t-online.com with esmtp id 152qYo-0mvbXsC; Thu, 24 May 2001 10:33:34 +0200 To: Mike Alexander Cc: "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <37013768.3199663524@mta-1.pnet.msen.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 97 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Sender: 520002458184-0001@t-dialin.net >>>>> "Mike" == Mike Alexander writes: Mike> I've been having trouble with this on a machine running the Mike> native build of XEmacs (from the current CVS trunk) on Mike> Windows NT 4.0 using the cygwin ftp client. When I try to Mike> open a file on an FTP server (I've tried several and it Mike> doesn't seem to matter which server) the file is truncated Mike> at a random location a few thousand bytes into the file. If Mike> you look at the ftp log everything seems to be ok, but efs Mike> doesn't seem to wait for the file to be transfered before Mike> using the result. I've tried to debug this a bit, but Mike> haven't learned very much. Has anyone else seen problems Mike> like this? Hi Mikes, I just tried this again with Mike latest EFS testing version. I still cannot use cygwin ftp.exe from a native Windows XEmacs 21.1.14: open ftp.somebody.de Connected to www.somebody.de. 220 ProFTPD 1.2.0 Server (SpaceNet GmbH) [www.somebody.de] quote user "adm" 331 Password required for adm. quote pass Turtle Power! 230 User adm logged in. hash Hash mark printing on (1024 bytes/hash mark). quote cwd /www/html-data/fussball/ 250 CWD command successful. ls "-al" C:/DOCUME~1/AICHNE~1/LOCALS~1/Temp/efsaXAjtJ 200 PORT command successful. 150 Opening ASCII mode data connection for file list. 226 Transfer complete. type image 200 Type set to I. put C:\Users\AichnerAd\WWW\gs\fussball\hirschgarten.html /www/html-data/fussball/hirschgarten.html /usr/bin/ftp: local: C:UsersAichnerAdWWWgsfussballhirschgarten.html: No such file or directory That's why I have moved my cygwin ftp.exe out of the way and use C:\WinNT\system32\ftp.exe instead. Best regards, Adrian Mike> I'm connected via an ISDN line so ftp transfers are not too Mike> fast. This might have something to do with it. I'll try it Mike> on other machines with faster net connections and see if Mike> that affects things. If I can provide any more information Mike> let me know. Mike> Mike Alexander Mike> Arbortext, Inc. +1-734-997-0200 Mike> --On Friday, May 18, 2001 8:37 AM +0200 "Michael Sperber [Mr. Preprocessor]" wrote: >> >> Steve Youngs has just released EFS package version 1.25. This is an >> experimental prerelease of EFS available as >> >> /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/efs-1.25-pkg.tar.gz >> >> In order to turn this into an official package release, I urgently >> need your help in testing it. I've tested EFS on a number of servers, >> but I only have access to Unix machines for client testing. So I >> especially need some reports from Windows users, connecting to both >> Unix and Windows ftp servers. This is especially as some subtle but >> possibly crucial aspects of the EFS<->client interactions have >> changed. >> >> I'm slowly working towards a testing suite, but it is not yet done and >> the urgency of the XEmacs/Cygwin situation has prompted me to try to >> release earlier. >> >> Let me emphasize that, if I cannot get some testing done by the >> community, the release will be significantly delayed, as we cannot >> risk putting out a faulty EFS to the general user community, given its >> current prominent role in the XEmacs package system. >> >> I appreciate your help. >> >> -- >> Cheers =8-} Mike >> Friede, Völkerverständigung und überhaupt blabla >> -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From npak@ispras.ru Thu May 24 07:05:08 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id HAA21855 for ; Thu, 24 May 2001 07:05:03 -0400 Received: (qmail 7660 invoked from network); 24 May 2001 11:03:54 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 24 May 2001 11:03:54 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f4OB4k811551; Thu, 24 May 2001 15:04:46 +0400 (MSK) Received: tid PAA09796; Fri, 24 May 1996 15:04:31 +0300 Received: from HOOKAH.kasbek.ispras.ru (hookah.kazbek.ispras.ru [194.186.94.160]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f4OB4Ug92950; Thu, 24 May 2001 15:04:31 +0400 (MSD) (envelope-from npak@ispras.ru) To: rendhalver@users.sourceforge.net Cc: Adrian.Aichner@t-online.de (Adrian Aichner), "Stephen J. Turnbull" , Hrvoje Niksic , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> <15116.14683.528468.483722@ulthwe.dyndns.org> From: npak@ispras.ru (Nick Pakoulin) Date: 24 May 2001 15:04:33 +0400 In-Reply-To: Peter Brown's message of "Thu, 24 May 2001 08:27:39 +1000" Message-ID: Lines: 42 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii intro: "PB" == Peter Brown writes: IMHO, eXtensible is a greate idea! XEmacs - extensible multi-platform editing and development environment Nick. PB> Adrian Aichner writes: >> >>>>> "Stephen" == Stephen J Turnbull writes: PB> im going away for a few days so i will cast my vote now PB> its so hard to decide but i agree with adrian about not needing Open PB> Source on sourceforge >> The XEmacs Multi-OS Editing & Development Environment XEmacs - Open >> Source, Multi-platform, Multi-Language, and _More_ Than Just an Editor >> XEmacs - Open Source, Multi-platform, Multi-Language, and a Way Of Life >> XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor >> XEmacs - The Multi-Platform Open Source Editor. XEmacs - the >> Multi-Platform Open Source Editor and Environment XEmacs - the >> Multi-Platform Platform XEmacs Multi-Platform Open Source Editor XEmacs, >> an Open Source Editor for MS Windows and Unix PB> and i do like the Multi-Language bit (not just cause i suggested it) um PB> maybe we could nail something together from the good bits of each PB> so maybe PB> XEmacs - Multi-platform, Multi-Language, Environment PB> um what *does* the X stand for anyway PB> eXtensible ?? PB> -- PB> ------------------------------------------------------------------------- PB> Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development PB> Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net PB> ------------------------------------------------------------------------- From monnier+lists.xemacs.beta/news/@RUM.cs.yale.edu Thu May 24 09:47:18 2001 Received: from tequila.cs.yale.edu (tequila.cs.yale.edu [128.36.229.152]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA29699 for ; Thu, 24 May 2001 09:47:18 -0400 Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.11.0/8.9.3) with SMTP id f4ODl3215930 for ; Thu, 24 May 2001 09:47:03 -0400 To: xemacs-beta@xemacs.org Sender: monnier@RUM.cs.yale.edu From: "Stefan Monnier" Newsgroups: lists.xemacs.beta Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <15116.8055.102676.553191@craigl.lanning.net> Date: 24 May 2001 09:46:59 -0400 Message-ID: <5lbsoiyi3w.fsf@rum.cs.yale.edu> Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Path: rum.cs.yale.edu NNTP-Posting-Host: rum.cs.yale.edu X-Trace: 24 May 2001 09:46:59 -0400, rum.cs.yale.edu >>>>> "Craig" == Craig Lanning writes: > One major advantage of CLiCC is that it is designed to do global > optimization for the entire application. This is something that C > compilers rarely (if ever) do. I generally find such whole program optimization completely stupid, but even more so in the specific case of (X)Emacs where code *will* be added when the next package gets loaded. Hopefully it can be adapted to be only "whole file". Stefan From hniksic@arsdigita.com Thu May 24 10:57:53 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA01381; Thu, 24 May 2001 10:57:53 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152wYe-0005td-00; Thu, 24 May 2001 16:57:48 +0200 Sender: hniksic@florida.arsdigita.de To: Martin Buchholz Cc: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> <15116.27476.989838.639409@gargle.gargle.HOWL> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 24 May 2001 16:57:48 +0200 In-Reply-To: <15116.27476.989838.639409@gargle.gargle.HOWL> (Martin Buchholz's message of "Thu, 24 May 2001 11:00:52 +0900") Message-ID: Lines: 27 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Martin Buchholz writes: > This is a very EASY translator to write compared to some of the other > projects being considered. Yes. > The hard part is integrating this into xemacs. I'm not convinced that integration is harder than writing the translator, but anyway... > Like figuring out the shared object loading mechanism across > platforms. Should all the package lisp be compiled to .so at > installation time, or should there be a JIT that optimizes hotspots > at run-time (it would have to call the compiler transparently to do > so, however). The former. I hate the JIT idea, especially in the context of Emacs! > Don't expect it to be a huge win, however. All the optimized machine > code will take up more memory than the bytecodes. And many elisp > operations like (setq i (1+ i)) will not be compilable to C i++, I never expect such an optimization because we don't have lexical scoping, declarations, type inference, etc. But I still believe that even without that optimization the translator would be a huge win. From hniksic@arsdigita.com Thu May 24 11:04:33 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA01718 for ; Thu, 24 May 2001 11:04:33 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152weP-0005um-00; Thu, 24 May 2001 17:03:45 +0200 Sender: hniksic@florida.arsdigita.de To: "Stephen J. Turnbull" Cc: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> <15116.30387.499474.132641@turnbull.sk.tsukuba.ac.jp> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 24 May 2001 17:03:45 +0200 In-Reply-To: <15116.30387.499474.132641@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Thu, 24 May 2001 11:49:23 +0900") Message-ID: Lines: 25 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Stephen J. Turnbull" writes: > How about 'buffer-representation? Yes, the elements of a buffer are > always characters, but using "character" drags a lot of stuff (coded > character sets, in particular) with it. The term "character" is pretty well defined in XEmacs, so `character-representation' would probably do it. buffer-representation sucks because characters are also applicable to strings, streams, etc. > I agree with this. I think that probably you can and should do all of > this with a package. The package could work with Mule by simply > forcing all file I/O to 'binary, I bet. Or, if the package is general enough, it could simply turn on the appropriate Mule magic behind the scenes in order to produce the same effect as the same commands had under no-Mule. > Except for one thing. There's no reason to wait for your package to > become immensely popular; we can include it immediately. :-) I would prefer to wait until a degree of maturity, if not popularity, is reached. From jason@xemacs.org Thu May 24 11:30:59 2001 Received: from sclp3.sclp.com ([209.196.61.66]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id LAA03395 for ; Thu, 24 May 2001 11:30:59 -0400 Received: (qmail 24844 invoked from network); 24 May 2001 15:30:15 -0000 Received: from localhost (HELO nightshade.la.mastaler.com) (jason@127.0.0.1) by localhost with SMTP; 24 May 2001 15:30:15 -0000 Received: (qmail 50483 invoked by uid 666); 24 May 2001 15:30:01 -0000 From: "Jason R. Mastaler" To: Alexey Mahotkin Cc: "Stephen J. Turnbull" , xemacs-beta@xemacs.org, "Jason R. Mastaler" Subject: Re: Non-english discussion channels References: <15096.23211.39938.402150@gargle.gargle.HOWL> <15096.49407.763993.21009@turnbull.sk.tsukuba.ac.jp> <873d9vq02g.fsf@tyranny.hsys.msk.ru> <87k83770db.fsf@u.sanpo.t.u-tokyo.ac.jp> Organization: The XEmacs Project X-Face: "Whz7py/hGVg+:}u&Q$/5z>j)gy%qNRX{j]0xGF&?Z"^b3`[6dY'^jSDlZDHh$m1~YX6U3J 1gOce%&je3)lVMOa/P,=9Kj:lmZb6]1hMmam*SW$GrVPa>b05y9/svb[uX.i><]^; iE1^(p_*=eLQJ6g$[aOX9I#`DCP\^O=RR:7|95hZ Date: 24 May 2001 09:29:59 -0600 In-Reply-To: <87k83770db.fsf@u.sanpo.t.u-tokyo.ac.jp> (Yoshiki Hayashi's message of "24 May 2001 15:00:00 +0900") Message-ID: Lines: 19 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Delivery-Agent: TMDA v0.14/Python 2.1 (freebsd4) Yoshiki Hayashi writes: > > SJT> We could also create an xemacs-users-ru list to parallel c.e.x and > > SJT> xemacs-beta, but specifically chartered for Russian discussion. > > SJT> Again, this has worked for Japanese (although traffic has gone to zero > > SJT> on xemacs-users-ja recently). > > > > I hope that xemacs-ru mailing list will be created soon by friendly > > sysadmins. Most worthy questions from there will be brought to your > > attention, don't worry :) > > Then you need to ask Jason (Cc: added). I have queued xemacs-users-ru for creation. In the meantime, who shall be the list admin? Alexey? For obvious reasons, it should be someone who understands Russian, da? -- http://www.xemacs.org/ From Adrian.Aichner@t-online.de Thu May 24 11:42:32 2001 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA03982; Thu, 24 May 2001 11:42:31 -0400 Received: from fwd01.sul.t-online.de by mailout05.sul.t-online.de with smtp id 152xFu-0002JO-05; Thu, 24 May 2001 17:42:30 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.39]) by fwd01.sul.t-online.com with esmtp id 152xGP-1OC0SuC; Thu, 24 May 2001 17:43:01 +0200 To: XEmacs Patches Cc: XEmacs Beta List Subject: [PATCH] Cannot ssh -l xemacs shell1.sourceforge.net, http://www.us.xemacs.org not updating X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 93 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net Will commit now. Adrian About/ChangeLog addition: 2001-05-24 Adrian Aichner * XEmacsServices.content: shell1.sourceforge refuses secure connection, http://www.us.xemacs.org not updating as a consequence. xemacsweb Patch (cvs -f -z3 diff -u About): cvs server: Diffing About Index: About/XEmacsServices.content =================================================================== RCS file: /cvsroot/xemacs/xemacsweb/About/XEmacsServices.content,v retrieving revision 1.9 diff -u -r1.9 XEmacsServices.content --- About/XEmacsServices.content 2001/05/24 11:08:53 1.9 +++ About/XEmacsServices.content 2001/05/24 15:41:02 @@ -58,6 +58,44 @@ + 5 + +
    +
  • ssh -l xemacs shell1.sourceforge.net
  • +
  • http://www.us.xemacs.org
  • +
+ + 2001-05-24 + ? + + + + +
+$ ssh -l xemacs shell1.sourceforge.net
+Secure connection to shell1.sourceforge.net refused.
+
+$ 
+          
+ As a consequence, our website at SourceForge is not being + updated from the CVS repository. + + + + + + None + + + + + +

https://sourceforge.net/tracker/index.php?func=detail&aid=426949&group_id=1&atid=200001

+ + + + + 4 http://www.it.xemacs.org 2001-05-16 @@ -71,7 +109,7 @@ -
+          
 On 16 May 2001, Adrian Aichner wrote:
 
 . . .
@@ -138,7 +176,7 @@
       
         
         
-          
cvs -n -q update
takes more than 10 + cvs -n -q update takes more than 10 minutes. cvs server: Diffing About/Screenshots -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From mta@arbortext.com Thu May 24 12:42:53 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA07799; Thu, 24 May 2001 12:42:52 -0400 Date: Thu, 24 May 2001 12:42:42 -0400 From: Mike Alexander To: Adrian Aichner cc: xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS Message-ID: <39024943.3199696962@mta-1.pnet.msen.com> In-Reply-To: X-Mailer: Mulberry/2.0.6 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit --On Thursday, May 24, 2001 10:32 AM +0200 Adrian Aichner wrote: > I just tried this again with Mike latest EFS testing version. > > I still cannot use cygwin ftp.exe from a native Windows XEmacs > 21.1.14: > > open ftp.somebody.de > Connected to www.somebody.de. > 220 ProFTPD 1.2.0 Server (SpaceNet GmbH) [www.somebody.de] > quote user "adm" > 331 Password required for adm. > quote pass Turtle Power! > 230 User adm logged in. > hash > Hash mark printing on (1024 bytes/hash mark). > quote cwd /www/html-data/fussball/ > 250 CWD command successful. > ls "-al" C:/DOCUME~1/AICHNE~1/LOCALS~1/Temp/efsaXAjtJ > 200 PORT command successful. > 150 Opening ASCII mode data connection for file list. > 226 Transfer complete. > type image > 200 Type set to I. > put C:\Users\AichnerAd\WWW\gs\fussball\hirschgarten.html > /www/html-data/fussball/hirschgarten.html /usr/bin/ftp: local: > C:UsersAichnerAdWWWgsfussballhirschgarten.html: No such file or directory > > That's why I have moved my cygwin ftp.exe out of the way and use > C:\WinNT\system32\ftp.exe instead. That problem has been fixed in 21.5 which is what I was using. It now uses "/" as a path delimiter in FTP commands regardless of the setting of directory-sep-char. Mike Alexander Arbortext, Inc. +1-734-997-0200 From hniksic@arsdigita.com Thu May 24 13:45:47 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA13642; Thu, 24 May 2001 13:45:47 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 152zBC-0007rc-00; Thu, 24 May 2001 19:45:46 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Patch Reviews , XEmacs Beta List Subject: Changed *scratch* message? X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 24 May 2001 19:45:46 +0200 Message-ID: Lines: 10 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eek, who changed the scratch message to be so huge? Could we please have the old, terser, message back? Rationale: * What C-something means is explained on the splash screen. Someone who doesn't know that will ignore the message anyway. * The idea of the message is to be informative, but as short as possible, so that you can ignore it. From Tony.Lam@eng.sun.com Thu May 24 14:49:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA19353 for ; Thu, 24 May 2001 14:49:57 -0400 Received: from zoso.Eng.Sun.COM ([129.144.14.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09934 for ; Thu, 24 May 2001 12:49:55 -0600 (MDT) Received: from philly.zoso.eng.sun.com (philly [129.144.27.133]) by zoso.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29528 for ; Thu, 24 May 2001 11:49:55 -0700 (PDT) X-Mailer: 21.4 (patch 2) "Developer-Friendly Unix APIs" XEmacs Lucid (via feedmail 9-beta-4 I) From: Tony Lam To: xemacs-beta@xemacs.org Subject: XEmacs 21.4.2 Hung with Fatal IO Error Date: 24 May 2001 11:49:49 -0700 Lines: 37 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii After using the same XEmacs session for days, I got this error when trying to have XEmacs display some contents with a new frame. The frame popped up fine, but XEmacs hung with the error below, showing partial contents: xemacs-21.4.2: Fatal I/O Error 0 (Error 0) on display connection ":0.0" after 964101 requests (964100 known processed) with 5 events remaining. Here's the stack trace: tonywl@philly> /usr/proc/bin/pstack 14050 14050: xemacs-21.4.2 fed194c0 _poll (16, 0, ffbed230, ffbed1b0, ffbed130, ffbecfd0) + 8 fefbbcc0 _XtWaitForSomething (302400, 0, 0, 1, f4240, 0) + 1e4 fefc0e94 XtAppPending (4, 1, 2, 4, 302400, 1) + 264 0017bc3c drain_X_queue (2a761c, 12aa2, 12a81, ffbed4a0, 0, 0) + 2c 0017bd68 emacs_Xt_event_pending_p (1, 2a264c, 2d2804, 0, 0, 0) + 110 000b9558 event_stream_event_pending_p (1, 2d2804, 2d2804, 0, 0, 0) + 20 000ba174 detect_input_pending (2d2804, 187b064, 2d2804, 0, 0, 2a2400) + 4 000bb75c run_pre_idle_hook (2d2804, 2d2804, 2d2804, 1, 2d2804, 0) + 20 000bbb2c Fnext_event (2d2804, 2a264c, 552380, 0, 20da65c, 5ad600) + 3a0 0006bf6c Fcommand_loop_1 (2a2400, 1, 2a7c00, 0, 0, 0) + 194 00089594 condition_case_1 (296000, 2a2800, 2a1000, 6b77c, 2d2804, 0) + 110 0006b884 command_loop_3 (0, ffbed8e0, ffbed958, 0, 0, 0) + 40 0006b8b8 command_loop_2 (2d2804, 6b8b4, ffffffff, fffffff8, 0, 1d1d0ed) + 4 000891f4 internal_catch (2e60c4, 6b8b4, 2d2804, 0, 0, 0) + b0 0006bab0 initial_command_loop (2c80e8, 2a1000, 4d3fb0, 4d3f9c, 322234, 321810) + 1e0 000855a8 xemacs_21_4_2_sparc_sun_solaris2_7 (1, 2d2804, 2c8000, 2a0c00, 2c8400, ffbedbc4) + 10b8 00085e34 main (1, ffbedbc4, ffbedbcc, 285c00, 0, 0) + b8 00051cd4 _start (0, 0, 0, 0, 0, 0) + dc In XEmacs 21.4 (patch 2) "Developer-Friendly Unix APIs" [Lucid] (sparc-sun-solaris2.7) of Fri May 11 2001 on micasa configured using `configure --prefix=/import/dream/tools --with-prefix=no --package-path=/import/dream/tools/lib/xemacs/xemacs-packages --with-gcc=no '--cflags=-v -xO2' --with-x --with-xpm '--site-includes=/import/dream/tools/include /usr/dt/include' '--site-libraries=/usr/lib /import/dream/tools/lib /usr/dt/lib' --with-database=berkdb,dbm --with-png --with-jpeg --with-tooltalk --with-workshop --with-cde --with-sparcworks=yes --with-xface --with-socks=no --with-mule=no --with-xfs=no --error-checking=no --debug=yes --with-gtk=no' Tony From Adrian.Aichner@t-online.de Thu May 24 16:28:33 2001 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA25403 for ; Thu, 24 May 2001 16:28:32 -0400 Received: from fwd01.sul.t-online.de by mailout06.sul.t-online.de with smtp id 1531iZ-0000QE-04; Thu, 24 May 2001 22:28:23 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.117]) by fwd01.sul.t-online.com with esmtp id 1531is-1n9slUC; Thu, 24 May 2001 22:28:42 +0200 To: XEmacs Beta List Subject: BAD: Handling of package-index by package release and install system X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 57 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net Hello All, Hello Steve, many of you must be experiencing the same problems. I had long wanted to write about the breakage I see. Some Facts: The package-index file contains (package-get-update-base-entry (quote ...)) forms. The file is not meant to be hand-edited: ;; Package Index file -- Do not edit manually. ;;;@@@ (package-get-update-base-entry (quote ... Building a package adds a (package-get-update-base-entry (quote ...)) form at the beginning of the package-index file in the staging area. The Problem: When a package-index file is read, the last (package-get-update-base-entry (quote ...)) form for a certain package in that file supercedes earlier ones. This means that the Package Release Engineer has to fiddle with the package-index file or remove the package-index file and rebuild all packages from scratch. Two Questions: 1. Is it a valuable feature for the package-index file to contain multiple instances of the same package to provide a building history of packages? We don't seem to have the interfaces to make use of this feature today. 2. Shouldn't the latest addition to the package-index file supercede older definitions? Has anybody been working on these problems already? Any suggestions what should be done? I think item 2 really needs fixing. Best regards, Adrian -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From jhar@tardis.ed.ac.uk Thu May 24 17:25:26 2001 Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA29483; Thu, 24 May 2001 17:25:23 -0400 Received: from marginal.demonadsltrial.co.uk ([193.195.64.136] helo=tardis.ed.ac.uk) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 1532bb-000DSi-0X; Thu, 24 May 2001 22:25:15 +0100 Message-ID: <3B0D7C39.5F2A2D41@tardis.ed.ac.uk> Date: Thu, 24 May 2001 22:25:13 +0100 From: Jonathan Harris X-No-Archive: Yes X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Aichner CC: Mike Alexander , "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <37013768.3199663524@mta-1.pnet.msen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, ... > I just tried this again with Mike latest EFS testing version. > > I still cannot use cygwin ftp.exe from a native Windows XEmacs > 21.1.14: ... > put C:\Users\AichnerAd\WWW\gs\fussball\hirschgarten.html /www/html-data/fussball/hirschgarten.html > /usr/bin/ftp: local: C:UsersAichnerAdWWWgsfussballhirschgarten.html: No such file or directory My patch in message <3B09B5A4.CEB137E7@tardis.ed.ac.uk> should fix that particular problem. > That's why I have moved my cygwin ftp.exe out of the way and use > C:\WinNT\system32\ftp.exe instead. I see a different problem using Windows ftp.exe with efs package 1.22 on Windows 98se. Are you using efs package 1.22 or 1.25? Jonathan. -- Jonathan Harris | jhar@tardis.ed.ac.uk London, England | Jonathan.Harris@symbian.com From jhar@tardis.ed.ac.uk Thu May 24 17:32:13 2001 Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA30057; Thu, 24 May 2001 17:32:12 -0400 Received: from marginal.demonadsltrial.co.uk ([193.195.64.136] helo=tardis.ed.ac.uk) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 1532iH-000EPn-0X; Thu, 24 May 2001 22:32:10 +0100 Message-ID: <3B0D7DCC.79B17743@tardis.ed.ac.uk> Date: Thu, 24 May 2001 22:31:56 +0100 From: Jonathan Harris X-No-Archive: Yes X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Aichner , Mike Alexander , "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <37013768.3199663524@mta-1.pnet.msen.com> <3B0D7C39.5F2A2D41@tardis.ed.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I see a different problem using Windows ftp.exe with efs package 1.22 ^ Oops, I meant 1.25 ---------------------------------------------------+ > on Windows 98se. Are you using efs package 1.22 or 1.25? Jonathan. -- Jonathan Harris | jhar@tardis.ed.ac.uk London, England | Jonathan.Harris@symbian.com From alexm@hsys.msk.ru Thu May 24 17:49:10 2001 Received: from umail.ru (ru1.mtu.ru [195.34.32.101]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA31253 for ; Thu, 24 May 2001 17:49:09 -0400 Received: from [195.34.32.10] (HELO mtu.ru) by umail.ru (CommuniGate Pro SMTP 3.4.6) with ESMTP id 9021655 for xemacs-beta@xemacs.org; Thu, 24 May 2001 18:49:05 -0300 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp136-33.dialup.mtu-net.ru [62.118.136.33]) by mtu.ru (Postfix) with ESMTP id E521673CE for ; Fri, 25 May 2001 01:49:06 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 12023 invoked by uid 1000); 24 May 2001 21:48:02 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Hrvoje Niksic To: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 25 May 2001 01:48:01 +0400 In-Reply-To: Hrvoje Niksic's message of "23 May 2001 22:41:54 +0200" Message-ID: <87vgmqo1v2.fsf@tyranny.hsys.msk.ru> Lines: 39 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "Hrvoje" == Hrvoje Niksic writes: >> It seems like 'ascii-character property could be renamed to >> 'single-byte-equivalent for clarity and formal correctness, Hrvoje> That cannot by right because the value of that property is a Hrvoje> character, not a byte. For instance, under Mule, it works Hrvoje> perfectly for Japanese characters. Didn't knew that. Although isn't 'character-equivalent better than -representation, as it is supported by appropriate error message? Yes, it'll be implemented as elisp package. Yes, I want "single-byte encodings" to be buffer-local with all their effects (I think it's not hard). Yes, I accept the burden of maintenance for all of this. I think non-Mule setups will be actual for some more time. Hrvoje> Now that Mule has been hacked into something close to usability, I Hrvoje> must admit I doubt that what you propose it worth the maintenance Hrvoje> pain. Can you remind me why exactly Mule fails to work for you? Mule works AFAIK. But for this or that reason it is not ubiquitos. Probably that's inertia, or some traumatic experience after its early incarnations... Hrvoje> Also, all of this sounds like an idea for a first-class external Hrvoje> package. Write it and distribute it to all your friends. If it Hrvoje> becomes immensely popular and all of Russia starts using it, we'll Hrvoje> include it too. It's as simple as that. I'll surely write it, but I want ftp.xemacs.org to distribute it to all my friends as a part of default redistributable ;) It's laughable how many kludgy and broken ways of setting up some or several Cyrillic encodings I've seen in various .emacs' in .ru, I'm really tired of that.... :(( --alexm From Adrian.Aichner@t-online.de Thu May 24 18:08:27 2001 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA32555; Thu, 24 May 2001 18:08:26 -0400 Received: from fwd01.sul.t-online.de by mailout05.sul.t-online.de with smtp id 1533HB-0000sI-00; Fri, 25 May 2001 00:08:13 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.117]) by fwd01.sul.t-online.com with esmtp id 1533Hf-0jqlbUC; Fri, 25 May 2001 00:08:43 +0200 To: Jonathan Harris Cc: Adrian Aichner , Mike Alexander , "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <37013768.3199663524@mta-1.pnet.msen.com> <3B0D7C39.5F2A2D41@tardis.ed.ac.uk> <3B0D7DCC.79B17743@tardis.ed.ac.uk> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Jonathan" == Jonathan Harris writes: >> I see a different problem using Windows ftp.exe with efs package 1.22 Jonathan> ^ Jonathan> Oops, I meant 1.25 ---------------------------------------------------+ >> on Windows 98se. Are you using efs package 1.22 or 1.25? I am using (emacs-version) "XEmacs 21.1 (patch 14) \"Cuyahoga Valley\" [Lucid] (i386-pc-win32) of Mon May 21 2001 on D5DC120J" on ver Microsoft Windows 2000 [Version 5.00.2195] with SP1 and, Ah! efs 1.23 I have now upgraded to efs 1.25. cygwin ftp still doesn't work with 21.1.14. I'll try 21.5-b1 next. Best regards, Adrian Jonathan> Jonathan. Jonathan> -- Jonathan> Jonathan Harris | jhar@tardis.ed.ac.uk Jonathan> London, England | Jonathan.Harris@symbian.com -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From Adrian.Aichner@t-online.de Thu May 24 18:19:26 2001 Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA00785; Thu, 24 May 2001 18:19:24 -0400 Received: from fwd01.sul.t-online.de by mailout02.sul.t-online.de with smtp id 1533Ru-00012c-04; Fri, 25 May 2001 00:19:18 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.117]) by fwd01.sul.t-online.com with esmtp id 1533SE-1NtrEmC; Fri, 25 May 2001 00:19:38 +0200 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Jonathan Harris , Mike Alexander , "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , xemacs-beta@xemacs.org, xemacs-nt@xemacs.org Subject: Re: Help test EFS References: <37013768.3199663524@mta-1.pnet.msen.com> <3B0D7C39.5F2A2D41@tardis.ed.ac.uk> <3B0D7DCC.79B17743@tardis.ed.ac.uk> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 66 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "APA" == Adrian Aichner writes: >>>>> "Jonathan" == Jonathan Harris writes: >>> I see a different problem using Windows ftp.exe with efs package 1.22 Jonathan> ^ Jonathan> Oops, I meant 1.25 ---------------------------------------------------+ >>> on Windows 98se. Are you using efs package 1.22 or 1.25? APA> I am using (emacs-version) APA> "XEmacs 21.1 (patch 14) \"Cuyahoga Valley\" [Lucid] (i386-pc-win32) of APA> Mon May 21 2001 on D5DC120J" APA> on ver APA> Microsoft Windows 2000 [Version 5.00.2195] APA> with SP1 APA> and, Ah! efs 1.23 APA> I have now upgraded to efs 1.25. APA> cygwin ftp still doesn't work with 21.1.14. APA> I'll try 21.5-b1 next. Sure enough efs doesn't work with cygwin ftp in (emacs-version) "XEmacs 21.5 (beta1) \"anise\" [Lucid] (i586-pc-win32) of Tue May 22 2001 on D5DC120J" either: quote cwd /www/html-data/fussball/ 250 CWD command successful. ls "-al" C:/DOCUME~1/AICHNE~1/LOCALS~1/Temp/efsagA01n 200 PORT command successful. 150 Opening ASCII mode data connection for file list. ## 226 Transfer complete. quote site idle 500 'SITE IDLE' not understood. quote site umask 22 500 'SITE UMASK' not understood. type image 200 Type set to I. put C:\Users\AichnerAd\WWW\gs\fussball\hirschgarten.html /www/html-data/fussball/hirschgarten.html /usr/bin/ftp: local: C:UsersAichnerAdWWWgsfussballhirschgarten.html: No such file or directory APA> Best regards, APA> Adrian Jonathan> Jonathan. Jonathan> -- Jonathan> Jonathan Harris | jhar@tardis.ed.ac.uk Jonathan> London, England | Jonathan.Harris@symbian.com APA> -- APA> Adrian Aichner APA> mailto:adrian@xemacs.org APA> http://www.xemacs.org/ -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From hniksic@arsdigita.com Thu May 24 19:22:30 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA05581 for ; Thu, 24 May 2001 19:22:29 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 1534R2-0001pL-00 for ; Fri, 25 May 2001 01:22:28 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> <87vgmqo1v2.fsf@tyranny.hsys.msk.ru> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 25 May 2001 01:22:28 +0200 In-Reply-To: <87vgmqo1v2.fsf@tyranny.hsys.msk.ru> (Alexey Mahotkin's message of "25 May 2001 01:48:01 +0400") Message-ID: Lines: 17 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Alexey Mahotkin writes: > Mule works AFAIK. But for this or that reason it is not ubiquitos. > Probably that's inertia, or some traumatic experience after its > early incarnations... Trust me, I can understand that sentiment. If I didn't consider myself a "developer", I would definitely still be using a non-Mule XEmacs. Why? Because it works. Because it's faster. Because I'd be sure that it won't screw up binary data in a file or buffer. I also had, and still have, fairly convoluted code that made XEmacs do what I wanted with the Croatian characters. But I was always aware that the whole thing was a huge hack. Had I ever desired to overcome the "hack" stage, I would have looked into Mule anyway. From jaa@cc.jyu.fi Thu May 24 22:18:19 2001 Received: from tukki.cc.jyu.fi (tukki.cc.jyu.fi [130.234.1.1]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA12303 for ; Thu, 24 May 2001 22:18:14 -0400 Received: from localhost (jaa@localhost) by tukki.cc.jyu.fi (8.9.3/8.9.3/antispam3) with ESMTP id FAA19016 for ; Fri, 25 May 2001 05:18:13 +0300 (EET DST) Date: Fri, 25 May 2001 05:18:13 +0300 (EET DST) From: Jani Averbach X-Sender: jaa@tukki To: xemacs-beta@xemacs.org Subject: Packages installer doesn't work + other weirdiness Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! The Problems: 1st Problem Compiling won't succees without --without-msw because configure try linking against winspool library. (This is Linux machnine) 2nd Problem The package autoinstaller won't work: tools->packages->add download... tools->packages->List and Install (1) (error/warning) Error in process filter: (ftp-error FTP Error: DIR failed: 500 Illegal PORT command.) and in the menu buffer there is text: Wrong type argument: stringp, nil I have tried xemacs.org, and few other local mirros, but the situation is always same. 3rd Problem M-x build-report generated following error: Symbol's function definition is void: mail I supposed that it will generate a file, witch one I can mail other way, but it seems that it like the mail the report by itself... I compiled XEmacs-21.4.3 in Redhat 6.2 machine (intel, glibc-2.1.3, kernel 2.4.x, XFree 4.0.3, ) with following command: ./configure i686-pc-linux-gnu --with-xpm --with-png --with-jpeg --with-tiff --without-msw --with-athena=3d After that I installed efs-1.22-pkg.tar.gz xemacs-base-1.53-pkg.tar.gz as mentioned in the Installation-HOWTO. But the result was problems listed above. Any help will be very appreciate. BR, Jani --- Jani Averbach From steve@turnbull.sk.tsukuba.ac.jp Fri May 25 00:06:34 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA17841 for ; Fri, 25 May 2001 00:06:33 -0400 Received: by localhost id m1538q6-00014mC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 25 May 2001 13:04:38 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15117.55743.379997.794134@turnbull.sk.tsukuba.ac.jp> Date: Fri, 25 May 2001 13:04:15 +0900 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: RFC: generic support for single-byte encodings in non-Mule XEmacs In-Reply-To: References: <15116.6397.651561.268146@tyranny.hsys.msk.ru> <15116.30387.499474.132641@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> "Stephen J. Turnbull" writes: >> How about 'buffer-representation? Hrvoje> The term "character" is pretty well defined in XEmacs, so Hrvoje> `character-representation' would probably do it. Much better, thanks! Who's the native speaker, here, anyway?! An alternative would be `text-representation', as Ben is planning on abstracting common aspects of character, string, and buffer representation into "src/text.[ch]." Hrvoje> I would prefer to wait until a degree of maturity, if not Hrvoje> popularity, is reached. That didn't stop the disgusting hack[1] known as "package-get.el" from becoming part of the core. :-( Footnotes: [1] I'm referring only to the utter dependence on EFS. There are parts of the explicit code in the library that aren't to my taste, but no way are they "disgusting." -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Fri May 25 00:19:32 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA18350 for ; Fri, 25 May 2001 00:19:30 -0400 Received: by localhost id m15394C-00014mC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Fri, 25 May 2001 13:19:12 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15117.56613.159294.451271@turnbull.sk.tsukuba.ac.jp> Date: Fri, 25 May 2001 13:18:45 +0900 To: Jani Averbach Cc: xemacs-beta@xemacs.org Subject: Packages installer doesn't work + other weirdiness In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 1) "Copyleft" XEmacs Lucid >>>>> "Jani" == Jani Averbach writes: Jani> Compiling won't succees without --without-msw because Jani> configure try linking against winspool library. (This is Jani> Linux machnine) This is a known problem, I think, very recently reported. You have Wine installed, no? Please provide the config.log up to that point. This will help us see if we need to make further tests (there was a different library cited in earlier reports, if they are the same problem). I believe we know how to deal with it, but I haven't gotten around to looking at those patches for application to 21.4 yet. Probably will be in 21.4.4. Jani> The package autoinstaller won't work: Jani> (1) (error/warning) Error in process filter: (ftp-error FTP Jani> Error: DIR failed: 500 Illegal PORT command.) Possibly you're using an FTP client (seems unlikely in Red Hat 6.2, but you could check) that EFS doesn't know about or an ancient EFS. If you're behind a firewall, configuring EFS to tell FTP to use passive mode might help. Finally, there have been recent reports of new problems with EFS, but I think they are only for the version in pre-test. The long-term fix is to provide alternative transports (HTTP, wget, etc) for the packages, but this is not done yet. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From reneky@stud.ntnu.no Fri May 25 01:38:25 2001 Received: from due.stud.ntnu.no (due.stud.ntnu.no [129.241.56.71]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA22510 for ; Fri, 25 May 2001 01:38:19 -0400 Received: from localhost (localhost [127.0.0.1]) by due.stud.ntnu.no (Postfix) with ESMTP id AB1F817A88 for ; Fri, 25 May 2001 07:38:12 +0200 (CEST) Received: from jeeves.stud.ntnu.no (jeeves [129.241.56.14]) by due.stud.ntnu.no (Postfix) with ESMTP id 9DE2F17A83 for ; Fri, 25 May 2001 07:38:09 +0200 (CEST) Received: from localhost (reneky@localhost) by jeeves.stud.ntnu.no (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id f4P5c8L21876 for ; Fri, 25 May 2001 07:38:08 +0200 (MET DST) X-Authentication-Warning: jeeves.stud.ntnu.no: reneky owned process doing -bs Date: Fri, 25 May 2001 07:38:08 +0200 (MET DST) From: Rene Kyllingstad To: Subject: Re: Packages installer doesn't work + other weirdiness In-Reply-To: <15117.56613.159294.451271@turnbull.sk.tsukuba.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-990769088=:14090" X-Virus-Scanned: by AMaViS perl-10 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-990769088=:14090 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 25 May 2001, Stephen J. Turnbull wrote: > >>>>> "Jani" =3D=3D Jani Averbach writes: > > Jani> Compiling won't succees without --without-msw because > Jani> configure try linking against winspool library. (This is > Jani> Linux machnine) > > This is a known problem, I think, very recently reported. You have > Wine installed, no? > > Please provide the config.log up to that point. This will help us see > if we need to make further tests (there was a different library cited > in earlier reports, if they are the same problem). Here is mine. (when not using --without-msw) -- Ren=E9 ---559023410-851401618-990769088=:14090 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="config.log" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="config.log" VGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNlZCBieSBj b21waWxlcnMgd2hpbGUNCnJ1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVi dWdnaW5nIGlmIGNvbmZpZ3VyZSBtYWtlcyBhIG1pc3Rha2UuDQoNCmNvbmZp Z3VyZTo4NDc6IGNoZWNraW5nIHdoZXRoZXIgbG4gLXMgd29ya3MNCmNvbmZp Z3VyZToxMTEyOiBjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlDQpjb25maWd1 cmU6MTYyNzogY2hlY2tpbmcgZm9yIGdjYw0KY29uZmlndXJlOjE3MzE6IGNo ZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgKGdjYyAgKSB3b3Jrcw0K Y29uZmlndXJlOjE3NDk6IGdjYyAtbyBjb25mdGVzdCAgICAgICAgICAgICAg Y29uZnRlc3QuYyAgICAgICAgICAgMT4mNQ0KY29uZmlndXJlOjE3Nzc6IGNo ZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgKGdjYyAgKSBpcyBhIGNy b3NzLWNvbXBpbGVyDQpjb25maWd1cmU6MTc4MjogY2hlY2tpbmcgd2hldGhl ciB3ZSBhcmUgdXNpbmcgR05VIEMNCmNvbmZpZ3VyZToxNzg5OiBnY2MgLUUg Y29uZnRlc3QuYw0KY29uZmlndXJlOjE4MDc6IGNoZWNraW5nIHdoZXRoZXIg Z2NjIGFjY2VwdHMgLWcNCmNvbmZpZ3VyZToyMjcwOiBjaGVja2luZyBob3cg dG8gcnVuIHRoZSBDIHByZXByb2Nlc3Nvcg0KY29uZmlndXJlOjIyODk6IGdj YyAtRSAgICAgICBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5v dXQNCmNvbmZpZ3VyZToyMzQ5OiBjaGVja2luZyBmb3IgQUlYDQpjb25maWd1 cmU6MjM3ODogY2hlY2tpbmcgZm9yIEdOVSBsaWJjDQpjb25maWd1cmU6MjM5 MjogZ2NjIC1jICAgICAgICBjb25mdGVzdC5jIDE+JjUNCmNvbmZpZ3VyZToy NDgzOiBnY2MgLW8gY29uZnRlc3QgICAgICAgICAgICAgIGNvbmZ0ZXN0LmMg ICAgICAgICAgIDE+JjUNCmNvbmZpZ3VyZToyNzgwOiBjaGVja2luZyBmb3Ig YnVnZ3kgZ2NjIHZlcnNpb25zDQpjb25maWd1cmU6MjkwMzogY2hlY2tpbmcg Zm9yIGR5bm9kdW1wDQpjb25maWd1cmU6MzE5NTogY2hlY2tpbmcgZm9yIG1h bGxvY19zZXRfc3RhdGUNCmNvbmZpZ3VyZTozMjIxOiBnY2MgLW8gY29uZnRl c3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgICAg ICAgIGNvbmZ0ZXN0LmMgICAgICAgICAgLWxnY2MgLWxjIC1sZ2NjIC91c3Iv bGliL2NydG4ubyAxPiY1DQpjb25maWd1cmU6MzI0MTogY2hlY2tpbmcgd2hl dGhlciBfX2FmdGVyX21vcmVjb3JlX2hvb2sgZXhpc3RzDQpjb25maWd1cmU6 MzI1MDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRj aCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3Np Z24tY29tcGFyZSAgICAgICAgICAgICBjb25mdGVzdC5jICAgICAgICAgIC1s Z2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJl OjMzMDY6IGNoZWNraW5nIGZvciByYW5saWINCmNvbmZpZ3VyZTozMzYxOiBj aGVja2luZyBmb3IgYSBCU0QgY29tcGF0aWJsZSBpbnN0YWxsDQpjb25maWd1 cmU6MzQxNTogY2hlY2tpbmcgZm9yIGJpc29uDQpjb25maWd1cmU6MzQ0Nzog Y2hlY2tpbmcgZm9yIGEub3V0LmgNCmNvbmZpZ3VyZTozNDU1OiBnY2MgLUUg ICAgICAgY29uZnRlc3QuYyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpj b25maWd1cmU6MzQ0NzogY2hlY2tpbmcgZm9yIGVsZi5oDQpjb25maWd1cmU6 MzQ1NTogZ2NjIC1FICAgICAgIGNvbmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNv bmZ0ZXN0Lm91dA0KY29uZmlndXJlOjM0NDc6IGNoZWNraW5nIGZvciBjeWd3 aW4vdmVyc2lvbi5oDQpjb25maWd1cmU6MzQ1NTogZ2NjIC1FICAgICAgIGNv bmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJl OjM0NTE6IGN5Z3dpbi92ZXJzaW9uLmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJl Y3RvcnkNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUg MzQ1MCAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5j bHVkZSA8Y3lnd2luL3ZlcnNpb24uaD4NCmNvbmZpZ3VyZTozNDQ3OiBjaGVj a2luZyBmb3IgZmNudGwuaA0KY29uZmlndXJlOjM0NTU6IGdjYyAtRSAgICAg ICBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZp Z3VyZTozNDQ3OiBjaGVja2luZyBmb3IgaW50dHlwZXMuaA0KY29uZmlndXJl OjM0NTU6IGdjYyAtRSAgICAgICBjb25mdGVzdC5jID4vZGV2L251bGwgMj5j b25mdGVzdC5vdXQNCmNvbmZpZ3VyZTozNDQ3OiBjaGVja2luZyBmb3IgbGli Z2VuLmgNCmNvbmZpZ3VyZTozNDU1OiBnY2MgLUUgICAgICAgY29uZnRlc3Qu YyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpjb25maWd1cmU6MzQ0Nzog Y2hlY2tpbmcgZm9yIGxvY2FsZS5oDQpjb25maWd1cmU6MzQ1NTogZ2NjIC1F ICAgICAgIGNvbmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0K Y29uZmlndXJlOjM0NDc6IGNoZWNraW5nIGZvciBtYWNoL21hY2guaA0KY29u ZmlndXJlOjM0NTU6IGdjYyAtRSAgICAgICBjb25mdGVzdC5jID4vZGV2L251 bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZTozNDUxOiBtYWNoL21hY2gu aDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KY29uZmlndXJlOiBmYWls ZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAzNDUwICJjb25maWd1cmUiDQojaW5j bHVkZSAiY29uZmRlZnMuaCINCiNpbmNsdWRlIDxtYWNoL21hY2guaD4NCmNv bmZpZ3VyZTozNDQ3OiBjaGVja2luZyBmb3Igc3lzL3BhcmFtLmgNCmNvbmZp Z3VyZTozNDU1OiBnY2MgLUUgICAgICAgY29uZnRlc3QuYyA+L2Rldi9udWxs IDI+Y29uZnRlc3Qub3V0DQpjb25maWd1cmU6MzQ0NzogY2hlY2tpbmcgZm9y IHN5cy9wc3RhdC5oDQpjb25maWd1cmU6MzQ1NTogZ2NjIC1FICAgICAgIGNv bmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJl OjM0NTE6IHN5cy9wc3RhdC5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 DQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDM0NTAg ImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUg PHN5cy9wc3RhdC5oPg0KY29uZmlndXJlOjM0NDc6IGNoZWNraW5nIGZvciBz eXMvdGltZS5oDQpjb25maWd1cmU6MzQ1NTogZ2NjIC1FICAgICAgIGNvbmZ0 ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJlOjM0 NDc6IGNoZWNraW5nIGZvciBzeXMvdGltZWIuaA0KY29uZmlndXJlOjM0NTU6 IGdjYyAtRSAgICAgICBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVz dC5vdXQNCmNvbmZpZ3VyZTozNDQ3OiBjaGVja2luZyBmb3Igc3lzL3VuLmgN CmNvbmZpZ3VyZTozNDU1OiBnY2MgLUUgICAgICAgY29uZnRlc3QuYyA+L2Rl di9udWxsIDI+Y29uZnRlc3Qub3V0DQpjb25maWd1cmU6MzQ0NzogY2hlY2tp bmcgZm9yIHVsaW1pdC5oDQpjb25maWd1cmU6MzQ1NTogZ2NjIC1FICAgICAg IGNvbmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmln dXJlOjM0NDc6IGNoZWNraW5nIGZvciB1bmlzdGQuaA0KY29uZmlndXJlOjM0 NTU6IGdjYyAtRSAgICAgICBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25m dGVzdC5vdXQNCmNvbmZpZ3VyZTozNDg1OiBjaGVja2luZyBmb3Igc3lzL3dh aXQuaCB0aGF0IGlzIFBPU0lYLjEgY29tcGF0aWJsZQ0KY29uZmlndXJlOjM1 MDQ6IGdjYyAtYyAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUg LVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUg ICAgICAgY29uZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6MzUyODogY2hlY2tp bmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMNCmNvbmZpZ3VyZTozNTM5OiBn Y2MgLUUgICAgICAgY29uZnRlc3QuYyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qu b3V0DQpjb25maWd1cmU6MzYwMzogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAt V2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBl cyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAgICAgICBjb25mdGVz dC5jICAgICAgICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8g MT4mNQ0KY29uZmlndXJlOjM2Mjk6IGNoZWNraW5nIHdoZXRoZXIgdGltZS5o IGFuZCBzeXMvdGltZS5oIG1heSBib3RoIGJlIGluY2x1ZGVkDQpjb25maWd1 cmU6MzY0MTogZ2NjIC1jIC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lu bGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29t cGFyZSAgICAgICBjb25mdGVzdC5jIDE+JjUNCmNvbmZpZ3VyZTogSW4gZnVu Y3Rpb24gYG1haW4nOg0KY29uZmlndXJlOjM2Mzc6IHdhcm5pbmc6IHVudXNl ZCB2YXJpYWJsZSBgdHAnDQpjb25maWd1cmU6MzY2NTogY2hlY2tpbmcgZm9y IHN5c19zaWdsaXN0IGRlY2xhcmF0aW9uIGluIHNpZ25hbC5oIG9yIHVuaXN0 ZC5oDQpjb25maWd1cmU6MzY4MDogZ2NjIC1jIC1nIC1PMyAtV2FsbCAtV25v LXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRv dyAtV3NpZ24tY29tcGFyZSAgICAgICBjb25mdGVzdC5jIDE+JjUNCmNvbmZp Z3VyZTogSW4gZnVuY3Rpb24gYG1haW4nOg0KY29uZmlndXJlOjM2NzY6IHdh cm5pbmc6IGluaXRpYWxpemF0aW9uIGRpc2NhcmRzIHF1YWxpZmllcnMgZnJv bSBwb2ludGVyIHRhcmdldCB0eXBlDQpjb25maWd1cmU6MzY3Njogd2Fybmlu ZzogdW51c2VkIHZhcmlhYmxlIGBtc2cnDQpjb25maWd1cmU6MzcwNjogY2hl Y2tpbmcgZm9yIHV0aW1lDQpjb25maWd1cmU6MzcxNjogZ2NjIC1jIC1nIC1P MyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICBjb25mdGVzdC5j IDE+JjUNCmNvbmZpZ3VyZTozNzkzOiBjaGVja2luZyByZXR1cm4gdHlwZSBv ZiBzaWduYWwgaGFuZGxlcnMNCmNvbmZpZ3VyZTozODEzOiBnY2MgLWMgLWcg LU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90 b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIGNvbmZ0ZXN0 LmMgMT4mNQ0KY29uZmlndXJlOiBJbiBmdW5jdGlvbiBgbWFpbic6DQpjb25m aWd1cmU6MzgwOTogd2FybmluZzogdW51c2VkIHZhcmlhYmxlIGBpJw0KY29u ZmlndXJlOjM4MzU6IGNoZWNraW5nIGZvciBzaXplX3QNCmNvbmZpZ3VyZToz ODY5OiBjaGVja2luZyBmb3IgcGlkX3QNCmNvbmZpZ3VyZTozOTAzOiBjaGVj a2luZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmgNCmNvbmZpZ3VyZTozOTQy OiBjaGVja2luZyBmb3IgbW9kZV90DQpjb25maWd1cmU6Mzk3NjogY2hlY2tp bmcgZm9yIG9mZl90DQpjb25maWd1cmU6NDAxMDogY2hlY2tpbmcgZm9yIHNz aXplX3QNCmNvbmZpZ3VyZTo0MDQ1OiBjaGVja2luZyBmb3Igc29ja2xlbl90 DQpjb25maWd1cmU6NDA1NjogZ2NjIC1jIC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAgICAgICBjb25mdGVzdC5jIDE+JjUNCmNvbmZpZ3Vy ZTo0MTA2OiBjaGVja2luZyBmb3Igc3RydWN0IHRpbWV2YWwNCmNvbmZpZ3Vy ZTo0MTI0OiBnY2MgLWMgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5s aW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21w YXJlICAgICAgIGNvbmZ0ZXN0LmMgMT4mNQ0KY29uZmlndXJlOjQxNDY6IGNo ZWNraW5nIHdoZXRoZXIgc3RydWN0IHRtIGlzIGluIHN5cy90aW1lLmggb3Ig dGltZS5oDQpjb25maWd1cmU6NDE1NzogZ2NjIC1jIC1nIC1PMyAtV2FsbCAt V25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3No YWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICBjb25mdGVzdC5jIDE+JjUNCmNv bmZpZ3VyZTogSW4gZnVuY3Rpb24gYG1haW4nOg0KY29uZmlndXJlOjQxNTM6 IHdhcm5pbmc6IHN0YXRlbWVudCB3aXRoIG5vIGVmZmVjdA0KY29uZmlndXJl OjQxODE6IGNoZWNraW5nIGZvciB0bV96b25lIGluIHN0cnVjdCB0bQ0KY29u ZmlndXJlOjQxOTI6IGdjYyAtYyAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2gg LVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWdu LWNvbXBhcmUgICAgICAgY29uZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6IElu IGZ1bmN0aW9uIGBtYWluJzoNCmNvbmZpZ3VyZTo0MTg4OiB3YXJuaW5nOiBz dGF0ZW1lbnQgd2l0aCBubyBlZmZlY3QNCmNvbmZpZ3VyZTo0MjU0OiBjaGVj a2luZyBmb3Igd29ya2luZyBjb25zdA0KY29uZmlndXJlOjQzMDY6IGdjYyAt YyAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5n LXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgY29u ZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6IEluIGZ1bmN0aW9uIGBtYWluJzoN CmNvbmZpZ3VyZTo0MjgwOiB3YXJuaW5nOiB1bnVzZWQgdmFyaWFibGUgYHMn DQpjb25maWd1cmU6NDI4NTogd2FybmluZzogZGVjbGFyYXRpb24gb2YgYHgn IHNoYWRvd3MgcHJldmlvdXMgbG9jYWwNCmNvbmZpZ3VyZTo0MjkxOiB3YXJu aW5nOiBkZWNsYXJhdGlvbiBvZiBgcCcgc2hhZG93cyBwcmV2aW91cyBsb2Nh bA0KY29uZmlndXJlOjQzMDA6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSBg Zm9vJw0KY29uZmlndXJlOjQyNjg6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJs ZSBgemVybycNCmNvbmZpZ3VyZTo0MjYyOiB3YXJuaW5nOiB1bnVzZWQgdmFy aWFibGUgYHgnDQpjb25maWd1cmU6NDI3OTogd2FybmluZzogYHQnIG1pZ2h0 IGJlIHVzZWQgdW5pbml0aWFsaXplZCBpbiB0aGlzIGZ1bmN0aW9uDQpjb25m aWd1cmU6NDI5Nzogd2FybmluZzogYGInIG1pZ2h0IGJlIHVzZWQgdW5pbml0 aWFsaXplZCBpbiB0aGlzIGZ1bmN0aW9uDQpjb25maWd1cmU6NDMzMTogY2hl Y2tpbmcgd2hldGhlciBtYWtlIHNldHMgJHtNQUtFfQ0KY29uZmlndXJlOjQz NTY6IGNoZWNraW5nIHdoZXRoZXIgYnl0ZSBvcmRlcmluZyBpcyBiaWdlbmRp YW4NCmNvbmZpZ3VyZTo0MzcyOiBnY2MgLWMgLWcgLU8zIC1XYWxsIC1Xbm8t c3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93 IC1Xc2lnbi1jb21wYXJlICAgICAgIGNvbmZ0ZXN0LmMgMT4mNQ0KY29uZmln dXJlOjQzODc6IGdjYyAtYyAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdp bmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNv bXBhcmUgICAgICAgY29uZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6IEluIGZ1 bmN0aW9uIGBtYWluJzoNCmNvbmZpZ3VyZTo0MzgyOiBgbm90JyB1bmRlY2xh cmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikNCmNvbmZpZ3VyZTo0 MzgyOiAoRWFjaCB1bmRlY2xhcmVkIGlkZW50aWZpZXIgaXMgcmVwb3J0ZWQg b25seSBvbmNlDQpjb25maWd1cmU6NDM4MjogZm9yIGVhY2ggZnVuY3Rpb24g aXQgYXBwZWFycyBpbi4pDQpjb25maWd1cmU6NDM4MjogcGFyc2UgZXJyb3Ig YmVmb3JlIGBiaWcnDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoN CiNsaW5lIDQzNzYgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5o Ig0KI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy9wYXJh bS5oPg0KaW50IG1haW4oKSB7DQoNCiNpZiBCWVRFX09SREVSICE9IEJJR19F TkRJQU4NCiBub3QgYmlnIGVuZGlhbg0KI2VuZGlmDQo7IHJldHVybiAwOyB9 DQpjb25maWd1cmU6NDQ0NDogY2hlY2tpbmcgc2l6ZSBvZiBzaG9ydA0KY29u ZmlndXJlOjQ0NTk6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVdu by1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFk b3cgLVdzaWduLWNvbXBhcmUgICAgICAgICAgICAgY29uZnRlc3QuYyAgICAg ICAgICAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCmNv bmZpZ3VyZTo0NDUxOiB3YXJuaW5nOiByZXR1cm4tdHlwZSBkZWZhdWx0cyB0 byBgaW50Jw0KY29uZmlndXJlOjQ0ODc6IGNoZWNraW5nIHNpemUgb2YgaW50 DQpjb25maWd1cmU6NDUwMjogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2Fs bCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAt V3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAgICAgICBjb25mdGVzdC5j ICAgICAgICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4m NQ0KY29uZmlndXJlOjQ0OTQ6IHdhcm5pbmc6IHJldHVybi10eXBlIGRlZmF1 bHRzIHRvIGBpbnQnDQpjb25maWd1cmU6NDUyNDogY2hlY2tpbmcgc2l6ZSBv ZiBsb25nDQpjb25maWd1cmU6NDUzOTogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1P MyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAgICAgICBjb25m dGVzdC5jICAgICAgICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRu Lm8gMT4mNQ0KY29uZmlndXJlOjQ1MzE6IHdhcm5pbmc6IHJldHVybi10eXBl IGRlZmF1bHRzIHRvIGBpbnQnDQpjb25maWd1cmU6NDU2MTogY2hlY2tpbmcg c2l6ZSBvZiBsb25nIGxvbmcNCmNvbmZpZ3VyZTo0NTc2OiBnY2MgLW8gY29u ZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlz c2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAg ICAgICAgIGNvbmZ0ZXN0LmMgICAgICAgICAgLWxnY2MgLWxjIC1sZ2NjIC91 c3IvbGliL2NydG4ubyAxPiY1DQpjb25maWd1cmU6NDU2ODogd2FybmluZzog cmV0dXJuLXR5cGUgZGVmYXVsdHMgdG8gYGludCcNCmNvbmZpZ3VyZTo0NTk4 OiBjaGVja2luZyBzaXplIG9mIHZvaWQgKg0KY29uZmlndXJlOjQ2MTM6IGdj YyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxp bmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBh cmUgICAgICAgICAgICAgY29uZnRlc3QuYyAgICAgICAgICAtbGdjYyAtbGMg LWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCmNvbmZpZ3VyZTo0NjA1OiB3 YXJuaW5nOiByZXR1cm4tdHlwZSBkZWZhdWx0cyB0byBgaW50Jw0KY29uZmln dXJlOjQ2MzY6IGNoZWNraW5nIGZvciBsb25nIGZpbGUgbmFtZXMNCmNvbmZp Z3VyZTo0NjgyOiBjaGVja2luZyBmb3Igc2luDQpjb25maWd1cmU6NDcwODog Z2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lu bGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29t cGFyZSAgICAgICAgICAgICBjb25mdGVzdC5jICAgICAgICAgIC1sZ2NjIC1s YyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjQ2OTI6 IHdhcm5pbmc6IGNvbmZsaWN0aW5nIHR5cGVzIGZvciBidWlsdC1pbiBmdW5j dGlvbiBgc2luJw0KL3RtcC9jY3hmZUZrbS5vOiBJbiBmdW5jdGlvbiBgbWFp bic6DQovdXNyL2xvY2FsL3NyYy94ZW1hY3MtMjEuNC4zL2NvbmZpZ3VyZTo0 NzAyOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBzaW4nDQpjb2xsZWN0Mjog bGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQg cHJvZ3JhbSB3YXM6DQojbGluZSA0Njg1ICJjb25maWd1cmUiDQojaW5jbHVk ZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9f c3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAg ICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIHNpbigpOyBiZWxvdy4g ICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2Nj MiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0K LyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJl dHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpj aGFyIHNpbigpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxp YnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1w bGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29t ZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5n IHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBh bGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX3NpbikgfHwgZGVmaW5l ZCAoX19zdHViX19fc2luKQ0KY2hva2UgbWUNCiNlbHNlDQpzaW4oKTsNCiNl bmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6NDcyNjogY2hlY2tp bmcgZm9yIHNpbiBpbiAtbG0NCmNvbmZpZ3VyZTo0NzQyOiBnY2MgLW8gY29u ZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlz c2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAg ICAgICAgIGNvbmZ0ZXN0LmMgICAtbG0gICAgICAgICAtbGdjYyAtbGMgLWxn Y2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCmNvbmZpZ3VyZTo0NzM1OiB3YXJu aW5nOiBjb25mbGljdGluZyB0eXBlcyBmb3IgYnVpbHQtaW4gZnVuY3Rpb24g YHNpbicNCmNvbmZpZ3VyZTo0NzkzOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8z IC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5 cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgICAgICAgIGNvbmZ0 ZXN0LmMgICAgICAgLWxtICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9j cnRuLm8gMT4mNQ0KY29uZmlndXJlOjQ4MTA6IGNoZWNraW5nIHR5cGUgb2Yg bWFpbCBzcG9vbCBmaWxlIGxvY2tpbmcNCmNvbmZpZ3VyZTo0ODE0OiBjaGVj a2luZyBmb3IgbG9ja2YNCmNvbmZpZ3VyZTo0ODQwOiBnY2MgLW8gY29uZnRl c3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgICAg ICAgIGNvbmZ0ZXN0LmMgICAgICAgLWxtICAgIC1sZ2NjIC1sYyAtbGdjYyAv dXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjQ4MTQ6IGNoZWNraW5n IGZvciBmbG9jaw0KY29uZmlndXJlOjQ4NDA6IGdjYyAtbyBjb25mdGVzdCAt ZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXBy b3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgICAgICAg Y29uZnRlc3QuYyAgICAgICAtbG0gICAgLWxnY2MgLWxjIC1sZ2NjIC91c3Iv bGliL2NydG4ubyAxPiY1DQpjb25maWd1cmU6NDk3NDogY2hlY2tpbmcgd2hl dGhlciB0aGUgLXhpbGRvZmYgY29tcGlsZXIgZmxhZyBpcyByZXF1aXJlZA0K Y29uZmlndXJlOjQ5OTc6IGNoZWNraW5nIGZvciBzcGVjaWZpZWQgd2luZG93 IHN5c3RlbQ0KY29uZmlndXJlOjU0NTA6IGNoZWNraW5nIGZvciBYDQpjb25m aWd1cmU6NTc2OTogY2hlY2tpbmcgZm9yIGRuZXRfbnRvYSBpbiAtbGRuZXQN CmNvbmZpZ3VyZTo1Nzg1OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxs IC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X c2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVk ZSAgICAgICBjb25mdGVzdC5jICAgLWxkbmV0ICAgICAgLWxtICAgIC1sZ2Nj IC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1 c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbGRuZXQNCmNvbGxlY3Qy OiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxl ZCBwcm9ncmFtIHdhczoNCiNsaW5lIDU3NzQgImNvbmZpZ3VyZSINCiNpbmNs dWRlICJjb25mZGVmcy5oIg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJu YWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVz ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw ZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBkbmV0 X250b2EoKTsNCg0KaW50IG1haW4oKSB7DQpkbmV0X250b2EoKQ0KOyByZXR1 cm4gMDsgfQ0KY29uZmlndXJlOjU4MDk6IGNoZWNraW5nIGZvciBkbmV0X250 b2EgaW4gLWxkbmV0X3N0dWINCmNvbmZpZ3VyZTo1ODI1OiBnY2MgLW8gY29u ZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlz c2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAg IC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgICBjb25mdGVzdC5jICAgLWxkbmV0 X3N0dWIgICAgICAtbG0gICAgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2Ny dG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5v dCBmaW5kIC1sZG5ldF9zdHViDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBl eGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQoj bGluZSA1ODE0ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCIN Ci8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBh dm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGlu dCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAg YnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk IHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgZG5ldF9udG9hKCk7DQoNCmludCBt YWluKCkgew0KZG5ldF9udG9hKCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZTo1ODU0OiBjaGVja2luZyBmb3IgZ2V0aG9zdGJ5bmFtZQ0KY29uZmlndXJl OjU4ODA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0 Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdz aWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgIGNv bmZ0ZXN0LmMgICAgICAgLWxtICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xp Yi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjU5NDc6IGNoZWNraW5nIGZvciBj b25uZWN0DQpjb25maWd1cmU6NTk3MzogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1P MyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDEx L2luY2x1ZGUgICAgICAgY29uZnRlc3QuYyAgICAgICAtbG0gICAgLWxnY2Mg LWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQpjb25maWd1cmU6NjAz NjogY2hlY2tpbmcgZm9yIHJlbW92ZQ0KY29uZmlndXJlOjYwNjI6IGdjYyAt byBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUg LVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUg ICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgIGNvbmZ0ZXN0LmMgICAg ICAgLWxtICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4m NQ0KY29uZmlndXJlOjYxMjM6IGNoZWNraW5nIGZvciBzaG1hdA0KY29uZmln dXJlOjYxNDk6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1z d2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cg LVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAg IGNvbmZ0ZXN0LmMgICAgICAgLWxtICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNy L2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjYyMjI6IGNoZWNraW5nIGZv ciBJY2VDb25uZWN0aW9uTnVtYmVyIGluIC1sSUNFDQpjb25maWd1cmU6NjIz ODogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAt V2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24t Y29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgIC1ML3Vzci9YMTEv bGliICAgICAgY29uZnRlc3QuYyAgIC1sSUNFICAgICAgLWxtICAgIC1sZ2Nj IC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjY0 MDU6IGNoZWNraW5nIGZvciBYIGRlZmluZXMgZXh0cmFjdGVkIGJ5IHhta21m DQpjb25maWd1cmU6NjQ1NDogY2hlY2tpbmcgZm9yIFgxMS9JbnRyaW5zaWMu aA0KY29uZmlndXJlOjY0NjI6IGdjYyAtRSAgICAgICAtSS91c3IvWDExL2lu Y2x1ZGUgY29uZnRlc3QuYyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpj b25maWd1cmU6NjQ4NjogY2hlY2tpbmcgZm9yIFhPcGVuRGlzcGxheSBpbiAt bFgxMQ0KY29uZmlndXJlOjY1MDI6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMg LVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlw ZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9p bmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAtbFgx MSAgICAgIC1sU00gLWxJQ0UgLWxtICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNy L2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjY1NzA6IGNoZWNraW5nIGZv ciBYU2hhcGVTZWxlY3RJbnB1dCBpbiAtbFhleHQNCmNvbmZpZ3VyZTo2NTg2 OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1X aW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1j b21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9Y MTEvbGliICBjb25mdGVzdC5jICAgLWxYZXh0ICAgLWxYMTEgICAtbFNNIC1s SUNFIC1sbSAgICAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+ JjUNCmNvbmZpZ3VyZTo2NjA5OiBjaGVja2luZyBmb3IgWHRPcGVuRGlzcGxh eSBpbiAtbFh0DQpjb25maWd1cmU6NjYyNTogZ2NjIC1vIGNvbmZ0ZXN0IC1n IC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJv dG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3Iv WDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAg IC1sWHQgICAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbGdj YyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCmNvbmZpZ3VyZTo2 NjQ4OiBjaGVja2luZyB0aGUgdmVyc2lvbiBvZiBYMTEgYmVpbmcgdXNlZA0K Y29uZmlndXJlOjY2NTU6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwg LVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdz aGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRl ICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYdCAtbFhl eHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbGdjYyAtbGMgLWxnY2Mg L3Vzci9saWIvY3J0bi5vIDE+JjUNCmNvbmZpZ3VyZTo2Njg2OiBjaGVja2lu ZyBmb3IgWENvbnZlcnRDYXNlDQpjb25maWd1cmU6NjcxMjogZ2NjIC1vIGNv bmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21p c3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAg ICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29u ZnRlc3QuYyAgICAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxt ICAgIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29u ZmlndXJlOjY3NDQ6IGNoZWNraW5nIGZvciBYMTEvWGxvY2FsZS5oDQpjb25m aWd1cmU6Njc1MjogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBj b25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3Vy ZTo2Nzg1OiBjaGVja2luZyBmb3IgWFJlZ2lzdGVySU1JbnN0YW50aWF0ZUNh bGxiYWNrDQpjb25maWd1cmU6NjgxMTogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1P MyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDEx L2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAt bFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sZ2NjIC1s YyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjY4Mzk6 IGNoZWNraW5nIGZvciBzdGFuZGFyZCBYUmVnaXN0ZXJJTUluc3RhbnRpYXRl Q2FsbGJhY2sgcHJvdG90eXBlDQpjb25maWd1cmU6Njg1MzogZ2NjIC1jIC1n IC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJv dG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3Iv WDExL2luY2x1ZGUgY29uZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6Njg0Njog Y29uZmxpY3RpbmcgdHlwZXMgZm9yIGBYUmVnaXN0ZXJJTUluc3RhbnRpYXRl Q2FsbGJhY2snDQovdXNyL1gxMS9pbmNsdWRlL1gxMS9YbGliLmg6NDc1MTog cHJldmlvdXMgZGVjbGFyYXRpb24gb2YgYFhSZWdpc3RlcklNSW5zdGFudGlh dGVDYWxsYmFjaycNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0K I2xpbmUgNjg0MSAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgi DQoNCiNkZWZpbmUgTmVlZEZ1bmN0aW9uUHJvdG90eXBlcyAxDQojaW5jbHVk ZSA8WDExL1hsaWIuaD4NCmV4dGVybiBCb29sIFhSZWdpc3RlcklNSW5zdGFu dGlhdGVDYWxsYmFjaygNCiAgIERpc3BsYXkqLCBzdHJ1Y3QgX1hybUhhc2hC dWNrZXRSZWMqLCBjaGFyKiwgY2hhciosIFhJTVByb2MsIFhQb2ludGVyKik7 DQoNCmludCBtYWluKCkgew0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6 Njg3NDogY2hlY2tpbmcgZm9yIFhtdVJlYWRCaXRtYXBEYXRhRnJvbUZpbGUg aW4gLWxYbXUNCmNvbmZpZ3VyZTo2ODkwOiBnY2MgLW8gY29uZnRlc3QgLWcg LU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90 b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9Y MTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAg LWxYbXUgICAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAg IC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmln dXJlOjY5Mjk6IGNoZWNraW5nIGZvciBtYWluIGluIC1sWGJzZA0KY29uZmln dXJlOjY5NDE6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1z d2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cg LVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAg LUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAtbFhic2QgICAtbFhtdSAt bFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sZ2NjIC1s YyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2Ut bGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbFhic2QNCmNvbGxlY3QyOiBs ZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBw cm9ncmFtIHdhczoNCiNsaW5lIDY5MzQgImNvbmZpZ3VyZSINCiNpbmNsdWRl ICJjb25mZGVmcy5oIg0KDQppbnQgbWFpbigpIHsNCm1haW4oKQ0KOyByZXR1 cm4gMDsgfQ0KY29uZmlndXJlOjY5Nzg6IGNoZWNraW5nIGZvciBNUy1XaW5k b3dzDQpjb25maWd1cmU6Njk4MTogY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxn ZGkzMg0KY29uZmlndXJlOjY5OTM6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMg LVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlw ZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9p bmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAtbGdk aTMyICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1s bSAgICAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCmNv bmZpZ3VyZTo3MDcxOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1X bm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hh ZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAg ICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQg LWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1s Z2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bv b2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNy L2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bv b2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25m aWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDcwNjYgImNvbmZp Z3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUgPGZjbnRs Lmg+DQogICAgaW50IG1haW4oKSB7IHJldHVybiAob3BlbigiL2Rldi93aW5k b3dzIiwgT19SRE9OTFksIDApID4gMCk/IDAgOiAxOyB9DQpjb25maWd1cmU6 NzEzNTogY2hlY2tpbmcgZm9yIFgxMS9leHRlbnNpb25zL3NoYXBlLmgNCmNv bmZpZ3VyZTo3MTQzOiBnY2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRl IGNvbmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmln dXJlOjcxOTU6IGNoZWNraW5nIGZvciBXTV9DT01NQU5EIG9wdGlvbg0KY29u ZmlndXJlOjcyMTA6IGNoZWNraW5nIGZvciBYMTEvWGF1dGguaA0KY29uZmln dXJlOjcyMTg6IGdjYyAtRSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgY29u ZnRlc3QuYyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpjb25maWd1cmU6 NzI0MTogY2hlY2tpbmcgZm9yIFhhdUdldEF1dGhCeUFkZHIgaW4gLWxYYXUN CmNvbmZpZ3VyZTo3MjU3OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxs IC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X c2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVk ZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgLWxYYXUgICAt bFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1s c2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwz MiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8g MT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmlu ZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0 YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSA3 MjQ2ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIE92 ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdo dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRp biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8NCmNoYXIgWGF1R2V0QXV0aEJ5QWRkcigpOw0KDQppbnQg bWFpbigpIHsNClhhdUdldEF1dGhCeUFkZHIoKQ0KOyByZXR1cm4gMDsgfQ0K Y29uZmlndXJlOjczMDI6IGNoZWNraW5nIGZvciB0dF9jLmgNCmNvbmZpZ3Vy ZTo3MzEwOiBnY2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0 ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJlOjcz MDY6IHR0X2MuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KY29uZmln dXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSA3MzA1ICJjb25maWd1 cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCiNpbmNsdWRlIDx0dF9jLmg+ DQpjb25maWd1cmU6NzMwMjogY2hlY2tpbmcgZm9yIFR0L3R0X2MuaA0KY29u ZmlndXJlOjczMTA6IGdjYyAtRSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUg Y29uZnRlc3QuYyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpjb25maWd1 cmU6NzMwNjogVHQvdHRfYy5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5 DQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDczMDUg ImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUg PFR0L3R0X2MuaD4NCmNvbmZpZ3VyZTo3MzAyOiBjaGVja2luZyBmb3IgZGVz a3RvcC90dF9jLmgNCmNvbmZpZ3VyZTo3MzEwOiBnY2MgLUUgICAgICAgLUkv dXNyL1gxMS9pbmNsdWRlIGNvbmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0 ZXN0Lm91dA0KY29uZmlndXJlOjczMDY6IGRlc2t0b3AvdHRfYy5oOiBObyBz dWNoIGZpbGUgb3IgZGlyZWN0b3J5DQpjb25maWd1cmU6IGZhaWxlZCBwcm9n cmFtIHdhczoNCiNsaW5lIDczMDUgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJj b25mZGVmcy5oIg0KI2luY2x1ZGUgPGRlc2t0b3AvdHRfYy5oPg0KY29uZmln dXJlOjc0MTk6IGNoZWNraW5nIGZvciBEdC9EdC5oDQpjb25maWd1cmU6NzQy NzogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVzdC5j ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZTo3NDIzOiBE dC9EdC5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5DQpjb25maWd1cmU6 IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDc0MjIgImNvbmZpZ3VyZSIN CiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUgPER0L0R0Lmg+DQpj b25maWd1cmU6NzU1OTogY2hlY2tpbmcgZm9yIExEQVANCmNvbmZpZ3VyZTo3 NTYyOiBjaGVja2luZyBmb3IgbGRhcC5oDQpjb25maWd1cmU6NzU3MDogZ2Nj IC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVzdC5jID4vZGV2 L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZTo3NTY2OiBsZGFwLmg6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCmNvbmZpZ3VyZTogZmFpbGVk IHByb2dyYW0gd2FzOg0KI2xpbmUgNzU2NSAiY29uZmlndXJlIg0KI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVkZSA8bGRhcC5oPg0KY29uZmlndXJl Ojc4NzI6IGNoZWNraW5nIGZvciBQb3N0Z3JlU1FMDQpjb25maWd1cmU6Nzg3 NzogY2hlY2tpbmcgZm9yIGxpYnBxLWZlLmgNCmNvbmZpZ3VyZTo3ODg1OiBn Y2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0ZXN0LmMgPi9k ZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJlOjc4ODE6IGxpYnBx LWZlLmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCmNvbmZpZ3VyZTog ZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgNzg4MCAiY29uZmlndXJlIg0K I2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVkZSA8bGlicHEtZmUuaD4N CmNvbmZpZ3VyZTo3ODc3OiBjaGVja2luZyBmb3IgcGdzcWwvbGlicHEtZmUu aA0KY29uZmlndXJlOjc4ODU6IGdjYyAtRSAgICAgICAtSS91c3IvWDExL2lu Y2x1ZGUgY29uZnRlc3QuYyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpj b25maWd1cmU6Nzg4MTogcGdzcWwvbGlicHEtZmUuaDogTm8gc3VjaCBmaWxl IG9yIGRpcmVjdG9yeQ0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6 DQojbGluZSA3ODgwICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMu aCINCiNpbmNsdWRlIDxwZ3NxbC9saWJwcS1mZS5oPg0KY29uZmlndXJlOjc4 Nzc6IGNoZWNraW5nIGZvciBwb3N0Z3Jlc3FsL2xpYnBxLWZlLmgNCmNvbmZp Z3VyZTo3ODg1OiBnY2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNv bmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJl Ojc4ODE6IHBvc3RncmVzcWwvbGlicHEtZmUuaDogTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeQ0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQoj bGluZSA3ODgwICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCIN CiNpbmNsdWRlIDxwb3N0Z3Jlc3FsL2xpYnBxLWZlLmg+DQpjb25maWd1cmU6 ODAyMjogY2hlY2tpbmcgZm9yIGdyYXBoaWNzIGxpYnJhcmllcw0KY29uZmln dXJlOjgwMjc6IGNoZWNraW5nIGZvciBYcG0gLSBubyBvbGRlciB0aGFuIDMu NGYNCmNvbmZpZ3VyZTo4MDM5OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1X YWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVz IC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5j bHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAtbFhwbSAg LWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAt bHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3Rs MzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5v IDE+JjUNCmNvbmZpZ3VyZTogSW4gZnVuY3Rpb24gYG1haW4nOg0KY29uZmln dXJlOjgwMzU6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1 bmN0aW9uIGBYcG1MaWJyYXJ5VmVyc2lvbicNCi91c3IvaTQ4Ni1zdXNlLWxp bnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6 IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVk IHByb2dyYW0gd2FzOg0KI2xpbmUgODAzMCAiY29uZmlndXJlIg0KI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQojZGVmaW5lIFhQTV9OVU1CRVJTDQojaW5jbHVk ZSA8WDExL3hwbS5oPg0KICAgIGludCBtYWluKGludCBjLCBjaGFyICoqdikg ew0KICAgIHJldHVybiBjID09IDEgPyAwIDoNCiAgICAgIFhwbUluY2x1ZGVW ZXJzaW9uICE9IFhwbUxpYnJhcnlWZXJzaW9uKCkgPyAxIDoNCiAgICAgIFhw bUluY2x1ZGVWZXJzaW9uIDwgMzA0MDYgPyAyIDogMCA7fQ0KY29uZmlndXJl OjgxMTc6IGNoZWNraW5nIGZvciBjb21wZmFjZS5oDQpjb25maWd1cmU6ODEy NTogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVzdC5j ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZTo4MTIxOiBj b21wZmFjZS5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5DQpjb25maWd1 cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDgxMjAgImNvbmZpZ3Vy ZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUgPGNvbXBmYWNl Lmg+DQpjb25maWd1cmU6ODIxNjogY2hlY2tpbmcgZm9yIGluZmxhdGUgaW4g LWxjDQpjb25maWd1cmU6ODIzMjogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAt V2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBl cyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2lu Y2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgIC1sYyAg IC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAg LWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0 bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4u byAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBm aW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQg c3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5l IDgyMjEgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyog T3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk IGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1p Z2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWls dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp bGwgYXBwbHkuICAqLw0KY2hhciBpbmZsYXRlKCk7DQoNCmludCBtYWluKCkg ew0KaW5mbGF0ZSgpDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6ODI1MTog Y2hlY2tpbmcgZm9yIGluZmxhdGUgaW4gLWx6DQpjb25maWd1cmU6ODI2Nzog Z2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lu bGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29t cGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDEx L2xpYiAgY29uZnRlc3QuYyAgIC1seiAgIC1sWG11IC1sWHQgLWxYZXh0IC1s WDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1 c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2Mg LWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3Vz ZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxl Y3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZh aWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDgyNTYgImNvbmZpZ3VyZSINCiNp bmNsdWRlICJjb25mZGVmcy5oIg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50 ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdl IHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4g dHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1 bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBp bmZsYXRlKCk7DQoNCmludCBtYWluKCkgew0KaW5mbGF0ZSgpDQo7IHJldHVy biAwOyB9DQpjb25maWd1cmU6ODI4NjogY2hlY2tpbmcgZm9yIGluZmxhdGUg aW4gLWxneg0KY29uZmlndXJlOjgzMDI6IGdjYyAtbyBjb25mdGVzdCAtZyAt TzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3Rv dHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gx MS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAt bGd6ICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1s bSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1s Y29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIv Y3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fu bm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEg ZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0K I2xpbmUgODI5MSAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgi DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8g YXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBp bnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAg IGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3Vs ZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGluZmxhdGUoKTsNCg0KaW50IG1h aW4oKSB7DQppbmZsYXRlKCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZTo4 MzMyOiBjaGVja2luZyBmb3IganBlZ2xpYi5oDQpjb25maWd1cmU6ODM0MDog Z2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVzdC5jID4v ZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZTo4MzYzOiBjaGVj a2luZyBmb3IganBlZ19kZXN0cm95X2RlY29tcHJlc3MgaW4gLWxqcGVnDQpj b25maWd1cmU6ODM3OTogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAt V25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3No YWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUg ICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgIC1sanBlZyAgIC1s WG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxz aGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMy IC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAx PiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5k IC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3Rh dHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDgz NjggImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogT3Zl cnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu IGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg YXBwbHkuICAqLw0KY2hhciBqcGVnX2Rlc3Ryb3lfZGVjb21wcmVzcygpOw0K DQppbnQgbWFpbigpIHsNCmpwZWdfZGVzdHJveV9kZWNvbXByZXNzKCkNCjsg cmV0dXJuIDA7IH0NCmNvbmZpZ3VyZTo4NDE1OiBjaGVja2luZyBmb3IgcG93 DQpjb25maWd1cmU6ODQ0MTogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2Fs bCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAt V3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1 ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAt bFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwz MiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdp bnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0K L3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdp bnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0K Y29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSA4NDE4ICJj b25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBo ZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBm ZXcgcHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBj aGFyIHBvdygpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQov KiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv aWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQg bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz dGlsbCBhcHBseS4gICovDQpjaGFyIHBvdygpOw0KDQppbnQgbWFpbigpIHsN Cg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5j dGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWls IHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5h bWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBu b3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19z dHViX3BvdykgfHwgZGVmaW5lZCAoX19zdHViX19fcG93KQ0KY2hva2UgbWUN CiNlbHNlDQpwb3coKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25m aWd1cmU6ODU4NjogY2hlY2tpbmcgZm9yIHRpZmZpby5oDQpjb25maWd1cmU6 ODU5NDogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVz dC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZTo4NjE3 OiBjaGVja2luZyBmb3IgVElGRkNsaWVudE9wZW4gaW4gLWx0aWZmDQpjb25m aWd1cmU6ODYzMzogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25v LXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRv dyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAg ICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgIC1sdGlmZiAgIC1sWG11 IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVs bDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1s d2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1 DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1s d2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVz DQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDg2MjIg ImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogT3ZlcnJp ZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy cm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1h dGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFu ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw bHkuICAqLw0KY2hhciBUSUZGQ2xpZW50T3BlbigpOw0KDQppbnQgbWFpbigp IHsNClRJRkZDbGllbnRPcGVuKCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZTo4NzU5OiBjaGVja2luZyBmb3IgWDExIGdyYXBoaWNzIGxpYnJhcmllcw0K Y29uZmlndXJlOjg3NjI6IGNoZWNraW5nIGZvciB0aGUgQXRoZW5hIHdpZGdl dHMNCmNvbmZpZ3VyZTo4Nzc2OiBjaGVja2luZyBmb3IgWGF3U2Nyb2xsYmFy U2V0VGh1bWIgaW4gLWxYYXcNCmNvbmZpZ3VyZTo4NzkyOiBnY2MgLW8gY29u ZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlz c2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAg IC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25m dGVzdC5jICAgLWxYYXcgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1s U00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1s Y29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdj YyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgv YmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQg cmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJv Z3JhbSB3YXM6DQojbGluZSA4NzgxICJjb25maWd1cmUiDQojaW5jbHVkZSAi Y29uZmRlZnMuaCINCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHBy b3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hh ciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg YSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJv dG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgWGF3U2Nyb2xs YmFyU2V0VGh1bWIoKTsNCg0KaW50IG1haW4oKSB7DQpYYXdTY3JvbGxiYXJT ZXRUaHVtYigpDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6ODkzNjogY2hl Y2tpbmcgZm9yIFgxMS9YYXcvVGhyZWVELmgNCmNvbmZpZ3VyZTo4OTQ0OiBn Y2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0ZXN0LmMgPi9k ZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJlOjg5NDA6IFgxMS9Y YXcvVGhyZWVELmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCmNvbmZp Z3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgODkzOSAiY29uZmln dXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVkZSA8WDExL1hh dy9UaHJlZUQuaD4NCmNvbmZpZ3VyZTo4OTY0OiBjaGVja2luZyBmb3IgWDEx L1hhdy9YYXdJbml0LmgNCmNvbmZpZ3VyZTo4OTcyOiBnY2MgLUUgICAgICAg LUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0ZXN0LmMgPi9kZXYvbnVsbCAyPmNv bmZ0ZXN0Lm91dA0KY29uZmlndXJlOjkyOTQ6IGNoZWNraW5nIGZvciBYbS9Y bS5oDQpjb25maWd1cmU6OTMwMjogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEv aW5jbHVkZSBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQN CmNvbmZpZ3VyZTo5Mjk4OiBYbS9YbS5oOiBObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5DQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5l IDkyOTcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2lu Y2x1ZGUgPFhtL1htLmg+DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZv ciBjYnJ0DQpjb25maWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAt TzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3Rv dHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gx MS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAg LWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAt bHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3Rs MzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5v IDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZp bmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBz dGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUg MTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyog U3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9w ZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGlj dCB3aXRoIGNoYXIgY2JydCgpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNz ZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5 cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2Nj Mg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGNicnQoKTsNCg0KaW50 IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhp cyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBh bHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBh Y3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9f IGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRl ZmluZWQgKF9fc3R1Yl9jYnJ0KSB8fCBkZWZpbmVkIChfX3N0dWJfX19jYnJ0 KQ0KY2hva2UgbWUNCiNlbHNlDQpjYnJ0KCk7DQojZW5kaWYNCg0KOyByZXR1 cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBjaGVja2luZyBmb3IgY2xvc2Vk aXINCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAt V2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBl cyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2lu Y2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFht dSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hl bGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAt bHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4m NQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAt bHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1 cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4 NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0 ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVs bHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdp dGggY2hhciBjbG9zZWRpcigpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNz ZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5 cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2Nj Mg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGNsb3NlZGlyKCk7DQoN CmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVz IHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQogICAg dG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9ucyBh cmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0 aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNp ZiBkZWZpbmVkIChfX3N0dWJfY2xvc2VkaXIpIHx8IGRlZmluZWQgKF9fc3R1 Yl9fX2Nsb3NlZGlyKQ0KY2hva2UgbWUNCiNlbHNlDQpjbG9zZWRpcigpOw0K I2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMDc4NDogY2hl Y2tpbmcgZm9yIGR1cDINCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0 ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3Np bmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAt SS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRl c3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0Ug LWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIg LWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xp Yi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBj YW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQg MSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6 DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZz LmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9z IGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2Fu IGNvbmZsaWN0IHdpdGggY2hhciBkdXAyKCk7IGJlbG93LiAgKi8NCiNpbmNs dWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFs IHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2Ug Y2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUg b2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQg cHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgZHVwMigp Ow0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVm aW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0K ICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlv bnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5n IHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICov DQojaWYgZGVmaW5lZCAoX19zdHViX2R1cDIpIHx8IGRlZmluZWQgKF9fc3R1 Yl9fX2R1cDIpDQpjaG9rZSBtZQ0KI2Vsc2UNCmR1cDIoKTsNCiNlbmRpZg0K DQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZv ciBlYWNjZXNzDQpjb25maWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAt ZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXBy b3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNy L1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMg ICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAg ICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29t Y3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0 bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90 IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhp dCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xp bmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0K LyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQg aG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25m bGljdCB3aXRoIGNoYXIgZWFjY2VzcygpOyBiZWxvdy4gICovDQojaW5jbHVk ZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBw cm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNo YXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9m IGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHBy b3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGVhY2Nlc3Mo KTsNCg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRl ZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMN CiAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rp b25zIGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGlu ZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAq Lw0KI2lmIGRlZmluZWQgKF9fc3R1Yl9lYWNjZXNzKSB8fCBkZWZpbmVkIChf X3N0dWJfX19lYWNjZXNzKQ0KY2hva2UgbWUNCiNlbHNlDQplYWNjZXNzKCk7 DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBj aGVja2luZyBmb3IgZm1vZA0KY29uZmlndXJlOjEwODEwOiBnY2MgLW8gY29u ZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlz c2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAg IC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25m dGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElD RSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGcz MiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3Iv bGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6 IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5l ZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdh czoNCiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRl ZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNy b3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3aGljaCBj YW4gY29uZmxpY3Qgd2l0aCBjaGFyIGZtb2QoKTsgYmVsb3cuICAqLw0KI2lu Y2x1ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJu YWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVz ZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw ZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBmbW9k KCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGlicmFyeSBk ZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRz DQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0 aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcgc3RhcnRp bmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAg Ki8NCiNpZiBkZWZpbmVkIChfX3N0dWJfZm1vZCkgfHwgZGVmaW5lZCAoX19z dHViX19fZm1vZCkNCmNob2tlIG1lDQojZWxzZQ0KZm1vZCgpOw0KI2VuZGlm DQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMDc4NDogY2hlY2tpbmcg Zm9yIGZwYXRoY29uZg0KY29uZmlndXJlOjEwODEwOiBnY2MgLW8gY29uZnRl c3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1J L3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVz dC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAt bG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAt bGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGli L2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNh bm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAx IGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoN CiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMu aCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3Mg YW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4g Y29uZmxpY3Qgd2l0aCBjaGFyIGZwYXRoY29uZigpOyBiZWxvdy4gICovDQoj aW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRl cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2Ug dXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0 eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGZw YXRoY29uZigpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxp YnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1w bGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29t ZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5n IHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBh bGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX2ZwYXRoY29uZikgfHwg ZGVmaW5lZCAoX19zdHViX19fZnBhdGhjb25mKQ0KY2hva2UgbWUNCiNlbHNl DQpmcGF0aGNvbmYoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25m aWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBmcmV4cA0KY29uZmlndXJlOjEw ODEwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNo IC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2ln bi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vz ci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1s WDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1 c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2Mg LWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3Vz ZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxl Y3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZh aWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQoj aW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVm aW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBl cywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIGZyZXhwKCk7 IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRl IGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv ci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQg dGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8NCmNoYXIgZnJleHAoKTsNCg0KaW50IG1haW4oKSB7DQoNCi8qIFRo ZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdo aWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVO T1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZA0KICAg IHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5h bWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1Yl9mcmV4 cCkgfHwgZGVmaW5lZCAoX19zdHViX19fZnJleHApDQpjaG9rZSBtZQ0KI2Vs c2UNCmZyZXhwKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmln dXJlOjEwNzg0OiBjaGVja2luZyBmb3IgZnRpbWUNCmNvbmZpZ3VyZToxMDgx MDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAt V2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24t Y29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3Iv WDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgx MSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNl cjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1s YyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2Ut bGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0 MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWls ZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2lu Y2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmlu ZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMs DQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBmdGltZSgpOyBi ZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBh bnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu ICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg dGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRo ZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4g ICovDQpjaGFyIGZ0aW1lKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUg R05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGlj aCBpdCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9T WVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBz b21ldGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1l IGlzIGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfZnRpbWUp IHx8IGRlZmluZWQgKF9fc3R1Yl9fX2Z0aW1lKQ0KY2hva2UgbWUNCiNlbHNl DQpmdGltZSgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZToxMDc4NDogY2hlY2tpbmcgZm9yIGdldGFkZHJpbmZvDQpjb25maWd1cmU6 MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0 Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdz aWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwv dXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQg LWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAt bHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdj YyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1z dXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29s bGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTog ZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSIN CiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBk ZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5 cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgZ2V0YWRk cmluZm8oKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyog T3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk IGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1p Z2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWls dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp bGwgYXBwbHkuICAqLw0KY2hhciBnZXRhZGRyaW5mbygpOw0KDQppbnQgbWFp bigpIHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZv ciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5 cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVh bGx5IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5k IHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5l ZCAoX19zdHViX2dldGFkZHJpbmZvKSB8fCBkZWZpbmVkIChfX3N0dWJfX19n ZXRhZGRyaW5mbykNCmNob2tlIG1lDQojZWxzZQ0KZ2V0YWRkcmluZm8oKTsN CiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNo ZWNraW5nIGZvciBnZXRob3N0bmFtZQ0KY29uZmlndXJlOjEwODEwOiBnY2Mg LW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5l IC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJl ICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGli ICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxT TSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxj b21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2Nj IC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9i aW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCBy ZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9n cmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQojaW5jbHVkZSAi Y29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1 YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3 aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIGdldGhvc3RuYW1lKCk7IGJl bG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFu eSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4g ICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0 aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhl biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg Ki8NCmNoYXIgZ2V0aG9zdG5hbWUoKTsNCg0KaW50IG1haW4oKSB7DQoNCi8q IFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25z IHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3aXRo IEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZA0K ICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFs IG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1Yl9n ZXRob3N0bmFtZSkgfHwgZGVmaW5lZCAoX19zdHViX19fZ2V0aG9zdG5hbWUp DQpjaG9rZSBtZQ0KI2Vsc2UNCmdldGhvc3RuYW1lKCk7DQojZW5kaWYNCg0K OyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBjaGVja2luZyBmb3Ig Z2V0bmFtZWluZm8NCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0 IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3Npbmct cHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91 c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3Qu YyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxt ICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxj b21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9j cnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5u b3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBl eGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQoj bGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgi DQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFu ZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNv bmZsaWN0IHdpdGggY2hhciBnZXRuYW1laW5mbygpOyBiZWxvdy4gICovDQoj aW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRl cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2Ug dXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0 eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGdl dG5hbWVpbmZvKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMg bGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBp bXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBT b21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhp bmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFu IGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfZ2V0bmFtZWluZm8p IHx8IGRlZmluZWQgKF9fc3R1Yl9fX2dldG5hbWVpbmZvKQ0KY2hva2UgbWUN CiNlbHNlDQpnZXRuYW1laW5mbygpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7 IH0NCmNvbmZpZ3VyZToxMDc4NDogY2hlY2tpbmcgZm9yIGdldHBhZ2VzaXpl DQpjb25maWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdh bGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMg LVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNs dWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUg LWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxs MzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3 aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUN Ci91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3 aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMN CmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcg ImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVt IGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5 IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRo IGNoYXIgZ2V0cGFnZXNpemUoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFz c2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90 eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJl Y2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdj YzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5 cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBnZXRwYWdlc2l6ZSgp Ow0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVm aW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0K ICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlv bnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5n IHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICov DQojaWYgZGVmaW5lZCAoX19zdHViX2dldHBhZ2VzaXplKSB8fCBkZWZpbmVk IChfX3N0dWJfX19nZXRwYWdlc2l6ZSkNCmNob2tlIG1lDQojZWxzZQ0KZ2V0 cGFnZXNpemUoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1 cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBnZXR0aW1lb2ZkYXkNCmNvbmZpZ3Vy ZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAt TC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4 dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMy IC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1s Z2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2 LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpj b2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJl OiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJl Ig0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRv IGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3Rv dHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBnZXR0 aW1lb2ZkYXkoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0K LyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2 b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50 IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBi dWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQg c3RpbGwgYXBwbHkuICAqLw0KY2hhciBnZXR0aW1lb2ZkYXkoKTsNCg0KaW50 IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhp cyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBh bHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBh Y3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9f IGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRl ZmluZWQgKF9fc3R1Yl9nZXR0aW1lb2ZkYXkpIHx8IGRlZmluZWQgKF9fc3R1 Yl9fX2dldHRpbWVvZmRheSkNCmNob2tlIG1lDQojZWxzZQ0KZ2V0dGltZW9m ZGF5KCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEw Nzg0OiBjaGVja2luZyBmb3IgZ2V0Y3dkDQpjb25maWd1cmU6MTA4MTA6IGdj YyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxp bmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBh cmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9s aWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAt bFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAt bGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxn Y2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4 L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxk IHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHBy b2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRl ICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19z dHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgZ2V0Y3dkKCk7IGJlbG93 LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFueSBn Y2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICov DQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUg cmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBp dHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8N CmNoYXIgZ2V0Y3dkKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05V IEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBp dCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMu ICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21l dGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlz IGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfZ2V0Y3dkKSB8 fCBkZWZpbmVkIChfX3N0dWJfX19nZXRjd2QpDQpjaG9rZSBtZQ0KI2Vsc2UN CmdldGN3ZCgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZToxMDc4NDogY2hlY2tpbmcgZm9yIGdldHdkDQpjb25maWd1cmU6MTA4MTA6 IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdp bmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNv bXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gx MS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEg ICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIz MiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMg LWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxp bnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6 IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVk IHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNs dWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUg X19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0K ICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgZ2V0d2QoKTsgYmVs b3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55 IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAg Ki8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo ZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVu IGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq Lw0KY2hhciBnZXR3ZCgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdO VSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2gg aXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lT LiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29t ZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBp cyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX2dldHdkKSB8 fCBkZWZpbmVkIChfX3N0dWJfX19nZXR3ZCkNCmNob2tlIG1lDQojZWxzZQ0K Z2V0d2QoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6 MTA3ODQ6IGNoZWNraW5nIGZvciBsb2diDQpjb25maWd1cmU6MTA4MTA6IGdj YyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxp bmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBh cmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9s aWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAt bFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAt bGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxn Y2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4 L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxk IHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHBy b2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRl ICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19z dHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgbG9nYigpOyBiZWxvdy4g ICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2Nj MiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0K LyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJl dHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRz IGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpj aGFyIGxvZ2IoKTsNCg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBs aWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGlt cGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNv bWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGlu ZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4g YWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1Yl9sb2diKSB8fCBkZWZp bmVkIChfX3N0dWJfX19sb2diKQ0KY2hva2UgbWUNCiNlbHNlDQpsb2diKCk7 DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBj aGVja2luZyBmb3IgbHJhbmQ0OA0KY29uZmlndXJlOjEwODEwOiBnY2MgLW8g Y29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1X bWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAg ICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBj b25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAt bElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21k bGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91 c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4v bGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1 cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFt IHdhczoNCiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29u ZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBt YWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3aGlj aCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIGxyYW5kNDgoKTsgYmVsb3cuICAq Lw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIg aW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8q IFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1 cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBh cmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hh ciBscmFuZDQ4KCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMg bGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBp bXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBT b21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhp bmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFu IGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfbHJhbmQ0OCkgfHwg ZGVmaW5lZCAoX19zdHViX19fbHJhbmQ0OCkNCmNob2tlIG1lDQojZWxzZQ0K bHJhbmQ0OCgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZToxMDc4NDogY2hlY2tpbmcgZm9yIG1hdGhlcnINCmNvbmZpZ3VyZToxMDgx MDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAt V2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24t Y29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3Iv WDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgx MSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNl cjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1s YyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2Ut bGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0 MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWls ZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2lu Y2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmlu ZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMs DQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBtYXRoZXJyKCk7 IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRl IGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv ci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQg dGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8NCmNoYXIgbWF0aGVycigpOw0KDQppbnQgbWFpbigpIHsNCg0KLyog VGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMg d2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGgg RU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQog ICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwg bmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX21h dGhlcnIpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX21hdGhlcnIpDQpjaG9rZSBt ZQ0KI2Vsc2UNCm1hdGhlcnIoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9 DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBta2Rpcg0KY29uZmln dXJlOjEwODEwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8t c3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93 IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAg IC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxY ZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2Rp MzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wg LWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0 ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wN CmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1 cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25maWd1 cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIg dG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJv dG90eXBlcywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIG1r ZGlyKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92 ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdo dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRp biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8NCmNoYXIgbWtkaXIoKTsNCg0KaW50IG1haW4oKSB7DQoN Ci8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rp b25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3 aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1l ZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9y bWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1 Yl9ta2RpcikgfHwgZGVmaW5lZCAoX19zdHViX19fbWtkaXIpDQpjaG9rZSBt ZQ0KI2Vsc2UNCm1rZGlyKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0K Y29uZmlndXJlOjEwNzg0OiBjaGVja2luZyBmb3IgbWt0aW1lDQpjb25maWd1 cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1z d2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cg LVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAg LUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhl eHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkz MiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAt bGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4 Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0K Y29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3Vy ZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3Vy ZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0 byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90 b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgbWt0 aW1lKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92 ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdo dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRp biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8NCmNoYXIgbWt0aW1lKCk7DQoNCmludCBtYWluKCkgew0K DQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0 aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwg d2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFt ZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5v cm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0 dWJfbWt0aW1lKSB8fCBkZWZpbmVkIChfX3N0dWJfX19ta3RpbWUpDQpjaG9r ZSBtZQ0KI2Vsc2UNCm1rdGltZSgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7 IH0NCmNvbmZpZ3VyZToxMDc4NDogY2hlY2tpbmcgZm9yIHBlcnJvcg0KY29u ZmlndXJlOjEwODEwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1X bm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hh ZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAg ICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQg LWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1s Z2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bv b2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNy L2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bv b2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25m aWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25m aWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFk ZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcg cHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFy IHBlcnJvcigpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQov KiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv aWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQg bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz dGlsbCBhcHBseS4gICovDQpjaGFyIHBlcnJvcigpOw0KDQppbnQgbWFpbigp IHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBm dW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBm YWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5 IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRo ZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAo X19zdHViX3BlcnJvcikgfHwgZGVmaW5lZCAoX19zdHViX19fcGVycm9yKQ0K Y2hva2UgbWUNCiNlbHNlDQpwZXJyb3IoKTsNCiNlbmRpZg0KDQo7IHJldHVy biAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBwb2xsDQpj b25maWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwg LVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdz aGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRl ICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxY dCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIg LWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5z cG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91 c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5z cG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNv bmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNv bmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhl YWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZl dyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNo YXIgcG9sbCgpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQov KiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv aWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQg bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz dGlsbCBhcHBseS4gICovDQpjaGFyIHBvbGwoKTsNCg0KaW50IG1haW4oKSB7 DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVu Y3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFp bCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBu YW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUg bm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9f c3R1Yl9wb2xsKSB8fCBkZWZpbmVkIChfX3N0dWJfX19wb2xsKQ0KY2hva2Ug bWUNCiNlbHNlDQpwb2xsKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0K Y29uZmlndXJlOjEwNzg0OiBjaGVja2luZyBmb3IgcmFuZG9tDQpjb25maWd1 cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1z d2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cg LVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAg LUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhl eHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkz MiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAt bGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4 Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0K Y29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3Vy ZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3Vy ZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0 byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90 b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgcmFu ZG9tKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92 ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdo dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRp biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8NCmNoYXIgcmFuZG9tKCk7DQoNCmludCBtYWluKCkgew0K DQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0 aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwg d2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFt ZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5v cm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0 dWJfcmFuZG9tKSB8fCBkZWZpbmVkIChfX3N0dWJfX19yYW5kb20pDQpjaG9r ZSBtZQ0KI2Vsc2UNCnJhbmRvbSgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7 IH0NCmNvbmZpZ3VyZToxMDc4NDogY2hlY2tpbmcgZm9yIHJlbmFtZQ0KY29u ZmlndXJlOjEwODEwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1X bm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hh ZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAg ICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQg LWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1s Z2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bv b2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNy L2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bv b2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25m aWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25m aWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFk ZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcg cHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFy IHJlbmFtZSgpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQov KiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv aWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQg bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz dGlsbCBhcHBseS4gICovDQpjaGFyIHJlbmFtZSgpOw0KDQppbnQgbWFpbigp IHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBm dW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBm YWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5 IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRo ZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAo X19zdHViX3JlbmFtZSkgfHwgZGVmaW5lZCAoX19zdHViX19fcmVuYW1lKQ0K Y2hva2UgbWUNCiNlbHNlDQpyZW5hbWUoKTsNCiNlbmRpZg0KDQo7IHJldHVy biAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciByZXNfaW5p dA0KY29uZmlndXJlOjEwODEwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1X YWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVz IC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5j bHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11 IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVs bDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1s d2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1 DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1s d2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVz DQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEwNzg3 ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3Rl bSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxs eSBmZXcgcHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0 aCBjaGFyIHJlc19pbml0KCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3Nl cnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlw ZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNh dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2My DQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBl IHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgcmVzX2luaXQoKTsNCg0K aW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMg dGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0 byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFy ZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRo IF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lm IGRlZmluZWQgKF9fc3R1Yl9yZXNfaW5pdCkgfHwgZGVmaW5lZCAoX19zdHVi X19fcmVzX2luaXQpDQpjaG9rZSBtZQ0KI2Vsc2UNCnJlc19pbml0KCk7DQoj ZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBjaGVj a2luZyBmb3IgcmludA0KY29uZmlndXJlOjEwODEwOiBnY2MgLW8gY29uZnRl c3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1J L3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVz dC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAt bG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAt bGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGli L2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNh bm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAx IGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoN CiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMu aCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3Mg YW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4g Y29uZmxpY3Qgd2l0aCBjaGFyIHJpbnQoKTsgYmVsb3cuICAqLw0KI2luY2x1 ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwg cHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBj aGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv ZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBw cm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciByaW50KCk7 DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZp bmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQog ICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9u cyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcg d2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8N CiNpZiBkZWZpbmVkIChfX3N0dWJfcmludCkgfHwgZGVmaW5lZCAoX19zdHVi X19fcmludCkNCmNob2tlIG1lDQojZWxzZQ0KcmludCgpOw0KI2VuZGlmDQoN CjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMDc4NDogY2hlY2tpbmcgZm9y IHJtZGlyDQpjb25maWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAt TzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3Rv dHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gx MS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAg LWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAt bHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3Rs MzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5v IDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZp bmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBz dGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUg MTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyog U3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9w ZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGlj dCB3aXRoIGNoYXIgcm1kaXIoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFz c2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90 eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJl Y2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdj YzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5 cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBybWRpcigpOw0KDQpp bnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0 aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRv IGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJl IGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGgg X18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYg ZGVmaW5lZCAoX19zdHViX3JtZGlyKSB8fCBkZWZpbmVkIChfX3N0dWJfX19y bWRpcikNCmNob2tlIG1lDQojZWxzZQ0Kcm1kaXIoKTsNCiNlbmRpZg0KDQo7 IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBz ZWxlY3QNCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1P MyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDEx L2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAt bFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1s c2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwz MiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8g MT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmlu ZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0 YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAx MDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBT eXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3Bl ZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0 IHdpdGggY2hhciBzZWxlY3QoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFz c2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90 eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJl Y2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdj YzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5 cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBzZWxlY3QoKTsNCg0K aW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMg dGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0 byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFy ZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRo IF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lm IGRlZmluZWQgKF9fc3R1Yl9zZWxlY3QpIHx8IGRlZmluZWQgKF9fc3R1Yl9f X3NlbGVjdCkNCmNob2tlIG1lDQojZWxzZQ0Kc2VsZWN0KCk7DQojZW5kaWYN Cg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBjaGVja2luZyBm b3Igc2V0aXRpbWVyDQpjb25maWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVz dCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5n LXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkv dXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0 LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1s bSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1s Y29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIv Y3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fu bm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEg ZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0K I2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5o Ig0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBh bmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBj b25mbGljdCB3aXRoIGNoYXIgc2V0aXRpbWVyKCk7IGJlbG93LiAgKi8NCiNp bmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVy bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1 c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5 cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1l bnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgc2V0 aXRpbWVyKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGli cmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21l IGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcg c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFs aWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfc2V0aXRpbWVyKSB8fCBk ZWZpbmVkIChfX3N0dWJfX19zZXRpdGltZXIpDQpjaG9rZSBtZQ0KI2Vsc2UN CnNldGl0aW1lcigpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZp Z3VyZToxMDc4NDogY2hlY2tpbmcgZm9yIHNldHBnaWQNCmNvbmZpZ3VyZTox MDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRj aCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3Np Z24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91 c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAt bFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1s dXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2Nj IC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1 c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xs ZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBm YWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0K I2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRl ZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlw ZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBzZXRwZ2lk KCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJy aWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl cnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBt YXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBh bmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFw cGx5LiAgKi8NCmNoYXIgc2V0cGdpZCgpOw0KDQppbnQgbWFpbigpIHsNCg0K LyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlv bnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdp dGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVk DQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3Jt YWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHVi X3NldHBnaWQpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX3NldHBnaWQpDQpjaG9r ZSBtZQ0KI2Vsc2UNCnNldHBnaWQoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAw OyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBzZXRsb2NhbGUN CmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2Fs bCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAt V3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1 ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAt bFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwz MiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdp bnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0K L3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdp bnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0K Y29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAi Y29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0g aGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkg ZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGgg Y2hhciBzZXRsb2NhbGUoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2Vy dC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBl IHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1 c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzIN CiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUg d291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBzZXRsb2NhbGUoKTsNCg0K aW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMg dGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0 byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFy ZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRo IF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lm IGRlZmluZWQgKF9fc3R1Yl9zZXRsb2NhbGUpIHx8IGRlZmluZWQgKF9fc3R1 Yl9fX3NldGxvY2FsZSkNCmNob2tlIG1lDQojZWxzZQ0Kc2V0bG9jYWxlKCk7 DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBj aGVja2luZyBmb3Igc2V0c2lkDQpjb25maWd1cmU6MTA4MTA6IGdjYyAtbyBj b25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdt aXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAg ICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNv bmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1s SUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRs ZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vz ci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9s ZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVy bmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0g d2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25m ZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1h Y3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNo IGNhbiBjb25mbGljdCB3aXRoIGNoYXIgc2V0c2lkKCk7IGJlbG93LiAgKi8N CiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGlu dGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBX ZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJu IHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJn dW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIg c2V0c2lkKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGli cmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21l IGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcg c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFs aWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfc2V0c2lkKSB8fCBkZWZp bmVkIChfX3N0dWJfX19zZXRzaWQpDQpjaG9rZSBtZQ0KI2Vsc2UNCnNldHNp ZCgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMDc4 NDogY2hlY2tpbmcgZm9yIHNpZ2Jsb2NrDQpjb25maWd1cmU6MTA4MTA6IGdj YyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxp bmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBh cmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9s aWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAt bFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAt bGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxn Y2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4 L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxk IHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHBy b2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNsdWRl ICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19z dHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgc2lnYmxvY2soKTsgYmVs b3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55 IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAg Ki8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo ZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVu IGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq Lw0KY2hhciBzaWdibG9jaygpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhl IEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hp Y2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5P U1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAg c29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFt ZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX3NpZ2Js b2NrKSB8fCBkZWZpbmVkIChfX3N0dWJfX19zaWdibG9jaykNCmNob2tlIG1l DQojZWxzZQ0Kc2lnYmxvY2soKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9 DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciBzaWdob2xkDQpjb25m aWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVdu by1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFk b3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAg ICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAt bFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxn ZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9v bCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3Iv aTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9v bA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZp Z3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZp Z3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRl ciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBw cm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIg c2lnaG9sZCgpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQov KiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZv aWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQg bWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1 aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz dGlsbCBhcHBseS4gICovDQpjaGFyIHNpZ2hvbGQoKTsNCg0KaW50IG1haW4o KSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3Ig ZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMg ZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxs eSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0 aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQg KF9fc3R1Yl9zaWdob2xkKSB8fCBkZWZpbmVkIChfX3N0dWJfX19zaWdob2xk KQ0KY2hva2UgbWUNCiNlbHNlDQpzaWdob2xkKCk7DQojZW5kaWYNCg0KOyBy ZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBjaGVja2luZyBmb3Igc2ln cHJvY21hc2sNCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1n IC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJv dG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3Iv WDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAg ICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAg IC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21j dGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRu Lm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3Qg ZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0 IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGlu ZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQov KiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBo b3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZs aWN0IHdpdGggY2hhciBzaWdwcm9jbWFzaygpOyBiZWxvdy4gICovDQojaW5j bHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5h bCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNl IGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBl IG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50 IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIHNpZ3By b2NtYXNrKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGli cmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21l IGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcg c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFs aWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfc2lncHJvY21hc2spIHx8 IGRlZmluZWQgKF9fc3R1Yl9fX3NpZ3Byb2NtYXNrKQ0KY2hva2UgbWUNCiNl bHNlDQpzaWdwcm9jbWFzaygpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0N CmNvbmZpZ3VyZToxMDc4NDogY2hlY2tpbmcgZm9yIHNucHJpbnRmDQpjb25m aWd1cmU6MTA4MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVdu by1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFk b3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAg ICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAt bFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxn ZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9v bCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3Iv aTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9v bA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZp Z3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZp Z3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRl ciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBw cm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIg c25wcmludGYoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0K LyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2 b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50 IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBi dWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQg c3RpbGwgYXBwbHkuICAqLw0KY2hhciBzbnByaW50ZigpOw0KDQppbnQgbWFp bigpIHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZv ciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5 cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVh bGx5IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5k IHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5l ZCAoX19zdHViX3NucHJpbnRmKSB8fCBkZWZpbmVkIChfX3N0dWJfX19zbnBy aW50ZikNCmNob2tlIG1lDQojZWxzZQ0Kc25wcmludGYoKTsNCiNlbmRpZg0K DQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZv ciBzdHBjcHkNCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1n IC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJv dG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3Iv WDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAg ICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAg IC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21j dGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRu Lm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3Qg ZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0 IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGlu ZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQov KiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBo b3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZs aWN0IHdpdGggY2hhciBzdHBjcHkoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUg PGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJv dG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFy IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBh IGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90 b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBzdHBjcHkoKTsN Cg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmlu ZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAg ICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25z IGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3 aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0K I2lmIGRlZmluZWQgKF9fc3R1Yl9zdHBjcHkpIHx8IGRlZmluZWQgKF9fc3R1 Yl9fX3N0cGNweSkNCmNob2tlIG1lDQojZWxzZQ0Kc3RwY3B5KCk7DQojZW5k aWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0OiBjaGVja2lu ZyBmb3Igc3RyZXJyb3INCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0 ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3Np bmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAt SS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRl c3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0Ug LWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIg LWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xp Yi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBj YW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQg MSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6 DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZz LmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9z IGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2Fu IGNvbmZsaWN0IHdpdGggY2hhciBzdHJlcnJvcigpOyBiZWxvdy4gICovDQoj aW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRl cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2Ug dXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0 eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIHN0 cmVycm9yKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGli cmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21l IGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcg c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFs aWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfc3RyZXJyb3IpIHx8IGRl ZmluZWQgKF9fc3R1Yl9fX3N0cmVycm9yKQ0KY2hva2UgbWUNCiNlbHNlDQpz dHJlcnJvcigpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZToxMDc4NDogY2hlY2tpbmcgZm9yIHR6c2V0DQpjb25maWd1cmU6MTA4MTA6 IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdp bmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNv bXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gx MS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEg ICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIz MiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMg LWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxp bnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6 IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVk IHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNpbmNs dWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUg X19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0K ICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgdHpzZXQoKTsgYmVs b3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55 IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAg Ki8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo ZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVu IGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq Lw0KY2hhciB0enNldCgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdO VSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2gg aXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lT LiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29t ZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBp cyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX3R6c2V0KSB8 fCBkZWZpbmVkIChfX3N0dWJfX190enNldCkNCmNob2tlIG1lDQojZWxzZQ0K dHpzZXQoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6 MTA3ODQ6IGNoZWNraW5nIGZvciB1bGltaXQNCmNvbmZpZ3VyZToxMDgxMDog Z2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lu bGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29t cGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDEx L2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAg IC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMy IC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAt bGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGlu dXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0Mjog bGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQg cHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBf X3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQog ICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciB1bGltaXQoKTsgYmVs b3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3ZlcnJpZGUgYW55 IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAg Ki8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRo ZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFuZCB0aGVu IGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq Lw0KY2hhciB1bGltaXQoKTsNCg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBH TlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNo IGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZ Uy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNv bWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUg aXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1Yl91bGltaXQp IHx8IGRlZmluZWQgKF9fc3R1Yl9fX3VsaW1pdCkNCmNob2tlIG1lDQojZWxz ZQ0KdWxpbWl0KCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmln dXJlOjEwNzg0OiBjaGVja2luZyBmb3IgdXNsZWVwDQpjb25maWd1cmU6MTA4 MTA6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2gg LVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWdu LWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNy L1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxY MTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVz ZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAt bGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNl LWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVj dDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFp bGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA3ODcgImNvbmZpZ3VyZSINCiNp bmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZp bmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVz LA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgdXNsZWVwKCk7 IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRl IGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv ci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQg dGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8NCmNoYXIgdXNsZWVwKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBU aGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3 aGljaCBpdCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBF Tk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAg ICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBu YW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfdXNs ZWVwKSB8fCBkZWZpbmVkIChfX3N0dWJfX191c2xlZXApDQpjaG9rZSBtZQ0K I2Vsc2UNCnVzbGVlcCgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNv bmZpZ3VyZToxMDc4NDogY2hlY2tpbmcgZm9yIHdhaXRwaWQNCmNvbmZpZ3Vy ZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAt TC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4 dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMy IC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1s Z2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2 LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpj b2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJl OiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJl Ig0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRv IGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3Rv dHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciB3YWl0 cGlkKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92 ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBh biBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdo dCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRp biBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxs IGFwcGx5LiAgKi8NCmNoYXIgd2FpdHBpZCgpOw0KDQppbnQgbWFpbigpIHsN Cg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5j dGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWls IHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5h bWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBu b3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19z dHViX3dhaXRwaWQpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX3dhaXRwaWQpDQpj aG9rZSBtZQ0KI2Vsc2UNCndhaXRwaWQoKTsNCiNlbmRpZg0KDQo7IHJldHVy biAwOyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciB2c25wcmlu dGYNCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAt V2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBl cyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2lu Y2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFht dSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hl bGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAt bHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4m NQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAt bHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1 cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDc4 NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0 ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVs bHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdp dGggY2hhciB2c25wcmludGYoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFz c2VydC5oPg0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90 eXBlIHRvIGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJl Y2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdj YzINCiAgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5 cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciB2c25wcmludGYoKTsN Cg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmlu ZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAg ICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25z IGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3 aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0K I2lmIGRlZmluZWQgKF9fc3R1Yl92c25wcmludGYpIHx8IGRlZmluZWQgKF9f c3R1Yl9fX3ZzbnByaW50ZikNCmNob2tlIG1lDQojZWxzZQ0KdnNucHJpbnRm KCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwNzg0 OiBjaGVja2luZyBmb3IgZnN5bmMNCmNvbmZpZ3VyZToxMDgxMDogZ2NjIC1v IGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAt V21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAg ICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAg Y29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00g LWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29t ZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAv dXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmlu L2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0 dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3Jh bSB3YXM6DQojbGluZSAxMDc4NyAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNv bmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIg bWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hp Y2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBmc3luYygpOyBiZWxvdy4gICov DQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBp bnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyog V2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVy biB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFy Z3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFy IGZzeW5jKCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGli cmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21l IGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcg c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFs aWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfZnN5bmMpIHx8IGRlZmlu ZWQgKF9fc3R1Yl9fX2ZzeW5jKQ0KY2hva2UgbWUNCiNlbHNlDQpmc3luYygp Ow0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMDc4NDog Y2hlY2tpbmcgZm9yIGZ0cnVuY2F0ZQ0KY29uZmlndXJlOjEwODEwOiBnY2Mg LW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5l IC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJl ICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGli ICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxT TSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxj b21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2Nj IC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9i aW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCBy ZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9n cmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25maWd1cmUiDQojaW5jbHVkZSAi Y29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1 YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3 aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIGZ0cnVuY2F0ZSgpOyBiZWxv dy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkg Z2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAq Lw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl IHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4g aXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov DQpjaGFyIGZ0cnVuY2F0ZSgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhl IEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hp Y2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5P U1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAg c29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFt ZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX2Z0cnVu Y2F0ZSkgfHwgZGVmaW5lZCAoX19zdHViX19fZnRydW5jYXRlKQ0KY2hva2Ug bWUNCiNlbHNlDQpmdHJ1bmNhdGUoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAw OyB9DQpjb25maWd1cmU6MTA3ODQ6IGNoZWNraW5nIGZvciB1bWFzaw0KY29u ZmlndXJlOjEwODEwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1X bm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hh ZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAg ICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQg LWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1s Z2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bv b2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNy L2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bv b2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25m aWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEwNzg3ICJjb25m aWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFk ZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcg cHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFy IHVtYXNrKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8q IE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9p ZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBt aWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVp bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0 aWxsIGFwcGx5LiAgKi8NCmNoYXIgdW1hc2soKTsNCg0KaW50IG1haW4oKSB7 DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVu Y3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFp bCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBu YW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUg bm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9f c3R1Yl91bWFzaykgfHwgZGVmaW5lZCAoX19zdHViX19fdW1hc2spDQpjaG9r ZSBtZQ0KI2Vsc2UNCnVtYXNrKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsg fQ0KY29uZmlndXJlOjEwODQyOiBjaGVja2luZyBmb3IgZ2V0cHQNCmNvbmZp Z3VyZToxMDg2ODogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25v LXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRv dyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAg ICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1s WGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdk aTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29s IC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9p NDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29s DQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmln dXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDg0NSAiY29uZmln dXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVy IHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHBy b3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBn ZXRwdCgpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBP dmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQg YW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWln aHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0 aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGls bCBhcHBseS4gICovDQpjaGFyIGdldHB0KCk7DQoNCmludCBtYWluKCkgew0K DQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0 aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwg d2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFt ZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5v cm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0 dWJfZ2V0cHQpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX2dldHB0KQ0KY2hva2Ug bWUNCiNlbHNlDQpnZXRwdCgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0N CmNvbmZpZ3VyZToxMDg0MjogY2hlY2tpbmcgZm9yIF9nZXRwdHkNCmNvbmZp Z3VyZToxMDg2ODogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25v LXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRv dyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAg ICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1s WGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdk aTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29s IC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9p NDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29s DQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmln dXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDg0NSAiY29uZmln dXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVy IHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHBy b3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBf Z2V0cHR5KCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8q IE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9p ZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBt aWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVp bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0 aWxsIGFwcGx5LiAgKi8NCmNoYXIgX2dldHB0eSgpOw0KDQppbnQgbWFpbigp IHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBm dW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBm YWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5 IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRo ZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAo X19zdHViX19nZXRwdHkpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX19nZXRwdHkp DQpjaG9rZSBtZQ0KI2Vsc2UNCl9nZXRwdHkoKTsNCiNlbmRpZg0KDQo7IHJl dHVybiAwOyB9DQpjb25maWd1cmU6MTA4NDI6IGNoZWNraW5nIGZvciBncmFu dHB0DQpjb25maWd1cmU6MTA4Njg6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMg LVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlw ZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9p bmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxY bXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNo ZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIg LWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+ JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQg LWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0 dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA4 NDUgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lz dGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1 bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3 aXRoIGNoYXIgZ3JhbnRwdCgpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNz ZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5 cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2Nj Mg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGdyYW50cHQoKTsNCg0K aW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMg dGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0 byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFy ZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRo IF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lm IGRlZmluZWQgKF9fc3R1Yl9ncmFudHB0KSB8fCBkZWZpbmVkIChfX3N0dWJf X19ncmFudHB0KQ0KY2hva2UgbWUNCiNlbHNlDQpncmFudHB0KCk7DQojZW5k aWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJlOjEwODQyOiBjaGVja2lu ZyBmb3IgdW5sb2NrcHQNCmNvbmZpZ3VyZToxMDg2ODogZ2NjIC1vIGNvbmZ0 ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3Np bmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAt SS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRl c3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0Ug LWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIg LWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xp Yi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBj YW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQg MSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6 DQojbGluZSAxMDg0NSAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZz LmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9z IGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2Fu IGNvbmZsaWN0IHdpdGggY2hhciB1bmxvY2twdCgpOyBiZWxvdy4gICovDQoj aW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRl cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2Ug dXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0 eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIHVu bG9ja3B0KCk7DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGli cmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBs ZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21l IGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcg c3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFs aWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0dWJfdW5sb2NrcHQpIHx8IGRl ZmluZWQgKF9fc3R1Yl9fX3VubG9ja3B0KQ0KY2hva2UgbWUNCiNlbHNlDQp1 bmxvY2twdCgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZToxMDg0MjogY2hlY2tpbmcgZm9yIHB0c25hbWUNCmNvbmZpZ3VyZToxMDg2 ODogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAt V2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24t Y29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3Iv WDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgx MSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNl cjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1s YyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2Ut bGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0 MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWls ZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDg0NSAiY29uZmlndXJlIg0KI2lu Y2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmlu ZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMs DQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBwdHNuYW1lKCk7 IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRl IGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv ci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQg dGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5 LiAgKi8NCmNoYXIgcHRzbmFtZSgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyog VGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMg d2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGgg RU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQog ICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwg bmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX3B0 c25hbWUpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX3B0c25hbWUpDQpjaG9rZSBt ZQ0KI2Vsc2UNCnB0c25hbWUoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9 DQpjb25maWd1cmU6MTA4NDI6IGNoZWNraW5nIGZvciBraWxscGcNCmNvbmZp Z3VyZToxMDg2ODogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25v LXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRv dyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAg ICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1s WGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdk aTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29s IC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9p NDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29s DQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmln dXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMDg0NSAiY29uZmln dXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVy IHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHBy b3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBr aWxscGcoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyog T3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk IGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1p Z2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWls dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3Rp bGwgYXBwbHkuICAqLw0KY2hhciBraWxscGcoKTsNCg0KaW50IG1haW4oKSB7 DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVu Y3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFp bCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBu YW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUg bm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9f c3R1Yl9raWxscGcpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX2tpbGxwZykNCmNo b2tlIG1lDQojZWxzZQ0Ka2lsbHBnKCk7DQojZW5kaWYNCg0KOyByZXR1cm4g MDsgfQ0KY29uZmlndXJlOjEwODQyOiBjaGVja2luZyBmb3IgdGNnZXRwZ3Jw DQpjb25maWd1cmU6MTA4Njg6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdh bGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMg LVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNs dWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUg LWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxs MzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3 aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUN Ci91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3 aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMN CmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA4NDUg ImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lzdGVt IGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5 IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3aXRo IGNoYXIgdGNnZXRwZ3JwKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3Nl cnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlw ZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNh dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2My DQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBl IHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgdGNnZXRwZ3JwKCk7DQoN CmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVz IHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQogICAg dG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9ucyBh cmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0 aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNp ZiBkZWZpbmVkIChfX3N0dWJfdGNnZXRwZ3JwKSB8fCBkZWZpbmVkIChfX3N0 dWJfX190Y2dldHBncnApDQpjaG9rZSBtZQ0KI2Vsc2UNCnRjZ2V0cGdycCgp Ow0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMDg5Nzog Y2hlY2tpbmcgZm9yIG9wZW5wdHkNCmNvbmZpZ3VyZToxMDkyMzogZ2NjIC1v IGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAt V21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAg ICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAg Y29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00g LWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29t ZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAv dXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmlu L2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0 dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3Jh bSB3YXM6DQojbGluZSAxMDkwMCAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNv bmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIg bWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hp Y2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBvcGVucHR5KCk7IGJlbG93LiAg Ki8NCiNpbmNsdWRlIDxhc3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2My IGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQov KiBXZSB1c2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0 dXJuIHR5cGUgb2YgYSBnY2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMg YXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNo YXIgb3BlbnB0eSgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBD IGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQg aW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAg U29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRo aW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBh biBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX29wZW5wdHkpIHx8 IGRlZmluZWQgKF9fc3R1Yl9fX29wZW5wdHkpDQpjaG9rZSBtZQ0KI2Vsc2UN Cm9wZW5wdHkoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1 cmU6MTA5NDI6IGNoZWNraW5nIGZvciBvcGVucHR5IGluIC1sdXRpbA0KY29u ZmlndXJlOjEwOTU4OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1X bm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hh ZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAg ICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgLWx1dGlsICAgLWxY bXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNo ZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIg LWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+ JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQg LWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0 dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTA5 NDcgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogT3Zl cnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu IGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg YXBwbHkuICAqLw0KY2hhciBvcGVucHR5KCk7DQoNCmludCBtYWluKCkgew0K b3BlbnB0eSgpDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTEwMzc6IGNo ZWNraW5nIGZvciBzdHJvcHRzLmgNCmNvbmZpZ3VyZToxMTA0NTogZ2NjIC1F ICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVzdC5jID4vZGV2L251 bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZToxMTA3ODogY2hlY2tpbmcg Zm9yIGlzYXN0cmVhbQ0KY29uZmlndXJlOjExMTA0OiBnY2MgLW8gY29uZnRl c3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1J L3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVz dC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAt bG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAt bGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGli L2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNh bm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAx IGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoN CiNsaW5lIDExMDgxICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMu aCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVmaW5lIF9fc3R1YiBtYWNyb3Mg YW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBlcywNCiAgICB3aGljaCBjYW4g Y29uZmxpY3Qgd2l0aCBjaGFyIGlzYXN0cmVhbSgpOyBiZWxvdy4gICovDQoj aW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRl cm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2Ug dXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0 eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGlz YXN0cmVhbSgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxp YnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1w bGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29t ZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5n IHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBh bGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX2lzYXN0cmVhbSkgfHwg ZGVmaW5lZCAoX19zdHViX19faXNhc3RyZWFtKQ0KY2hva2UgbWUNCiNlbHNl DQppc2FzdHJlYW0oKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpjb25m aWd1cmU6MTExMzU6IGNoZWNraW5nIGZvciBzdHJ0aW8uaA0KY29uZmlndXJl OjExMTQzOiBnY2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0 ZXN0LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJlOjEx MTM5OiBzdHJ0aW8uaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KY29u ZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMTEzOCAiY29u ZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVkZSA8c3Ry dGlvLmg+DQpjb25maWd1cmU6MTExODA6IGNoZWNraW5nIGZvciBnZXRsb2Fk YXZnDQpjb25maWd1cmU6MTEyMDY6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMg LVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlw ZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9p bmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxY bXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNo ZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIg LWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+ JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQg LWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0 dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTEx ODMgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lz dGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1 bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3 aXRoIGNoYXIgZ2V0bG9hZGF2ZygpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8 YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90 b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIg YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEg Z2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3Rv dHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIGdldGxvYWRhdmco KTsNCg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRl ZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMN CiAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rp b25zIGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGlu ZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAq Lw0KI2lmIGRlZmluZWQgKF9fc3R1Yl9nZXRsb2FkYXZnKSB8fCBkZWZpbmVk IChfX3N0dWJfX19nZXRsb2FkYXZnKQ0KY2hva2UgbWUNCiNlbHNlDQpnZXRs b2FkYXZnKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmlndXJl OjExMjgzOiBjaGVja2luZyBmb3Iga3N0YXRfb3BlbiBpbiAtbGtzdGF0DQpj b25maWd1cmU6MTEyOTk6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwg LVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdz aGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRl ICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAtbGtzdGF0ICAg LWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAt bHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3Rs MzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5v IDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZp bmQgLWxrc3RhdA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0 dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTEy ODggImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogT3Zl cnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu IGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg YXBwbHkuICAqLw0KY2hhciBrc3RhdF9vcGVuKCk7DQoNCmludCBtYWluKCkg ew0Ka3N0YXRfb3BlbigpDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTEz MzQ6IGNoZWNraW5nIGZvciBrc3RhdC5oDQpjb25maWd1cmU6MTEzNDI6IGdj YyAtRSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgY29uZnRlc3QuYyA+L2Rl di9udWxsIDI+Y29uZnRlc3Qub3V0DQpjb25maWd1cmU6MTEzMzg6IGtzdGF0 Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCmNvbmZpZ3VyZTogZmFp bGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTEzMzcgImNvbmZpZ3VyZSINCiNp bmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUgPGtzdGF0Lmg+DQpjb25m aWd1cmU6MTEzNzQ6IGNoZWNraW5nIGZvciBrdm1fcmVhZCBpbiAtbGt2bQ0K Y29uZmlndXJlOjExMzkwOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxs IC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X c2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVk ZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgLWxrdm0gICAt bFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1s c2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwz MiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8g MT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmlu ZCAtbGt2bQ0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMN CmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTEzNzkg ImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogT3ZlcnJp ZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVy cm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1h dGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGluIGFu ZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBw bHkuICAqLw0KY2hhciBrdm1fcmVhZCgpOw0KDQppbnQgbWFpbigpIHsNCmt2 bV9yZWFkKCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMTQyNDogY2hl Y2tpbmcgd2hldGhlciBuZXRkYiBkZWNsYXJlcyBoX2Vycm5vDQpjb25maWd1 cmU6MTE0MzM6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1z d2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cg LVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAg LUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhl eHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkz MiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAt bGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4 Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0K Y29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3Vy ZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTE0MjYgImNvbmZpZ3Vy ZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUgPG5ldGRiLmg+ DQppbnQgbWFpbigpIHsNCnJldHVybiBoX2Vycm5vOw0KOyByZXR1cm4gMDsg fQ0KY29uZmlndXJlOjExNDUzOiBjaGVja2luZyBmb3Igc2lnc2V0am1wDQpj b25maWd1cmU6MTE0NjI6IGdjYyAtYyAtZyAtTzMgLVdhbGwgLVduby1zd2l0 Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdz aWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0ZXN0 LmMgMT4mNQ0KY29uZmlndXJlOjExNDgyOiBjaGVja2luZyB3aGV0aGVyIGxv Y2FsdGltZSBjYWNoZXMgVFoNCmNvbmZpZ3VyZToxMTU1MTogY2hlY2tpbmcg d2hldGhlciBnZXR0aW1lb2ZkYXkgYWNjZXB0cyBvbmUgb3IgdHdvIGFyZ3Vt ZW50cw0KY29uZmlndXJlOjExNTc0OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8z IC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5 cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEv aW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1s WG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxz aGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMy IC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAx PiY1DQpjb25maWd1cmU6IEluIGZ1bmN0aW9uIGBtYWluJzoNCmNvbmZpZ3Vy ZToxMTU2ODogd2FybmluZzogZGVjbGFyYXRpb24gb2YgYHRpbWUnIHNoYWRv d3MgZ2xvYmFsIGRlY2xhcmF0aW9uDQovdXNyL2k0ODYtc3VzZS1saW51eC9i aW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCBy ZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9n cmFtIHdhczoNCiNsaW5lIDExNTUzICJjb25maWd1cmUiDQojaW5jbHVkZSAi Y29uZmRlZnMuaCINCg0KI2lmZGVmIFRJTUVfV0lUSF9TWVNfVElNRQ0KI2lu Y2x1ZGUgPHN5cy90aW1lLmg+DQojaW5jbHVkZSA8dGltZS5oPg0KI2Vsc2UN CiNpZmRlZiBIQVZFX1NZU19USU1FX0gNCiNpbmNsdWRlIDxzeXMvdGltZS5o Pg0KI2Vsc2UNCiNpbmNsdWRlIDx0aW1lLmg+DQojZW5kaWYNCiNlbmRpZg0K ICANCmludCBtYWluKCkgew0KDQogIHN0cnVjdCB0aW1ldmFsIHRpbWU7DQog IGdldHRpbWVvZmRheSAoJnRpbWUsIDApOw0KDQo7IHJldHVybiAwOyB9DQpj b25maWd1cmU6MTE1OTY6IGNoZWNraW5nIGZvciBpbmxpbmUNCmNvbmZpZ3Vy ZToxMTYwODogZ2NjIC1jIC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lu bGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29t cGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgY29uZnRlc3QuYyAxPiY1 DQpjb25maWd1cmU6IEluIGZ1bmN0aW9uIGBtYWluJzoNCmNvbmZpZ3VyZTox MTYwNDogd2FybmluZzogY29udHJvbCByZWFjaGVzIGVuZCBvZiBub24tdm9p ZCBmdW5jdGlvbg0KY29uZmlndXJlOiBBdCB0b3AgbGV2ZWw6DQpjb25maWd1 cmU6MTE2MDQ6IHdhcm5pbmc6IHJldHVybi10eXBlIGRlZmF1bHRzIHRvIGBp bnQnDQpjb25maWd1cmU6MTE2MDQ6IHdhcm5pbmc6IG5vIHByZXZpb3VzIHBy b3RvdHlwZSBmb3IgYGZvbycNCmNvbmZpZ3VyZToxMTY0OTogY2hlY2tpbmcg Zm9yIHdvcmtpbmcgYWxsb2NhLmgNCmNvbmZpZ3VyZToxMTY1OTogZ2NjIC1v IGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAt V21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAg ICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAg Y29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00g LWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29t ZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAv dXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOiBJbiBmdW5jdGlvbiBg bWFpbic6DQpjb25maWd1cmU6MTE2NTU6IHdhcm5pbmc6IHVudXNlZCB2YXJp YWJsZSBgcCcNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90 IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhp dCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xp bmUgMTE2NTIgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0K I2luY2x1ZGUgPGFsbG9jYS5oPg0KaW50IG1haW4oKSB7DQpjaGFyICpwID0g YWxsb2NhKDIgKiBzaXplb2YoaW50KSk7DQo7IHJldHVybiAwOyB9DQpjb25m aWd1cmU6MTE2ODM6IGNoZWNraW5nIGZvciBhbGxvY2ENCmNvbmZpZ3VyZTox MTcxNDogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRj aCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3Np Z24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91 c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAt bFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1s dXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2Nj IC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOiBJ biBmdW5jdGlvbiBgbWFpbic6DQpjb25maWd1cmU6MTE3MTA6IHdhcm5pbmc6 IHVudXNlZCB2YXJpYWJsZSBgcCcNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jp bi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJl dHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dy YW0gd2FzOg0KI2xpbmUgMTE2ODYgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJj b25mZGVmcy5oIg0KDQojaWZkZWYgX19HTlVDX18NCiMgZGVmaW5lIGFsbG9j YSBfX2J1aWx0aW5fYWxsb2NhDQojZWxzZQ0KIyBpZmRlZiBfTVNDX1ZFUg0K IyAgaW5jbHVkZSA8bWFsbG9jLmg+DQojICBkZWZpbmUgYWxsb2NhIF9hbGxv Y2ENCiMgZWxzZQ0KIyAgaWYgSEFWRV9BTExPQ0FfSA0KIyAgIGluY2x1ZGUg PGFsbG9jYS5oPg0KIyAgZWxzZQ0KIyAgIGlmZGVmIF9BSVgNCiAjcHJhZ21h IGFsbG9jYQ0KIyAgIGVsc2UNCiMgICAgaWZuZGVmIGFsbG9jYSAvKiBwcmVk ZWZpbmVkIGJ5IEhQIGNjICtPbGliY2FsbHMgKi8NCmNoYXIgKmFsbG9jYSAo KTsNCiMgICAgZW5kaWYNCiMgICBlbmRpZg0KIyAgZW5kaWYNCiMgZW5kaWYN CiNlbmRpZg0KDQppbnQgbWFpbigpIHsNCmNoYXIgKnAgPSAoY2hhciAqKSBh bGxvY2EoMSk7DQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTE3NTM6IGNo ZWNraW5nIHdoZXRoZXIgYWxsb2NhIG5lZWRzIENyYXkgaG9va3MNCmNvbmZp Z3VyZToxMTgzNjogY2hlY2tpbmcgc3RhY2sgZGlyZWN0aW9uIGZvciBDIGFs bG9jYQ0KY29uZmlndXJlOjExODU4OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8z IC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5 cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEv aW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1s WG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxz aGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMy IC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAx PiY1DQpjb25maWd1cmU6MTE4NDE6IHdhcm5pbmc6IHJldHVybi10eXBlIGRl ZmF1bHRzIHRvIGBpbnQnDQpjb25maWd1cmU6MTE4NDE6IHdhcm5pbmc6IG5v IHByZXZpb3VzIHByb3RvdHlwZSBmb3IgYGZpbmRfc3RhY2tfZGlyZWN0aW9u Jw0KY29uZmlndXJlOjExODUzOiB3YXJuaW5nOiByZXR1cm4tdHlwZSBkZWZh dWx0cyB0byBgaW50Jw0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBj YW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQg MSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6 DQojbGluZSAxMTgzOSAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZz LmgiDQpmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKQ0Kew0KICBzdGF0aWMgY2hh ciAqYWRkciA9IDA7DQogIGF1dG8gY2hhciBkdW1teTsNCiAgaWYgKGFkZHIg PT0gMCkNCiAgICB7DQogICAgICBhZGRyID0gJmR1bW15Ow0KICAgICAgcmV0 dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpOw0KICAgIH0NCiAgZWxzZQ0K ICAgIHJldHVybiAoJmR1bW15ID4gYWRkcikgPyAxIDogLTE7DQp9DQptYWlu ICgpDQp7DQogIGV4aXQgKGZpbmRfc3RhY2tfZGlyZWN0aW9uKCkgPCAwKTsN Cn0NCmNvbmZpZ3VyZToxMTg4ODogY2hlY2tpbmcgZm9yIHZmb3JrLmgNCmNv bmZpZ3VyZToxMTg5NjogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVk ZSBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZp Z3VyZToxMTg5MjogdmZvcmsuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y eQ0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMTg5 MSAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVk ZSA8dmZvcmsuaD4NCmNvbmZpZ3VyZToxMTkyNDogY2hlY2tpbmcgZm9yIHdv cmtpbmcgdmZvcmsNCmNvbmZpZ3VyZToxMjAyMjogZ2NjIC1vIGNvbmZ0ZXN0 IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3Npbmct cHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91 c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3Qu YyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxt ICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxj b21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9j cnRuLm8gMT4mNQ0KY29uZmlndXJlOjExOTQ4OiB3YXJuaW5nOiByZXR1cm4t dHlwZSBkZWZhdWx0cyB0byBgaW50Jw0KY29uZmlndXJlOiBJbiBmdW5jdGlv biBgc3BhcmNfYWRkcmVzc190ZXN0JzoNCmNvbmZpZ3VyZToxMTk2NDogd2Fy bmluZzogY29udHJvbCByZWFjaGVzIGVuZCBvZiBub24tdm9pZCBmdW5jdGlv bg0KY29uZmlndXJlOiBBdCB0b3AgbGV2ZWw6DQpjb25maWd1cmU6MTE5NjU6 IHdhcm5pbmc6IHJldHVybi10eXBlIGRlZmF1bHRzIHRvIGBpbnQnDQpjb25m aWd1cmU6IEluIGZ1bmN0aW9uIGBtYWluJzoNCmNvbmZpZ3VyZToxMTk0ODog d2FybmluZzogaW5saW5pbmcgZmFpbGVkIGluIGNhbGwgdG8gYHNwYXJjX2Fk ZHJlc3NfdGVzdCcNCmNvbmZpZ3VyZToxMTk2OTogd2FybmluZzogY2FsbGVk IGZyb20gaGVyZQ0KY29uZmlndXJlOjEyMDAzOiB3YXJuaW5nOiBpbXBsaWNp dCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiBgd2FpdCcNCi91c3IvaTQ4Ni1z dXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29s bGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTog ZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTE5MjcgImNvbmZpZ3VyZSIN CiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogVGhhbmtzIHRvIFBhdWwgRWdn ZXJ0IGZvciB0aGlzIHRlc3QuICAqLw0KI2luY2x1ZGUgPHN0ZGlvLmg+DQoj aW5jbHVkZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8c3lzL3N0YXQuaD4N CiNpZmRlZiBIQVZFX1VOSVNURF9IDQojaW5jbHVkZSA8dW5pc3RkLmg+DQoj ZW5kaWYNCiNpZmRlZiBIQVZFX1ZGT1JLX0gNCiNpbmNsdWRlIDx2Zm9yay5o Pg0KI2VuZGlmDQovKiBPbiBzb21lIHNwYXJjIHN5c3RlbXMsIGNoYW5nZXMg YnkgdGhlIGNoaWxkIHRvIGxvY2FsIGFuZCBpbmNvbWluZw0KICAgYXJndW1l bnQgcmVnaXN0ZXJzIGFyZSBwcm9wYWdhdGVkIGJhY2sgdG8gdGhlIHBhcmVu dC4NCiAgIFRoZSBjb21waWxlciBpcyB0b2xkIGFib3V0IHRoaXMgd2l0aCAj aW5jbHVkZSA8dmZvcmsuaD4sDQogICBidXQgc29tZSBjb21waWxlcnMgKGUu Zy4gZ2NjIC1PKSBkb24ndCBncm9rIDx2Zm9yay5oPi4NCiAgIFRlc3QgZm9y IHRoaXMgYnkgdXNpbmcgYSBzdGF0aWMgdmFyaWFibGUgd2hvc2UgYWRkcmVz cw0KICAgaXMgcHV0IGludG8gYSByZWdpc3RlciB0aGF0IGlzIGNsb2JiZXJl ZCBieSB0aGUgdmZvcmsuICAqLw0Kc3RhdGljDQojaWZkZWYgX19jcGx1c3Bs dXMNCnNwYXJjX2FkZHJlc3NfdGVzdCAoaW50IGFyZykNCiNlbHNlDQpzcGFy Y19hZGRyZXNzX3Rlc3QgKGFyZykgaW50IGFyZzsNCiNlbmRpZg0Kew0KICBz dGF0aWMgcGlkX3QgY2hpbGQ7DQogIGlmICghY2hpbGQpIHsNCiAgICBjaGls ZCA9IHZmb3JrICgpOw0KICAgIGlmIChjaGlsZCA8IDApIHsNCiAgICAgIHBl cnJvciAoInZmb3JrIik7DQogICAgICBfZXhpdCgyKTsNCiAgICB9DQogICAg aWYgKCFjaGlsZCkgew0KICAgICAgYXJnID0gZ2V0cGlkKCk7DQogICAgICB3 cml0ZSgtMSwgIiIsIDApOw0KICAgICAgX2V4aXQgKGFyZyk7DQogICAgfQ0K ICB9DQp9DQptYWluKCkgew0KICBwaWRfdCBwYXJlbnQgPSBnZXRwaWQgKCk7 DQogIHBpZF90IGNoaWxkOw0KDQogIHNwYXJjX2FkZHJlc3NfdGVzdCAoKTsN Cg0KICBjaGlsZCA9IHZmb3JrICgpOw0KDQogIGlmIChjaGlsZCA9PSAwKSB7 DQogICAgLyogSGVyZSBpcyBhbm90aGVyIHRlc3QgZm9yIHNwYXJjIHZmb3Jr IHJlZ2lzdGVyIHByb2JsZW1zLg0KICAgICAgIFRoaXMgdGVzdCB1c2VzIGxv dHMgb2YgbG9jYWwgdmFyaWFibGVzLCBhdCBsZWFzdA0KICAgICAgIGFzIG1h bnkgbG9jYWwgdmFyaWFibGVzIGFzIG1haW4gaGFzIGFsbG9jYXRlZCBzbyBm YXINCiAgICAgICBpbmNsdWRpbmcgY29tcGlsZXIgdGVtcG9yYXJpZXMuICA0 IGxvY2FscyBhcmUgZW5vdWdoIGZvcg0KICAgICAgIGdjYyAxLjQwLjMgb24g YSBTb2xhcmlzIDQuMS4zIHNwYXJjLCBidXQgd2UgdXNlIDggdG8gYmUgc2Fm ZS4NCiAgICAgICBBIGJ1Z2d5IGNvbXBpbGVyIHNob3VsZCByZXVzZSB0aGUg cmVnaXN0ZXIgb2YgcGFyZW50DQogICAgICAgZm9yIG9uZSBvZiB0aGUgbG9j YWwgdmFyaWFibGVzLCBzaW5jZSBpdCB3aWxsIHRoaW5rIHRoYXQNCiAgICAg ICBwYXJlbnQgY2FuJ3QgcG9zc2libHkgYmUgdXNlZCBhbnkgbW9yZSBpbiB0 aGlzIHJvdXRpbmUuDQogICAgICAgQXNzaWduaW5nIHRvIHRoZSBsb2NhbCB2 YXJpYWJsZSB3aWxsIHRodXMgbXVuZ2UgcGFyZW50DQogICAgICAgaW4gdGhl IHBhcmVudCBwcm9jZXNzLiAgKi8NCiAgICBwaWRfdA0KICAgICAgcCA9IGdl dHBpZCgpLCBwMSA9IGdldHBpZCgpLCBwMiA9IGdldHBpZCgpLCBwMyA9IGdl dHBpZCgpLA0KICAgICAgcDQgPSBnZXRwaWQoKSwgcDUgPSBnZXRwaWQoKSwg cDYgPSBnZXRwaWQoKSwgcDcgPSBnZXRwaWQoKTsNCiAgICAvKiBDb252aW5j ZSB0aGUgY29tcGlsZXIgdGhhdCBwLi5wNyBhcmUgbGl2ZTsgb3RoZXJ3aXNl LCBpdCBtaWdodA0KICAgICAgIHVzZSB0aGUgc2FtZSBoYXJkd2FyZSByZWdp c3RlciBmb3IgYWxsIDggbG9jYWwgdmFyaWFibGVzLiAgKi8NCiAgICBpZiAo cCAhPSBwMSB8fCBwICE9IHAyIHx8IHAgIT0gcDMgfHwgcCAhPSBwNA0KCXx8 IHAgIT0gcDUgfHwgcCAhPSBwNiB8fCBwICE9IHA3KQ0KICAgICAgX2V4aXQo MSk7DQoNCiAgICAvKiBPbiBzb21lIHN5c3RlbXMgKGUuZy4gSVJJWCAzLjMp LA0KICAgICAgIHZmb3JrIGRvZXNuJ3Qgc2VwYXJhdGUgcGFyZW50IGZyb20g Y2hpbGQgZmlsZSBkZXNjcmlwdG9ycy4NCiAgICAgICBJZiB0aGUgY2hpbGQg Y2xvc2VzIGEgZGVzY3JpcHRvciBiZWZvcmUgaXQgZXhlY3Mgb3IgZXhpdHMs DQogICAgICAgdGhpcyBtdW5nZXMgdGhlIHBhcmVudCdzIGRlc2NyaXB0b3Ig YXMgd2VsbC4NCiAgICAgICBUZXN0IGZvciB0aGlzIGJ5IGNsb3Npbmcgc3Rk b3V0IGluIHRoZSBjaGlsZC4gICovDQogICAgX2V4aXQoY2xvc2UoZmlsZW5v KHN0ZG91dCkpICE9IDApOw0KICB9IGVsc2Ugew0KICAgIGludCBzdGF0dXM7 DQogICAgc3RydWN0IHN0YXQgc3Q7DQoNCiAgICB3aGlsZSAod2FpdCgmc3Rh dHVzKSAhPSBjaGlsZCkNCiAgICAgIDsNCiAgICBleGl0KA0KCSAvKiBXYXMg dGhlcmUgc29tZSBwcm9ibGVtIHdpdGggdmZvcmtpbmc/ICAqLw0KCSBjaGls ZCA8IDANCg0KCSAvKiBEaWQgdGhlIGNoaWxkIGZhaWw/ICAoVGhpcyBzaG91 bGRuJ3QgaGFwcGVuLikgICovDQoJIHx8IHN0YXR1cw0KDQoJIC8qIERpZCB0 aGUgdmZvcmsvY29tcGlsZXIgYnVnIG9jY3VyPyAgKi8NCgkgfHwgcGFyZW50 ICE9IGdldHBpZCgpDQoNCgkgLyogRGlkIHRoZSBmaWxlIGRlc2NyaXB0b3Ig YnVnIG9jY3VyPyAgKi8NCgkgfHwgZnN0YXQoZmlsZW5vKHN0ZG91dCksICZz dCkgIT0gMA0KCSApOw0KICB9DQp9DQpjb25maWd1cmU6MTIwNDg6IGNoZWNr aW5nIGZvciB3b3JraW5nIHN0cmNvbGwNCmNvbmZpZ3VyZToxMjA2MTogZ2Nj IC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGlu ZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFy ZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xp YiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1s U00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1s Y29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdj YyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KY29uZmlndXJlOjEyMDU0OiB3YXJu aW5nOiByZXR1cm4tdHlwZSBkZWZhdWx0cyB0byBgaW50Jw0KL3Vzci9pNDg2 LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpj b2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJl OiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMjA1MSAiY29uZmlndXJl Ig0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVkZSA8c3RyaW5nLmg+ DQptYWluICgpDQp7DQogIGV4aXQgKHN0cmNvbGwgKCJhYmMiLCAiZGVmIikg Pj0gMCB8fA0KCXN0cmNvbGwgKCJBQkMiLCAiREVGIikgPj0gMCB8fA0KCXN0 cmNvbGwgKCIxMjMiLCAiNDU2IikgPj0gMCk7DQp9DQpjb25maWd1cmU6MTIw ODk6IGNoZWNraW5nIGZvciBnZXRwZ3JwDQpjb25maWd1cmU6MTIxMTU6IGdj YyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxp bmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBh cmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9s aWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAt bFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAt bGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxn Y2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4 L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxk IHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHBy b2dyYW0gd2FzOg0KI2xpbmUgMTIwOTIgImNvbmZpZ3VyZSINCiNpbmNsdWRl ICJjb25mZGVmcy5oIg0KLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19z dHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0KICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgZ2V0cGdycCgpOyBiZWxv dy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlkZSBhbnkg Z2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAq Lw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhl IHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4g aXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov DQpjaGFyIGdldHBncnAoKTsNCg0KaW50IG1haW4oKSB7DQoNCi8qIFRoZSBH TlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNo IGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3aXRoIEVOT1NZ Uy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZA0KICAgIHNv bWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUg aXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1Yl9nZXRwZ3Jw KSB8fCBkZWZpbmVkIChfX3N0dWJfX19nZXRwZ3JwKQ0KY2hva2UgbWUNCiNl bHNlDQpnZXRwZ3JwKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29u ZmlndXJlOjEyMTQzOiBjaGVja2luZyB3aGV0aGVyIGdldHBncnAgdGFrZXMg bm8gYXJndW1lbnQNCmNvbmZpZ3VyZToxMjIwMTogZ2NjIC1vIGNvbmZ0ZXN0 IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3Npbmct cHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91 c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3Qu YyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxt ICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxj b21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9j cnRuLm8gMT4mNQ0KY29uZmlndXJlOjEyMTYyOiB3YXJuaW5nOiByZXR1cm4t dHlwZSBkZWZhdWx0cyB0byBgaW50Jw0KY29uZmlndXJlOiBJbiBmdW5jdGlv biBgbWFpbic6DQpjb25maWd1cmU6MTIxNjM6IHdhcm5pbmc6IGltcGxpY2l0 IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGBnZXRwaWQnDQpjb25maWd1cmU6 MTIxNjQ6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0 aW9uIGBnZXRwZ3JwJw0KY29uZmlndXJlOjEyMTc2OiB3YXJuaW5nOiBpbXBs aWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiBgZm9yaycNCmNvbmZpZ3Vy ZToxMjE4Njogd2FybmluZzogaW1wbGljaXQgZGVjbGFyYXRpb24gb2YgZnVu Y3Rpb24gYHNldHBncnAnDQpjb25maWd1cmU6MTIxOTQ6IHdhcm5pbmc6IGlt cGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGB3YWl0Jw0KL3Vzci9p NDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29s DQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmln dXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMjE0NiAiY29uZmln dXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQoNCi8qDQogKiBJZiB0aGlz IHN5c3RlbSBoYXMgYSBCU0Qtc3R5bGUgZ2V0cGdycCgpLA0KICogd2hpY2gg dGFrZXMgYSBwaWQgYXJndW1lbnQsIGV4aXQgdW5zdWNjZXNzZnVsbHkuDQog Kg0KICogU25hcmZlZCBmcm9tIENoZXQgUmFtZXkncyBiYXNoIHBncnAuYyB0 ZXN0IHByb2dyYW0NCiAqLw0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVk ZSA8c3lzL3R5cGVzLmg+DQoNCmludCAgICAgcGlkOw0KaW50ICAgICBwZzEs IHBnMiwgcGczLCBwZzQ7DQppbnQgICAgIG5nLCBucCwgcywgY2hpbGQ7DQoN Cm1haW4oKQ0Kew0KICAgICAgICBwaWQgPSBnZXRwaWQoKTsNCiAgICAgICAg cGcxID0gZ2V0cGdycCgwKTsNCiAgICAgICAgcGcyID0gZ2V0cGdycCgpOw0K ICAgICAgICBwZzMgPSBnZXRwZ3JwKHBpZCk7DQogICAgICAgIHBnNCA9IGdl dHBncnAoMSk7DQoNCiAgICAgICAgLyoNCiAgICAgICAgICogSWYgYWxsIG9m IHRoZXNlIHZhbHVlcyBhcmUgdGhlIHNhbWUsIGl0J3MgcHJldHR5IHN1cmUg dGhhdA0KICAgICAgICAgKiB3ZSdyZSBvbiBhIHN5c3RlbSB0aGF0IGlnbm9y ZXMgZ2V0cGdycCdzIGZpcnN0IGFyZ3VtZW50Lg0KICAgICAgICAgKi8NCiAg ICAgICAgaWYgKHBnMiA9PSBwZzQgJiYgcGcxID09IHBnMyAmJiBwZzIgPT0g cGczKQ0KICAgICAgICAgICAgICAgIGV4aXQoMCk7DQoNCiAgICAgICAgY2hp bGQgPSBmb3JrKCk7DQogICAgICAgIGlmIChjaGlsZCA8IDApDQogICAgICAg ICAgICAgICAgZXhpdCgxKTsNCiAgICAgICAgZWxzZSBpZiAoY2hpbGQgPT0g MCkgew0KICAgICAgICAgICAgICAgIG5wID0gZ2V0cGlkKCk7DQogICAgICAg ICAgICAgICAgLyoNCiAgICAgICAgICAgICAgICAgKiBJZiB0aGlzIGlzIFN5 cyBWLCB0aGlzIHdpbGwgbm90IHdvcms7IHBncnAgd2lsbCBiZQ0KICAgICAg ICAgICAgICAgICAqIHNldCB0byBucCBiZWNhdXNlIHNldHBncnAganVzdCBj aGFuZ2VzIGEgcGdycCB0byBiZQ0KICAgICAgICAgICAgICAgICAqIHRoZSBz YW1lIGFzIHRoZSBwaWQuDQogICAgICAgICAgICAgICAgICovDQogICAgICAg ICAgICAgICAgc2V0cGdycChucCwgcGcxKTsNCiAgICAgICAgICAgICAgICBu ZyA9IGdldHBncnAoMCk7ICAgICAgICAvKiBTYW1lIHJlc3VsdCBmb3IgU3lz IFYgYW5kIEJTRCAqLw0KICAgICAgICAgICAgICAgIGlmIChuZyA9PSBwZzEp IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4aXQoMSk7DQogICAgICAg ICAgICAgICAgfSBlbHNlIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4 aXQoMCk7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICB9IGVsc2Ugew0K ICAgICAgICAgICAgICAgIHdhaXQoJnMpOw0KICAgICAgICAgICAgICAgIGV4 aXQocz4+OCk7DQogICAgICAgIH0NCn0NCg0KY29uZmlndXJlOjEyMjI4OiBj aGVja2luZyBmb3Igd29ya2luZyBtbWFwDQpjb25maWd1cmU6MTIyNjQ6IGdj YyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxp bmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBh cmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9s aWIgIGNvbmZ0ZXN0LmMgICAgLWxYbXUgLWxYdCAtbFhleHQgLWxYMTEgICAt bFNNIC1sSUNFIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAt bGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxn Y2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCmNvbmZpZ3VyZTogSW4gZnVuY3Rp b24gYG1haW4nOg0KY29uZmlndXJlOjEyMjQ4OiB3YXJuaW5nOiB1bnVzZWQg dmFyaWFibGUgYHAnDQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNh bm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAx IGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoN CiNsaW5lIDEyMjMxICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMu aCINCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5oPg0K I2luY2x1ZGUgPGZjbnRsLmg+DQojaW5jbHVkZSA8c3lzL21tYW4uaD4NCg0K I2lmbmRlZiBNQVBfVkFSSUFCTEUNCiNkZWZpbmUgTUFQX1ZBUklBQkxFIDAN CiNlbmRpZg0KDQojaWZuZGVmIE1BUF9GQUlMRUQNCiNkZWZpbmUgTUFQX0ZB SUxFRCAtMQ0KI2VuZGlmDQoNCmludCBtYWluIChpbnQgYXJnYywgY2hhciAq YXJndltdKQ0Kew0KICBpbnQgZmQgPSAtMTsNCiAgY2FkZHJfdCBwOw0KI2lm bmRlZiBNQVBfQU5PTllNT1VTDQogIGZkID0gb3BlbiAoIi9kZXYvemVybyIs IE9fUkRXUik7DQogIGlmIChmZCA8IDApDQogICAgcmV0dXJuIDE7DQojZGVm aW5lIE1BUF9BTk9OWU1PVVMgMA0KI2VuZGlmDQogIGlmIChtbWFwKDAsIDEw MjQsIFBST1RfUkVBRCB8IFBST1RfV1JJVEUsDQoJICAgTUFQX1BSSVZBVEUg fCBNQVBfVkFSSUFCTEUgfCBNQVBfQU5PTllNT1VTLA0KCSAgIGZkLCAwKSAh PSAodm9pZCAqKSBNQVBfRkFJTEVEKQ0KICAgIHJldHVybiAwOw0KICBwZXJy b3IgKCJjb25mdGVzdDogbW1hcCBmYWlsZWQiKTsNCiAgcmV0dXJuIDE7DQp9 DQpjb25maWd1cmU6MTIzMzI6IGNoZWNraW5nIGZvciB0ZXJtaW9zLmgNCmNv bmZpZ3VyZToxMjM0MDogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVk ZSBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZp Z3VyZToxMjQyMzogY2hlY2tpbmcgZm9yIHNvY2tldA0KY29uZmlndXJlOjEy NDQ5OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNo IC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2ln bi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vz ci9YMTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1s WDExICAgLWxTTSAtbElDRSAtbG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1 c2VyMzIgLWxjb21kbGczMiAtbGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2Mg LWxjIC1sZ2NjIC91c3IvbGliL2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3Vz ZS1saW51eC9iaW4vbGQ6IGNhbm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxl Y3QyOiBsZCByZXR1cm5lZCAxIGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZh aWxlZCBwcm9ncmFtIHdhczoNCiNsaW5lIDEyNDI2ICJjb25maWd1cmUiDQoj aW5jbHVkZSAiY29uZmRlZnMuaCINCi8qIFN5c3RlbSBoZWFkZXIgdG8gZGVm aW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJvdG90eXBl cywNCiAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIHNvY2tldCgp OyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVycmlk ZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJy b3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0 Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4gYW5k IHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBs eS4gICovDQpjaGFyIHNvY2tldCgpOw0KDQppbnQgbWFpbigpIHsNCg0KLyog VGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0aGlzIGZvciBmdW5jdGlvbnMg d2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRvIGFsd2F5cyBmYWlsIHdpdGgg RU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJlIGFjdHVhbGx5IG5hbWVkDQog ICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGggX18gYW5kIHRoZSBub3JtYWwg bmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYgZGVmaW5lZCAoX19zdHViX3Nv Y2tldCkgfHwgZGVmaW5lZCAoX19zdHViX19fc29ja2V0KQ0KY2hva2UgbWUN CiNlbHNlDQpzb2NrZXQoKTsNCiNlbmRpZg0KDQo7IHJldHVybiAwOyB9DQpj b25maWd1cmU6MTI1OTY6IGNoZWNraW5nIGZvciBtc2dnZXQNCmNvbmZpZ3Vy ZToxMjYyMjogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAt TC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4 dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMy IC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1s Z2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2 LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpj b2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJl OiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMjU5OSAiY29uZmlndXJl Ig0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRv IGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3Rv dHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBtc2dn ZXQoKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3Zl cnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu IGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg YXBwbHkuICAqLw0KY2hhciBtc2dnZXQoKTsNCg0KaW50IG1haW4oKSB7DQoN Ci8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBmb3IgZnVuY3Rp b25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdheXMgZmFpbCB3 aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1l ZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9y bWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmluZWQgKF9fc3R1 Yl9tc2dnZXQpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX21zZ2dldCkNCmNob2tl IG1lDQojZWxzZQ0KbXNnZ2V0KCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsg fQ0KY29uZmlndXJlOjEyNzA4OiBjaGVja2luZyBmb3IgZGlyZW50LmgNCmNv bmZpZ3VyZToxMjcxNjogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVk ZSBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZp Z3VyZToxMjc4NDogY2hlY2tpbmcgZm9yIG5saXN0LmgNCmNvbmZpZ3VyZTox Mjc5MjogZ2NjIC1FICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSBjb25mdGVz dC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQNCmNvbmZpZ3VyZToxMjc4 ODogbmxpc3QuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KY29uZmln dXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxMjc4NyAiY29uZmln dXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQojaW5jbHVkZSA8bmxpc3Qu aD4NCmNvbmZpZ3VyZToxMjgyMjogY2hlY2tpbmcgZm9yIHNvdW5kIHN1cHBv cnQNCmNvbmZpZ3VyZToxMzA1NTogY2hlY2tpbmcgZm9yIGF1ZGlvL2F1ZGlv bGliLmgNCmNvbmZpZ3VyZToxMzA2MzogZ2NjIC1FICAgICAgIC1JL3Vzci9Y MTEvaW5jbHVkZSBjb25mdGVzdC5jID4vZGV2L251bGwgMj5jb25mdGVzdC5v dXQNCmNvbmZpZ3VyZToxMzA1OTogYXVkaW8vYXVkaW9saWIuaDogTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeQ0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3Jh bSB3YXM6DQojbGluZSAxMzA1OCAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNv bmZkZWZzLmgiDQojaW5jbHVkZSA8YXVkaW8vYXVkaW9saWIuaD4NCmNvbmZp Z3VyZToxMzE2NzogY2hlY2tpbmcgZm9yIGVzZC1jb25maWcNCmNvbmZpZ3Vy ZToxMzE5NjogY2hlY2tpbmcgZm9yIGVzZF9wbGF5X3N0cmVhbQ0KY29uZmln dXJlOjEzMjIyOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8t c3dpdGNoIC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93 IC1Xc2lnbi1jb21wYXJlICAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAg ICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1s WGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLUwvdXNyL2xpYiAtbGVzZCAtbGF1 ZGlvZmlsZSAtbG0gLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMy IC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAt bGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGlu dXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0Mjog bGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQg cHJvZ3JhbSB3YXM6DQojbGluZSAxMzE5OSAiY29uZmlndXJlIg0KI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBf X3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQog ICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBlc2RfcGxheV9zdHJl YW0oKTsgYmVsb3cuICAqLw0KI2luY2x1ZGUgPGFzc2VydC5oPg0KLyogT3Zl cnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu IGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0 IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAgICBidWlsdGlu IGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwg YXBwbHkuICAqLw0KY2hhciBlc2RfcGxheV9zdHJlYW0oKTsNCg0KaW50IG1h aW4oKSB7DQoNCi8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRlZmluZXMgdGhpcyBm b3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMNCiAgICB0byBhbHdh eXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1 YWxseSBuYW1lZA0KICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFu ZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4gYWxpYXMuICAqLw0KI2lmIGRlZmlu ZWQgKF9fc3R1Yl9lc2RfcGxheV9zdHJlYW0pIHx8IGRlZmluZWQgKF9fc3R1 Yl9fX2VzZF9wbGF5X3N0cmVhbSkNCmNob2tlIG1lDQojZWxzZQ0KZXNkX3Bs YXlfc3RyZWFtKCk7DQojZW5kaWYNCg0KOyByZXR1cm4gMDsgfQ0KY29uZmln dXJlOjEzMjczOiBjaGVja2luZyBmb3IgVFRZLXJlbGF0ZWQgZmVhdHVyZXMN CmNvbmZpZ3VyZToxMzI4OTogY2hlY2tpbmcgZm9yIHRnZXRlbnQgaW4gLWxu Y3Vyc2VzDQpjb25maWd1cmU6MTMzMDU6IGdjYyAtbyBjb25mdGVzdCAtZyAt TzMgLVdhbGwgLVduby1zd2l0Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3Rv dHlwZXMgLVdzaGFkb3cgLVdzaWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gx MS9pbmNsdWRlICAgICAgLUwvdXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAt bG5jdXJzZXMgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJ Q0UgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxn MzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNy L2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xk OiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJu ZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3 YXM6DQojbGluZSAxMzI5NCAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZk ZWZzLmgiDQovKiBPdmVycmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5 cGUgdG8gYXZvaWQgYW4gZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVj YXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2Nj Mg0KICAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlw ZSB3b3VsZCBzdGlsbCBhcHBseS4gICovDQpjaGFyIHRnZXRlbnQoKTsNCg0K aW50IG1haW4oKSB7DQp0Z2V0ZW50KCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZp Z3VyZToxMzU5NDogY2hlY2tpbmcgZm9yIGdwbS5oDQpjb25maWd1cmU6MTM2 MDI6IGdjYyAtRSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgY29uZnRlc3Qu YyA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0DQpjb25maWd1cmU6MTM2MjU6 IGNoZWNraW5nIGZvciBHcG1fT3BlbiBpbiAtbGdwbQ0KY29uZmlndXJlOjEz NjQxOiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNo IC1XaW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2ln bi1jb21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vz ci9YMTEvbGliICBjb25mdGVzdC5jICAgLWxncG0gICAtbFhtdSAtbFh0IC1s WGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWx0ZXJtY2FwIC1sY3Vyc2VzIC1s bSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1s Y29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIv Y3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fu bm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEg ZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0K I2xpbmUgMTM2MzAgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5o Ig0KLyogT3ZlcnJpZGUgYW55IGdjYzIgaW50ZXJuYWwgcHJvdG90eXBlIHRv IGF2b2lkIGFuIGVycm9yLiAgKi8NCi8qIFdlIHVzZSBjaGFyIGJlY2F1c2Ug aW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIGdjYzINCiAg ICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291 bGQgc3RpbGwgYXBwbHkuICAqLw0KY2hhciBHcG1fT3BlbigpOw0KDQppbnQg bWFpbigpIHsNCkdwbV9PcGVuKCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3Vy ZToxMzY5MTogY2hlY2tpbmcgZm9yIGRhdGFiYXNlIHN1cHBvcnQNCmNvbmZp Z3VyZToxMzY5NjogY2hlY2tpbmcgZm9yIG5kYm0uaA0KY29uZmlndXJlOjEz NzA0OiBnY2MgLUUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlIGNvbmZ0ZXN0 LmMgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dA0KY29uZmlndXJlOjEzNzAw OiBuZGJtLmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCmNvbmZpZ3Vy ZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTM2OTkgImNvbmZpZ3Vy ZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KI2luY2x1ZGUgPG5kYm0uaD4N CmNvbmZpZ3VyZToxMzg4MDogY2hlY2tpbmcgZm9yIEJlcmtlbGV5IGRiLmgN CmNvbmZpZ3VyZToxMzkwNTogZ2NjIC1jIC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgY29uZnRl c3QuYyAxPiY1DQpjb25maWd1cmU6MTM4OTg6IGRiL2RiLmg6IE5vIHN1Y2gg ZmlsZSBvciBkaXJlY3RvcnkNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0g d2FzOg0KI2xpbmUgMTM4ODMgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25m ZGVmcy5oIg0KDQojaW5jbHVkZSA8c3RkbGliLmg+DQojaWYgIShkZWZpbmVk IF9fR0xJQkNfXyAmJiBfX0dMSUJDX01JTk9SX18gPj0gMSkNCiNpZmRlZiBI QVZFX0lOVFRZUEVTX0gNCiNkZWZpbmUgX19CSVRfVFlQRVNfREVGSU5FRF9f DQojaW5jbHVkZSA8aW50dHlwZXMuaD4NCnR5cGVkZWYgdWludDhfdCAgdV9p bnQ4X3Q7DQp0eXBlZGVmIHVpbnQxNl90IHVfaW50MTZfdDsNCnR5cGVkZWYg dWludDMyX3QgdV9pbnQzMl90Ow0KI2lmZGVmIFdFX0RPTlRfTkVFRF9RVUFE Uw0KdHlwZWRlZiB1aW50NjRfdCB1X2ludDY0X3Q7DQojZW5kaWYNCiNlbmRp Zg0KI2VuZGlmDQojaW5jbHVkZSA8ZGIvZGIuaD4NCg0KaW50IG1haW4oKSB7 DQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxMzkwNTogZ2NjIC1jIC1n IC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJv dG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3Iv WDExL2luY2x1ZGUgY29uZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6MTM5MjE6 IGNoZWNraW5nIGZvciBCZXJrZWxleSBEQiB2ZXJzaW9uDQpjb25maWd1cmU6 MTM5NjI6IGNoZWNraW5nIGZvciBkYl9jcmVhdGUNCmNvbmZpZ3VyZToxMzk4 ODogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3aXRjaCAt V2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAtV3NpZ24t Y29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgICAgICAtTC91c3Iv WDExL2xpYiAgY29uZnRlc3QuYyAgICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgx MSAgIC1sU00gLWxJQ0UgLWx0ZXJtY2FwIC1sY3Vyc2VzIC1sbSAgICAtbHNo ZWxsMzIgLWxnZGkzMiAtbHVzZXIzMiAtbGNvbWRsZzMyIC1sY29tY3RsMzIg LWx3aW5zcG9vbCAtbGdjYyAtbGMgLWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+ JjUNCi91c3IvaTQ4Ni1zdXNlLWxpbnV4L2Jpbi9sZDogY2Fubm90IGZpbmQg LWx3aW5zcG9vbA0KY29sbGVjdDI6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0 dXMNCmNvbmZpZ3VyZTogZmFpbGVkIHByb2dyYW0gd2FzOg0KI2xpbmUgMTM5 NjUgImNvbmZpZ3VyZSINCiNpbmNsdWRlICJjb25mZGVmcy5oIg0KLyogU3lz dGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1 bGx5IGZldyBwcm90b3R5cGVzLA0KICAgIHdoaWNoIGNhbiBjb25mbGljdCB3 aXRoIGNoYXIgZGJfY3JlYXRlKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxh c3NlcnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3Rv dHlwZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBi ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBn Y2MyDQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90 eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgZGJfY3JlYXRlKCk7 DQoNCmludCBtYWluKCkgew0KDQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZp bmVzIHRoaXMgZm9yIGZ1bmN0aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQog ICAgdG8gYWx3YXlzIGZhaWwgd2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9u cyBhcmUgYWN0dWFsbHkgbmFtZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcg d2l0aCBfXyBhbmQgdGhlIG5vcm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8N CiNpZiBkZWZpbmVkIChfX3N0dWJfZGJfY3JlYXRlKSB8fCBkZWZpbmVkIChf X3N0dWJfX19kYl9jcmVhdGUpDQpjaG9rZSBtZQ0KI2Vsc2UNCmRiX2NyZWF0 ZSgpOw0KI2VuZGlmDQoNCjsgcmV0dXJuIDA7IH0NCmNvbmZpZ3VyZToxNDAw NzogY2hlY2tpbmcgZm9yIGRiX2NyZWF0ZSBpbiAtbGRiDQpjb25maWd1cmU6 MTQwMjM6IGdjYyAtbyBjb25mdGVzdCAtZyAtTzMgLVdhbGwgLVduby1zd2l0 Y2ggLVdpbmxpbmUgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdzaGFkb3cgLVdz aWduLWNvbXBhcmUgICAgICAgLUkvdXNyL1gxMS9pbmNsdWRlICAgICAgLUwv dXNyL1gxMS9saWIgIGNvbmZ0ZXN0LmMgICAtbGRiICAgLWxYbXUgLWxYdCAt bFhleHQgLWxYMTEgICAtbFNNIC1sSUNFIC1sdGVybWNhcCAtbGN1cnNlcyAt bG0gICAgLWxzaGVsbDMyIC1sZ2RpMzIgLWx1c2VyMzIgLWxjb21kbGczMiAt bGNvbWN0bDMyIC1sd2luc3Bvb2wgLWxnY2MgLWxjIC1sZ2NjIC91c3IvbGli L2NydG4ubyAxPiY1DQovdXNyL2k0ODYtc3VzZS1saW51eC9iaW4vbGQ6IGNh bm5vdCBmaW5kIC1sd2luc3Bvb2wNCmNvbGxlY3QyOiBsZCByZXR1cm5lZCAx IGV4aXQgc3RhdHVzDQpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoN CiNsaW5lIDE0MDEyICJjb25maWd1cmUiDQojaW5jbHVkZSAiY29uZmRlZnMu aCINCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlwZSB0 byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNhdXNl IGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2MyDQog ICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv dWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgZGJfY3JlYXRlKCk7DQoNCmlu dCBtYWluKCkgew0KZGJfY3JlYXRlKCkNCjsgcmV0dXJuIDA7IH0NCmNvbmZp Z3VyZToxNDE1ODogY2hlY2tpbmcgZm9yIG1vZHVsZSBzdXBwb3J0DQpjb25m aWd1cmU6MTQzNTI6IGNoZWNraW5nIGhvdyB0byBidWlsZCBkeW5hbWljIGxp YnJhcmllcyBmb3IgaTU4Ni1wYy1saW51eA0KY29uZmlndXJlOjE0NDA0OiBj aGVja2luZyBob3cgdG8gcHJvZHVjZSBQSUMgY29kZQ0KY29uZmlndXJlOjE0 NTA1OiBjaGVja2luZyBpZiBQSUMgZmxhZyAtZlBJQyByZWFsbHkgd29ya3MN CmNvbmZpZ3VyZToxNDUxNjogZ2NjIC1jIC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAtZlBJQyAtRFBJQyAgICAgICAtSS91c3IvWDExL2lu Y2x1ZGUgY29uZnRlc3QuYyAxPiY1DQpjb25maWd1cmU6IEluIGZ1bmN0aW9u IGBtYWluJzoNCmNvbmZpZ3VyZToxNDUxMjogd2FybmluZzogdW51c2VkIHZh cmlhYmxlIGB4Jw0KY29uZmlndXJlOjE0NTQ3OiBjaGVja2luZyBpZiBDIGNv bXBpbGVyIGNhbiBwcm9kdWNlIHNoYXJlZCBsaWJyYXJpZXMNCmNvbmZpZ3Vy ZToxNDYwNTogZ2NjIC1vIGNvbmZ0ZXN0IC1nIC1PMyAtV2FsbCAtV25vLXN3 aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJvdG90eXBlcyAtV3NoYWRvdyAt V3NpZ24tY29tcGFyZSAgICAgICAtSS91c3IvWDExL2luY2x1ZGUgLXNoYXJl ZCAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVzdC5jIDE+JjUNCmNvbmZp Z3VyZTogSW4gZnVuY3Rpb24gYG1haW4nOg0KY29uZmlndXJlOjE0NjAxOiB3 YXJuaW5nOiB1bnVzZWQgdmFyaWFibGUgYHgnDQpjb25maWd1cmU6MTQ2MzA6 IGNoZWNraW5nIGZvciBsZCB1c2VkIGJ5IEdDQw0KY29uZmlndXJlOjE0Njkz OiBjaGVja2luZyBpZiB0aGUgbGlua2VyIGlzIEdOVSBsZA0KR05VIGxkIHZl cnNpb24gMi4xMC45MSAod2l0aCBCRkQgMi4xMC4wLjMzKQ0KY29uZmlndXJl OjE0OTMyOiBjaGVja2luZyBmb3IgZGxlcnJvcg0KY29uZmlndXJlOjE0OTU4 OiBnY2MgLW8gY29uZnRlc3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1X aW5saW5lIC1XbWlzc2luZy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1j b21wYXJlICAgICAgIC1JL3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9Y MTEvbGliICBjb25mdGVzdC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDEx ICAgLWxTTSAtbElDRSAtbHRlcm1jYXAgLWxjdXJzZXMgLWxtICAgIC1sc2hl bGwzMiAtbGdkaTMyIC1sdXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAt bHdpbnNwb29sIC1sZ2NjIC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4m NQ0KL3Vzci9pNDg2LXN1c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAt bHdpbnNwb29sDQpjb2xsZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1 cw0KY29uZmlndXJlOiBmYWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxNDkz NSAiY29uZmlndXJlIg0KI2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0 ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVs bHkgZmV3IHByb3RvdHlwZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdp dGggY2hhciBkbGVycm9yKCk7IGJlbG93LiAgKi8NCiNpbmNsdWRlIDxhc3Nl cnQuaD4NCi8qIE92ZXJyaWRlIGFueSBnY2MyIGludGVybmFsIHByb3RvdHlw ZSB0byBhdm9pZCBhbiBlcnJvci4gICovDQovKiBXZSB1c2UgY2hhciBiZWNh dXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBnY2My DQogICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBl IHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8NCmNoYXIgZGxlcnJvcigpOw0KDQpp bnQgbWFpbigpIHsNCg0KLyogVGhlIEdOVSBDIGxpYnJhcnkgZGVmaW5lcyB0 aGlzIGZvciBmdW5jdGlvbnMgd2hpY2ggaXQgaW1wbGVtZW50cw0KICAgIHRv IGFsd2F5cyBmYWlsIHdpdGggRU5PU1lTLiAgU29tZSBmdW5jdGlvbnMgYXJl IGFjdHVhbGx5IG5hbWVkDQogICAgc29tZXRoaW5nIHN0YXJ0aW5nIHdpdGgg X18gYW5kIHRoZSBub3JtYWwgbmFtZSBpcyBhbiBhbGlhcy4gICovDQojaWYg ZGVmaW5lZCAoX19zdHViX2RsZXJyb3IpIHx8IGRlZmluZWQgKF9fc3R1Yl9f X2RsZXJyb3IpDQpjaG9rZSBtZQ0KI2Vsc2UNCmRsZXJyb3IoKTsNCiNlbmRp Zg0KDQo7IHJldHVybiAwOyB9DQpjb25maWd1cmU6MTQ5MzI6IGNoZWNraW5n IGZvciBfZGxlcnJvcg0KY29uZmlndXJlOjE0OTU4OiBnY2MgLW8gY29uZnRl c3QgLWcgLU8zIC1XYWxsIC1Xbm8tc3dpdGNoIC1XaW5saW5lIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1Xc2hhZG93IC1Xc2lnbi1jb21wYXJlICAgICAgIC1J L3Vzci9YMTEvaW5jbHVkZSAgICAgIC1ML3Vzci9YMTEvbGliICBjb25mdGVz dC5jICAgIC1sWG11IC1sWHQgLWxYZXh0IC1sWDExICAgLWxTTSAtbElDRSAt bHRlcm1jYXAgLWxjdXJzZXMgLWxtICAgIC1sc2hlbGwzMiAtbGdkaTMyIC1s dXNlcjMyIC1sY29tZGxnMzIgLWxjb21jdGwzMiAtbHdpbnNwb29sIC1sZ2Nj IC1sYyAtbGdjYyAvdXNyL2xpYi9jcnRuLm8gMT4mNQ0KL3Vzci9pNDg2LXN1 c2UtbGludXgvYmluL2xkOiBjYW5ub3QgZmluZCAtbHdpbnNwb29sDQpjb2xs ZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29uZmlndXJlOiBm YWlsZWQgcHJvZ3JhbSB3YXM6DQojbGluZSAxNDkzNSAiY29uZmlndXJlIg0K I2luY2x1ZGUgImNvbmZkZWZzLmgiDQovKiBTeXN0ZW0gaGVhZGVyIHRvIGRl ZmluZSBfX3N0dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlw ZXMsDQogICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciBfZGxlcnJv cigpOyBiZWxvdy4gICovDQojaW5jbHVkZSA8YXNzZXJ0Lmg+DQovKiBPdmVy cmlkZSBhbnkgZ2NjMiBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4g ZXJyb3IuICAqLw0KLyogV2UgdXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQg bWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgZ2NjMg0KICAgIGJ1aWx0aW4g YW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBh cHBseS4gICovDQpjaGFyIF9kbGVycm9yKCk7DQoNCmludCBtYWluKCkgew0K DQovKiBUaGUgR05VIEMgbGlicmFyeSBkZWZpbmVzIHRoaXMgZm9yIGZ1bmN0 aW9ucyB3aGljaCBpdCBpbXBsZW1lbnRzDQogICAgdG8gYWx3YXlzIGZhaWwg d2l0aCBFTk9TWVMuICBTb21lIGZ1bmN0aW9ucyBhcmUgYWN0dWFsbHkgbmFt ZWQNCiAgICBzb21ldGhpbmcgc3RhcnRpbmcgd2l0aCBfXyBhbmQgdGhlIG5v cm1hbCBuYW1lIGlzIGFuIGFsaWFzLiAgKi8NCiNpZiBkZWZpbmVkIChfX3N0 dWJfX2RsZXJyb3IpIHx8IGRlZmluZWQgKF9fc3R1Yl9fX19kbGVycm9yKQ0K Y2hva2UgbWUNCiNlbHNlDQpfZGxlcnJvcigpOw0KI2VuZGlmDQoNCjsgcmV0 dXJuIDA7IH0NCmNvbmZpZ3VyZToxNTAwMTogZ2NjIC1vIGNvbmZ0ZXN0IC1n IC1PMyAtV2FsbCAtV25vLXN3aXRjaCAtV2lubGluZSAtV21pc3NpbmctcHJv dG90eXBlcyAtV3NoYWRvdyAtV3NpZ24tY29tcGFyZSAgICAgICAtSS91c3Iv WDExL2luY2x1ZGUgICAgICAtTC91c3IvWDExL2xpYiAgY29uZnRlc3QuYyAg ICAtbFhtdSAtbFh0IC1sWGV4dCAtbFgxMSAgIC1sU00gLWxJQ0UgLWx0ZXJt Y2FwIC1sY3Vyc2VzIC1sbSAgICAtbHNoZWxsMzIgLWxnZGkzMiAtbHVzZXIz MiAtbGNvbWRsZzMyIC1sY29tY3RsMzIgLWx3aW5zcG9vbCAtbGdjYyAtbGMg LWxnY2MgL3Vzci9saWIvY3J0bi5vIDE+JjUNCi91c3IvaTQ4Ni1zdXNlLWxp bnV4L2Jpbi9sZDogY2Fubm90IGZpbmQgLWx3aW5zcG9vbA0KY29sbGVjdDI6 IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmNvbmZpZ3VyZTogZmFpbGVk IHByb2dyYW0gd2FzOg0KI2xpbmUgMTQ5OTcgImNvbmZpZ3VyZSINCiNpbmNs dWRlICJjb25mZGVmcy5oIg0KaW50IG1haW4oaW50IGMsY2hhciAqdltdKXty ZXR1cm4gMDt9DQo= ---559023410-851401618-990769088=:14090-- From jaa@cc.jyu.fi Fri May 25 01:40:02 2001 Received: from tukki.cc.jyu.fi (tukki.cc.jyu.fi [130.234.1.1]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA22575 for ; Fri, 25 May 2001 01:40:01 -0400 Received: from localhost (jaa@localhost) by tukki.cc.jyu.fi (8.9.3/8.9.3/antispam3) with ESMTP id IAA22783 for ; Fri, 25 May 2001 08:39:31 +0300 (EET DST) Date: Fri, 25 May 2001 08:39:31 +0300 (EET DST) From: Jani Averbach X-Sender: jaa@tukki To: xemacs-beta@xemacs.org Subject: Re: Packages installer doesn't work + other weirdiness In-Reply-To: <15117.56613.159294.451271@turnbull.sk.tsukuba.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 May 2001, Stephen J. Turnbull wrote: > Please provide the config.log up to that point. This will help us see > if we need to make further tests (there was a different library cited > in earlier reports, if they are the same problem). > I send the logs to you in the privat mail. > Jani> The package autoinstaller won't work: > > Jani> (1) (error/warning) Error in process filter: (ftp-error FTP > Jani> Error: DIR failed: 500 Illegal PORT command.) > > Possibly you're using an FTP client (seems unlikely in Red Hat 6.2, > but you could check) that EFS doesn't know about or an ancient EFS. > If you're behind a firewall, configuring EFS to tell FTP to use > passive mode might help. Ok, that helps but not without glue. I can't customise efs (The info tells that there is customise group for efs, but there isn't) or I can't find from help how to change efs to use ftp-client in the passive mode. So I changed system's ftp binary to shell-script which calls ftp with -p. That's help, and everything works after that like charm. But obviously that won't work if you haven't root account at hand. But anyway, thanks very much for help! BR, Jani --- Jani Averbach From youngs@xemacs.org Fri May 25 03:52:43 2001 Received: from mail003.syd.optusnet.com.au (mail003.syd.optusnet.com.au [203.2.75.251]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA26670 for ; Fri, 25 May 2001 03:52:41 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail003.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4P7qWp09004 for ; Fri, 25 May 2001 17:52:34 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4P7l8U1029074; Fri, 25 May 2001 17:47:08 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: print.c error in 21.5 From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 25 May 2001 17:47:08 +1000 Message-ID: Lines: 32 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >From latest CVS I'm getting: ,---- | print.c: In function `print_internal': | print.c:1365: incompatible type for argument 3 of `signal_error' | make[1]: *** [print.o] Error 1 `---- Martin, does it have anything to do with: ,----[ ./src/ChangeLog ] | 2001-05-25 Martin Buchholz | | * fns.c (base64_conversion_error): Fix compile warning. | | * realpath.c: This file doesn't deal with internal | representation. Define DONT_ENCAPSULATE. | Fixes crash in test suite. | | * print.c (print_internal): Fix compile error. | | * miscplay.c (waverequire): Don't inline. | Gcc can't inline functions that call alloca. `---- This is with gcc-2.95.3. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From Adrian.Aichner@t-online.de Fri May 25 04:09:34 2001 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA27642 for ; Fri, 25 May 2001 04:09:33 -0400 Received: from fwd03.sul.t-online.de by mailout05.sul.t-online.de with smtp id 153Cf5-0002MH-04; Fri, 25 May 2001 10:09:31 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.19]) by fwd03.sul.t-online.com with esmtp id 153Cff-0wPF3oC; Fri, 25 May 2001 10:10:07 +0200 To: Jani Averbach Cc: xemacs-beta@xemacs.org Subject: Re: Packages installer doesn't work + other weirdiness References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Jani" == Jani Averbach writes: Jani> 3rd Problem Jani> M-x build-report generated following error: Jani> Symbol's function definition is void: mail Jani> I supposed that it will generate a file, witch one I can Jani> mail other way, but it seems that it like the mail the Jani> report by itself... Hello Jani! I wrote build-report. It uses compose-mail, honoring your setting of mail-user-agent, the standard way to choose among the possible mail user agents. This of course is of little us when you don't have mail-lib, or mh, or gnus, or installed. I recognize this as "my problem" and will think about a solution. The fallback will probably be a buffer containing all proper mail headers and the body containing a complete build-report, which can be saved to a file or even piped into "/usr/bin/mail" directly. Sending in the information obtained by M-x describe-installation is a good first step in the interim. Best regards, Adrian -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From martin@m17n.org Fri May 25 04:16:57 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA27935; Fri, 25 May 2001 04:16:43 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4P8H2p08685; Fri, 25 May 2001 17:17:02 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id RAA24552; Fri, 25 May 2001 17:16:40 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4P8GdE23237; Fri, 25 May 2001 17:16:39 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15118.5351.823681.138564@gargle.gargle.HOWL> Date: Fri, 25 May 2001 17:16:39 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: Steve Youngs Cc: XEmacs Beta Subject: Re: print.c error in 21.5 In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "SY" == Steve Youngs writes: >> From latest CVS I'm getting: SY> ,---- SY> | print.c: In function `print_internal': SY> | print.c:1365: incompatible type for argument 3 of `signal_error' SY> | make[1]: *** [print.o] Error 1 SY> `---- I think I understand why I don't see this myself - union type PLUS no error checking. Try this: Index: src/print.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/print.c,v retrieving revision 1.31 diff -u -w -r1.31 print.c --- src/print.c 2001/05/25 02:57:34 1.31 +++ src/print.c 2001/05/25 08:13:18 @@ -1362,7 +1362,7 @@ /* We're in trouble if this happens! */ if (print_readably) signal_error (Qinternal_error, "printing illegal data type #o%03o", - (int) XTYPE (obj)); + make_int (XTYPE (obj))); write_c_string ("#; Fri, 25 May 2001 09:25:43 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail007.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4PDPcT14152 for ; Fri, 25 May 2001 23:25:38 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4PDN5He007221; Fri, 25 May 2001 23:23:05 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: print.c error in 21.5 References: <15118.5351.823681.138564@gargle.gargle.HOWL> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 25 May 2001 23:23:04 +1000 In-Reply-To: <15118.5351.823681.138564@gargle.gargle.HOWL> (Martin Buchholz's message of "Fri, 25 May 2001 17:16:39 +0900") Message-ID: Lines: 39 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "MB" == Martin Buchholz writes: >>>>>>"SY" == Steve Youngs writes: >>>From latest CVS I'm getting: SY> ,---- SY> | print.c: In function `print_internal': SY> | print.c:1365: incompatible type for argument 3 of `signal_error' SY> | make[1]: *** [print.o] Error 1 SY> `---- MB> I think I understand why I don't see this myself - union type PLUS no MB> error checking. MB> Try this: MB> Index: src/print.c MB> =================================================================== MB> RCS file: /usr/CVSroot/XEmacs/xemacs/src/print.c,v MB> retrieving revision 1.31 MB> diff -u -w -r1.31 print.c MB> --- src/print.c 2001/05/25 02:57:34 1.31 MB> +++ src/print.c 2001/05/25 08:13:18 MB> @@ -1362,7 +1362,7 @@ MB> /* We're in trouble if this happens! */ MB> if (print_readably) MB> signal_error (Qinternal_error, "printing illegal data type #o%03o", MB> - (int) XTYPE (obj)); MB> + make_int (XTYPE (obj))); MB> write_c_string ("# printcharfun); MB> sprintf (buf, "(#o%3o)", (int) XTYPE (obj)); Yes, that fixed the problem. Thanks, Martin. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From toy@rtp.ericsson.se Fri May 25 09:42:57 2001 Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA08443 for ; Fri, 25 May 2001 09:42:57 -0400 Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4PDgq826109 for ; Fri, 25 May 2001 08:42:52 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4PDgqr02069 for ; Fri, 25 May 2001 08:42:52 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Fri May 25 08:42:51 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id JAA11585; Fri, 25 May 2001 09:43:02 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id JAA04521; Fri, 25 May 2001 09:42:49 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: Jani Averbach Cc: xemacs-beta@xemacs.org Subject: Re: Packages installer doesn't work + other weirdiness References: From: Raymond Toy Date: 25 May 2001 09:42:49 -0400 In-Reply-To: Message-ID: <4n1ypdy27a.fsf@rtp.ericsson.se> Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Jani" == Jani Averbach writes: Jani> 2nd Problem Jani> The package autoinstaller won't work: tools-> packages->add download... tools-> packages->List and Install Jani> (1) (error/warning) Error in process filter: (ftp-error FTP Error: DIR Jani> failed: 500 Illegal PORT command.) Jani> and in the menu buffer there is text: Jani> Wrong type argument: stringp, nil Jani> I have tried xemacs.org, and few other local mirros, but the situation is Jani> always same. Can't help with this, but I do have a similar problem. If I select some (well only tried unc and uiuc) of the mirrors and try to tools->packages->update package index, they fail because the package index isn't there. xemacs.org and utk work fine. Haven't tried the others. This is with 21.5-b1, on Solaris 2.7. Ray From youngs@xemacs.org Fri May 25 10:16:58 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA10640 for ; Fri, 25 May 2001 10:16:56 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4PEGne05811 for ; Sat, 26 May 2001 00:16:49 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4PEFFCL019501; Sat, 26 May 2001 00:15:15 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: print.c error in 21.5 References: <15118.5351.823681.138564@gargle.gargle.HOWL> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 26 May 2001 00:15:13 +1000 In-Reply-To: <15118.5351.823681.138564@gargle.gargle.HOWL> (Martin Buchholz's message of "Fri, 25 May 2001 17:16:39 +0900") Message-ID: Lines: 20 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "MB" == Martin Buchholz writes: >>>>>>"SY" == Steve Youngs writes: >>>From latest CVS I'm getting: SY> ,---- SY> | print.c: In function `print_internal': SY> | print.c:1365: incompatible type for argument 3 of `signal_error' SY> | make[1]: *** [print.o] Error 1 SY> `---- MB> I think I understand why I don't see this myself - union type PLUS no MB> error checking. Spot on. Remove '--with-union-type' and it builds without the patch. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From jeff@delphioutpost.com Fri May 25 10:37:32 2001 Received: from capital.delphioutpost.com (h0040108fed72.ne.mediaone.net [65.96.206.68]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id KAA11820 for ; Fri, 25 May 2001 10:37:31 -0400 Received: (qmail 9370 invoked by uid 1002); 25 May 2001 14:37:20 -0000 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15118.28191.488551.727963@delphioutpost.com> Date: Fri, 25 May 2001 10:37:19 -0400 (EDT) To: xemacs-beta@xemacs.org Subject: update package index X-Mailer: VM 6.72 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid When I try to update package index (running from 21.1.11 solaris) I get: (1) (error/warning) Error in process filter: (ftp-error FTP Error: CWD 550 /pub/xemacs/packages/package-index.LATEST.pgp/: Not a directory. failed: ) The problem seems to be that efs insists that the package index file is a directory instead of a file, and gets an error when it trys to download the index. (package-get-locate-index-file nil) ==> "/anonymous@ftp.sunsite.utk.edu:pub/xemacs/packages/package-index.LATEST.pgp" -jeff From glynn.clements@virgin.net Fri May 25 11:41:54 2001 Received: from mta3-svc.virgin.net (mta3-svc.virgin.net [62.253.164.43]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA15438 for ; Fri, 25 May 2001 11:41:54 -0400 Received: from cerise.nosuchdomain.co.uk ([62.252.69.143]) by mta3-svc.virgin.net (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20010525154153.BWSD27981.mta3-svc.virgin.net@cerise.nosuchdomain.co.uk>; Fri, 25 May 2001 16:41:53 +0100 Received: (from glynn@localhost) by cerise.nosuchdomain.co.uk (8.9.3/8.9.3) id QAA01119; Fri, 25 May 2001 16:24:32 +0100 From: Glynn Clements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15118.31024.170573.311903@cerise.nosuchdomain.co.uk> Date: Fri, 25 May 2001 16:24:32 +0100 To: Jani Averbach Cc: xemacs-beta@xemacs.org Subject: Re: Packages installer doesn't work + other weirdiness In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Jani Averbach wrote: > The package autoinstaller won't work: > > tools->packages->add download... > tools->packages->List and Install > > (1) (error/warning) Error in process filter: (ftp-error FTP Error: DIR > failed: 500 Illegal PORT command.) I suspect that you need to set `efs-use-passive-mode' to `t'. -- Glynn Clements From kkm@dtmx.com Fri May 25 19:03:29 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA05607; Fri, 25 May 2001 19:03:26 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 25 May 2001 15:56:05 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010525154812.02e386f8@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 May 2001 16:03:06 -0700 To: "Stephen J. Turnbull" From: "Kirill 'Big K' Katsnelson" Subject: Re: [PATCH] Allows preemtion of redisplay Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org In-Reply-To: <15118.28470.409544.870789@turnbull.sk.tsukuba.ac.jp> References: <4.3.2.7.2.20010524161505.02de0af8@pop> <4.3.2.7.2.20010524161505.02de0af8@pop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Some time ago, Stephen J. Turnbull wrote... > >>>>> "kkm" == Kirill 'Big K' Katsnelson writes: > > kkm> Interesting, but redisplay preemption is disabled in XEmacs > kkm> at all. Once redisplay starts, it will continue through all > kkm> devices and frames, > >I don't understand; the check at l. 6457 looks OK. Comment in >redisplay_frame() indicates this is intentional. Or do you just mean >all frames on the current device? That's bad enough to justify this >patch, though. Stephen, what comment are you referring to? I may have modified the file, so line numbers are off. Generally, redisplay_without_hooks() calls redisplay_device() in a loop, and does not do the preemption check itself, and rather relies on the return value from r_d(). The latter, in turn, calls redisplay_frame(): int preempted = redisplay_frame (f, 1); /* was (f, 0) - kkm */ if (preempted) return 1; The second parameter to r_f() allows preemption when non-zero. I just changed it from 0 to 1, because there was obvious nonsense in the above lines: r_f() never gets preempted, and thus never returns non-zero when its second parameter equal 0. That is, preemption never happened! CVS revision 1.1.1.1, the oldest one, also has the preemption check turned off. I hope that there is enough time for 21.5 to get fixed all the buglets which would be uncovered by this change. > kkm> Please test it. > >Maybe you should post patches of this type to xemacs-beta? Sorry, I misworded this. I did not mean that this is an experimental patch, rather, I am pretty much confident that this change is correct. What I meant by testing was that I wanted everybody to keep an eye open on glitches in display appearance. Thank you for checking it, in any case! -kkm From jmignault@oxygen.com Fri May 25 21:49:00 2001 Received: from 3055jmignault3 (jbm.dialup.access.net [166.84.254.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA12144; Fri, 25 May 2001 21:48:58 -0400 Received: from jmignault by 3055jmignault3 with local (Exim 3.12 #1 (Debian)) id 153U8g-0005gi-00; Fri, 25 May 2001 21:49:14 -0500 From: John Mignault To: XEmacs Build Reports List , xemacs-beta@xemacs.org Subject: [Success] XEmacs 21.5-b1 "anise", i686-pc-linux Message-Id: Date: Fri, 25 May 2001 21:49:14 -0500 Just the configure workaround for Debian. So far so good. j > XEmacs Build Report generated by emacs-version > 21.5 (beta1) "anise" XEmacs Lucid > with system-configuration > i686-pc-linux > follows: > Contents of /home/jmignault/src/xemacs-21.5.1/Installation: > (Output from most recent run of ./configure) uname -a: Linux 3055jmignault3 2.2.18pre21 #1 Sat Nov 18 18:47:15 EST 2000 i686 unknown ./configure '-error-checking=none' '--with-athena=3d' XEmacs 21.5-b1 "anise" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /home/jmignault/src/xemacs-21.5.1 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw3d - Athena library to link: Xaw3d Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Compiling in support for extra debugging code. /home/jmignault/src/xemacs-21.5.1/xemacs-make-install.err not found! /home/jmignault/src/xemacs-21.5.1/xemacs-make-check.err not found! /home/jmignault/src/xemacs-21.5.1/xemacs-make-check-temacs.err not found! /home/jmignault/src/xemacs-21.5.1/xemacs-make-all.err not found! /home/jmignault/src/xemacs-21.5.1/beta.err not found! From ben@666.com Sat May 26 04:18:26 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id EAA28265 for ; Sat, 26 May 2001 04:18:26 -0400 Received: (qmail 23877 invoked by alias); 26 May 2001 08:18:20 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 23824 invoked by uid 0); 26 May 2001 08:18:19 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 26 May 2001 08:18:19 -0000 Message-ID: <3B0F6729.71C18348@666.com> Date: Sat, 26 May 2001 01:19:53 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Buchholz CC: Nix , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> <87zoc3hjod.fsf@loki.wkstn.nix> <15116.30928.39045.556655@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin Buchholz wrote: > > >>>>> "Nix" == nix writes: > > Nix> Oh, FWIW the preprocessor should be able to handle just about anything, > Nix> 'cos I'm cheating. I'm taking c-parse.y and cpplex.c from GCC, and > Nix> tearing them down into something that can unambiguously spot C blocks > Nix> (`stmts_and_decls'), assignments (`expr_no_commas'), Lisp_Object > Nix> variable declarations (`decl' nodes), and temporaries. Everything else > Nix> that I can throw away I will; we don't need a complete C parser, let > Nix> alone the Objective C parts (sorry, Ovidiu ;) ). > > We already have a makefile rule for running the C preprocessor: > > make foo.i > > should work (the rule might not be portable to every C compiler). > > You'll want to run your C parser on the output of that. > > Nix> Fun. (But if this were C++ it would not be fun, it would be torment...) > > Ahhh, but this _is_ C++. > > The production xemacs I use is compiled by a C++ compiler. And the > road is open to someone to take xemacs in a purely C++ direction, for > example to create Qt-xemacs. > > >> Sorry, I meant there's little scope for a Boehm mark() to be better > >> than the existing mark() because the existing one, via lisp object > >> type mark methods, already knows exactly which object components might > >> contain other Lisp_Objects. The mark bitmap won't help you much > >> during the mark phase, in fact it ought to make things worse. > > Nix> Hmm. Why is that? The current garbage collector has appalling VM > Nix> behaviour; every Lisp_Object is sucked back into memory, even if they > Nix> cannot contain other Lisp_Objects. If a mark bitmap is used, a > Nix> Lisp_Object will only be accessed for pointer tracing; if it cannot > Nix> contain another Lisp_Object, it won't be touched. > > Oh, you mean that Lisp object types not containing any Lisp_Objects as > members are accessed by the current gc to access the mark bit in the > lrecord_header? That's true, but currently, also the type and the > c_readonly members need to be accessed. If you move *only* the mark > bits to a separate bitmap, you still need to determine the type of > each object. And even if you don't have to read the lrecord_header of > lisp objects that don't reference other lisp objects, I think you > won't win very much, because MOST lisp objects do reference other lisp > objects. You can look at the output of (garbage-collect) to figure > out what the potential savings are. > > Nix> I'll admit that I haven't instrumented the existing gc to find out what > Nix> percentage of objects are accessed only to set the mark bit; I'll do so > Nix> as soon as this cold has worn off. (I'll feel a right idiot if the > Nix> answer is something like 1%, too...) > > Programmers are notoriously poor at estimating performance questions. > That also means you shouldn't trust my pessimism above. > > >> The place where the Boehm gc shines performance wise is not during gc > >> at all, but in the fact that gcpros can be dispensed with entirely > >> while the mutator runs. Normally the advantage of mark&sweep over > >> reference counting is: not slowing down the mutator. But gcproing does > >> slow down the mutator. But I really don't know how much overhead we > >> have from GCPROing, and it's hard to measure. My random guess is that > >> 10% of the runtime of lisp function calls that do no work (i.e. return > >> immediately) is taken up with gcproing. > > Nix> However, a (not huge) general slowdown like that is hard for humans to > Nix> spot. What humans definitely *do* spot (well, I know I've spotted it, > Nix> and so have friends of mine, new XEmacs hands and old) is the total > Nix> stoppage we get whenever GCing runs and the world freezes except for the > Nix> hammering of the disk :( if XEmacs is totally in swap, it can be frozen > Nix> for a minute or more while GC runs. > > I don't see this happen. Your machine has to have enough memory to > run xemacs - it's a memory hog. > > Better ways to fix this (the "resident set size problem") are: > > - load less lisp. > - load lisp more lazily. (or gasp, unload lisp after it's not been > used for a while... think of loading lisp as "paging in") > - generational gc. > > Nix> Given Moore's Law and the fact that machines with small amounts of > Nix> memory are getting steadily harder to find and steadily harder to run > Nix> late versions of XEmacs on (and probably don't see many upgrades > Nix> anyway), I am happy to *increase* the number of GCPROs substantially, to > Nix> ensure that we can freely modify arbitrary functions without triggering > Nix> GC hell. After all, GCPROs are really quite efficiently implemented; > > You're complaining about how slow xemacs is, and also "it's ok for me > to make it a little slower". > > Nix> it's not as if they call malloc() or something like that. (As a > Nix> *structure*, the gcprolist is praiseworthy. It's just the manual way > Nix> it's kept updated that's disgusting and restrictive.) > > Offhand, it bothers me that most struct gcpro protect just one > variable, so much of the time the initialization and reading of the > nvars member is wasted. But I don't know whether this can be easily > optimized away. Could one have a gcprolist with only `simple' > variables, and a multiple_gcprolist that can protect arrays of > variables? trying to optimize gcpro is wasted effort. [in fact, all attempts to optimize individual machine cycles are wasted efforts -- all you're doing is decreasing the constant factors slightly. you should read the sections on O[n] and optimization in an introductory CS textbook.] > > Nix> (Then I read of GCPRO and felt quite ill...) > > There are other health-sapping critters lurking in the xemacs source code... -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From youngs@xemacs.org Sat May 26 04:36:11 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA28850 for ; Sat, 26 May 2001 04:36:09 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4Q8a0m01916 for ; Sat, 26 May 2001 18:36:01 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4Q8Q13H026481; Sat, 26 May 2001 18:26:01 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 26 May 2001 18:26:01 +1000 In-Reply-To: (Adrian.Aichner@t-online.de's message of "24 May 2001 22:28:09 +0200") Message-ID: Lines: 84 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "APA" == Adrian Aichner writes: APA> Hello All, Hello Steve, APA> many of you must be experiencing the same problems. Not if you're careful. APA> I had long wanted to write about the breakage I see. APA> Some Facts: APA> The package-index file contains APA> (package-get-update-base-entry (quote ...)) APA> forms. Yes. APA> The file is not meant to be hand-edited: APA> ;; Package Index file -- Do not edit manually. APA> ;;;@@@ APA> (package-get-update-base-entry (quote APA> ... True. APA> Building a package adds a APA> (package-get-update-base-entry (quote ...)) APA> form at the beginning of the package-index file in the staging area. Not quite correct. If the entry doesn't already exist it will get written to the top of the file. However, if it does exist, the old entry is overwritten. APA> The Problem: APA> When a package-index file is read, the last APA> (package-get-update-base-entry (quote ...)) APA> form for a certain package in that file supercedes earlier ones. In the normal course of events there is only one entry per package. So this doesn't happen. APA> This means that the Package Release Engineer has to fiddle with the APA> package-index file or remove the package-index file and rebuild all APA> packages from scratch. The only "fiddling" that I do with the package-index file is make sure I have the right version of it in $STAGING. Building all the packages from scratch for me is a *BIG PAIN* because I would have to re-release each and every package each time I wanted to release a single package. Because of the md5sums. Each time you build a package you get a *different* md5sum, regardless of whether anything has changed in the package. APA> Two Questions: APA> 1. Is it a valuable feature for the package-index file to contain APA> multiple instances of the same package to provide a building history APA> of packages? We don't seem to have the interfaces to make use of this APA> feature today. No. At least not until the package system evolves into something a lot more intelligent than what we have now. APA> 2. Shouldn't the latest addition to the package-index file supercede APA> older definitions? It does. APA> Has anybody been working on these problems already? Not me. I don't see a problem. APA> I think item 2 really needs fixing. It ain't broke. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Sat May 26 05:06:39 2001 Received: from mail006.syd.optusnet.com.au (mail006.syd.optusnet.com.au [203.2.75.230]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA29823 for ; Sat, 26 May 2001 05:06:37 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail006.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4Q96Um24778 for ; Sat, 26 May 2001 19:06:30 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4Q8ug7Y026639; Sat, 26 May 2001 18:56:42 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Problem with TAGS, but it's probably me. From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 26 May 2001 18:56:41 +1000 Message-ID: Lines: 15 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I wanted to find something buried deep within the XEmacs source. So I decided to try out this "TAGS" thing. make tags Tools -> Tags -> Set Tags Table File (set to appropriate file) Tools -> Tags -> Find Tag infinite loop (escapable with C-g) Is it a problem with me, or with XEmacs (21.5-b1)? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From Adrian.Aichner@t-online.de Sat May 26 06:07:12 2001 Received: from mailout00.sul.t-online.de (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA31524; Sat, 26 May 2001 06:07:11 -0400 Received: from fwd05.sul.t-online.de by mailout00.sul.t-online.de with smtp id 153ayN-0000UA-0B; Sat, 26 May 2001 12:07:03 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.28]) by fwd05.sul.t-online.com with esmtp id 153az2-1CPeZEC; Sat, 26 May 2001 12:07:44 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 109 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "SY" == Steve Youngs writes: SY> |--==> "APA" == Adrian Aichner writes: APA> Hello All, Hello Steve, APA> many of you must be experiencing the same problems. SY> Not if you're careful. Rephrase that to: Not if your're not using a native Windows XEmacs. Perhaps that is what you mean by being careful :-) APA> I had long wanted to write about the breakage I see. APA> Some Facts: APA> The package-index file contains APA> (package-get-update-base-entry (quote ...)) APA> forms. SY> Yes. APA> The file is not meant to be hand-edited: APA> ;; Package Index file -- Do not edit manually. APA> ;;;@@@ APA> (package-get-update-base-entry (quote APA> ... SY> True. APA> Building a package adds a APA> (package-get-update-base-entry (quote ...)) APA> form at the beginning of the package-index file in the staging area. SY> Not quite correct. If the entry doesn't already exist it will get SY> written to the top of the file. However, if it does exist, the old SY> entry is overwritten. Not for me. APA> The Problem: APA> When a package-index file is read, the last APA> (package-get-update-base-entry (quote ...)) APA> form for a certain package in that file supercedes earlier ones. SY> In the normal course of events there is only one entry per package. SY> So this doesn't happen. Aha, this must be a problem with my platform then. APA> This means that the Package Release Engineer has to fiddle with the APA> package-index file or remove the package-index file and rebuild all APA> packages from scratch. SY> The only "fiddling" that I do with the package-index file is make sure SY> I have the right version of it in $STAGING. SY> Building all the packages from scratch for me is a *BIG PAIN* because SY> I would have to re-release each and every package each time I wanted SY> to release a single package. Because of the md5sums. Each time you SY> build a package you get a *different* md5sum, regardless of whether SY> anything has changed in the package. Yes, I know. APA> Two Questions: APA> 1. Is it a valuable feature for the package-index file to contain APA> multiple instances of the same package to provide a building history APA> of packages? We don't seem to have the interfaces to make use of this APA> feature today. SY> No. At least not until the package system evolves into something a SY> lot more intelligent than what we have now. OK. I guess I'll go bug-hunting. APA> 2. Shouldn't the latest addition to the package-index file supercede APA> older definitions? SY> It does. APA> Has anybody been working on these problems already? SY> Not me. I don't see a problem. APA> I think item 2 really needs fixing. SY> It ain't broke. Yes it is :-) Later, Adrian SY> -- SY> |---------------------| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |---------------------------------------| -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From hniksic@arsdigita.com Sat May 26 06:14:05 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA31737 for ; Sat, 26 May 2001 06:14:04 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 153b59-0002iE-00 for ; Sat, 26 May 2001 12:14:03 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: BAD: Handling of package-index by package release and install system References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 26 May 2001 12:14:03 +0200 In-Reply-To: (Steve Youngs's message of "26 May 2001 18:26:01 +1000") Message-ID: Lines: 11 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Steve Youngs writes: > Building all the packages from scratch for me is a *BIG PAIN* because > I would have to re-release each and every package each time I wanted > to release a single package. Because of the md5sums. Each time you > build a package you get a *different* md5sum, regardless of whether > anything has changed in the package. a. Why? b. Can that be changed? From nix@esperi.demon.co.uk Sat May 26 08:30:11 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA02866; Sat, 26 May 2001 08:30:08 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id NAA29141; Sat, 26 May 2001 13:24:36 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id NAA09986; Sat, 26 May 2001 13:24:35 +0100 Sender: nix@esperi.demon.co.uk To: Ben Wing Cc: Martin Buchholz , Richard Reingruber , Yoshiki Hayashi , Olivier Galibert , Michael Sperber , XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <87ae45j0bn.fsf@loki.wkstn.nix> <15114.13741.708870.454969@gargle.gargle.HOWL> <87zoc3hjod.fsf@loki.wkstn.nix> <15116.30928.39045.556655@gargle.gargle.HOWL> <3B0F6729.71C18348@666.com> X-Emacs: no job too big... no job. From: Nix Date: 26 May 2001 13:24:24 +0100 In-Reply-To: <3B0F6729.71C18348@666.com> Message-ID: <8766eob8nb.fsf@loki.wkstn.nix> Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sat, 26 May 2001, Ben Wing uttered the following: > > Martin Buchholz wrote: >> Offhand, it bothers me that most struct gcpro protect just one >> variable, so much of the time the initialization and reading of the >> nvars member is wasted. But I don't know whether this can be easily >> optimized away. Could one have a gcprolist with only `simple' >> variables, and a multiple_gcprolist that can protect arrays of >> variables? > > trying to optimize gcpro is wasted effort. [in fact, all attempts to optimize > individual machine cycles are wasted efforts -- all you're doing is decreasing > the constant factors slightly. you should read the sections on O[n] and > optimization in an introductory CS textbook.] Not strictly true; in some places GCPRO can contribute more than constant time; e.g. inside recursive functions, or functions that are indirectly called recursively. (There aren't many such yet that I can see; in one place the comment says this is because it was too hard to keep the GCPROs straight... :( But, yes, fixing the algorithms is always a better move. I will, of course, restrain myself from replacing GCPRO with something that is insanely slow (that, say, does dynamic allocation or something)... (One viewpoint is that GCPROs are extra complexity of a totally mechanical nature and so they should be dealt with by computers. That's what they're good at.) -- `Technology is meaningless. What matters is how people _think_ of it.' --- Linus Torvalds From youngs@xemacs.org Sat May 26 08:30:27 2001 Received: from mail007.syd.optusnet.com.au (mail007.syd.optusnet.com.au [203.2.75.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA02878 for ; Sat, 26 May 2001 08:30:25 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail007.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4QCUMT14329 for ; Sat, 26 May 2001 22:30:22 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4QCQPsv018843; Sat, 26 May 2001 22:26:25 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 26 May 2001 22:26:24 +1000 In-Reply-To: (Hrvoje Niksic's message of "26 May 2001 12:14:03 +0200") Message-ID: Lines: 32 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Steve Youngs writes: >>Building all the packages from scratch for me is a *BIG PAIN* because >>I would have to re-release each and every package each time I wanted >>to release a single package. Because of the md5sums. Each time you >>build a package you get a *different* md5sum, regardless of whether >>anything has changed in the package. Hrvoje> a. Why? Personally, I blame GNU/tar. Try doing this: tar cvzf test.tar.gz /some/directory/ md5sum test.tar.gz > test.md5 rm test.tar.gz tar cvzf test.tar.gz /some/directory/ md5sum test.tar.gz >> test.md5 cat test.md5 For some reason you'll have two different md5's. Hrvoje> b. Can that be changed? Don't know. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From ben@666.com Sat May 26 08:39:15 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id IAA03218 for ; Sat, 26 May 2001 08:39:14 -0400 Received: (qmail 86982 invoked by alias); 26 May 2001 12:39:13 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 86965 invoked by uid 0); 26 May 2001 12:39:12 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 26 May 2001 12:39:12 -0000 Message-ID: <3B0FA44F.6B1FA8A5@666.com> Date: Sat, 26 May 2001 05:40:47 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nix CC: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi. i've read some of this thread, and i wish you luck. a few comments: 1. awhile ago i wrote this: http://www.xemacs.org/Architecting-XEmacs/lisp-engine-replacement.html about eliminating the gcpro's and other related changes to improve the ability to replace the garbage collector and/or lisp engine. there is a lot of talk in here about using a c preprocessor to aid in this. some of the ideas here might be useful. 2. my biggest concern is "the last 20%". [it worries me, for example, that michael sperber's student may never get to merging his code and hasn't worked out his plans to do so.] i have seen a great number of efforts in the past involving major changes to the c code, and 9 out of 10 never make it back to the core and soon rot away into nothingness. "the last 20%" actually takes at least 50%-75% of the total time of the project, and isn't the fun part. programmers rarely account for this, and so they typically end up biting off more than they can chew, get stuck somewhere in the middle of the "last 20%", get disheartened and give up. i recommend that you spend some time right now and [a] consider what your plan is for (1) getting the code merged, (2) testing it on all major platforms and in all important configurations, (3) writing up detailed docs [ala my XEmacs Internals Manual] so others can maintain it, and (4) working out any rough edges [e.g. can we easily configure with your new code either on or off? in practice we can't afford to throw away the old code until long after the new code is in place, made the default, and hammered on to no end]; and [b] compute how much effort you think the "last 20%" will take, and then multiply by 3. you'll certainly need all that time. i don't mean to sound pessimistic; i just really want your project to succeed, and that means taking the steps right now to ensure its success. for example, you probably want to reduce the scope of your first pass down to a bare minimum, and restructure your effort so it can be done in stages. then, do the work right away to integrate and test your first pass; that way, you'll have a better sense of how much effort it actually takes to do the integration, and how much motivation you actually have. i am offering to help you in whatever capacity i can. e.g. i probably have a better overall sense of how the internals work than anyone else and can help you understand unclear areas or interactions between areas. also due to unfortunate personal circumstances i have learned how to do the planning and structuring i mentioned above so that i could get done long and difficult tasks given sometimes failing motivation or physical ability, and i'll gladly review any plan of action you come up with and/or help you construct such a plan. Nix wrote: > > I'm currently in the middle of a hack of crazy size, jumping in at the > deep end of XEmacs development, in order to familiarize myself with all > the code. > > I'm doing what should have been done a *long* time ago; ditching the > garbage collector and replacing it with a nicer one. I think everyone > can agree that XEmacs's garbage collector currently sucks really rather > hard; I don't think there are any ways to worsen its VM behaviour or > intrusiveness if we tried. > > The one I've picked is the Boehm collector; it's not terribly portable, > but that can be fixed fairly easily --- and it lets us dump bloody GCPRO > and all the uglinesses it has spawned over the years (blocking string > compaction, Lispification in redisplay and many other things). > > The Boehm collector only has one downside that I can see; unportability > (it's not portable to some of the more obscure platforms that XEmacs > runs on). Upsides include: > > - better VM behaviour (mark bits kept in a bitmap, and GC_malloc_atomic() > to state that certain kinds of objects cannot contain pointers). As > it is most of XEmacs is forced to stay memory-resident all the time > by mark bit setting; that proportion will reduce to just those > parts that contain pointers that must be traced. This is my primary > motivation for this because I run XEmacs on some fairly memory-poor > machines and I'm fed up of waiting for bloody GC to finish. > > - mark bit sanity; we can reclaim at least one bit from many objects, > and might even get lightweight cons cells back (I'm not sure if one > bit saved is enough for that though). Certainly we can junk the myriad > different ways we have to mark things; this is very much improved > recently but the boehm-gc can fix it completely > > - (on some platforms) full incrementality/generationality; we can say a > near-total goodbye to GC delays on those platforms > > - the death of GCPRO, and therefore probably also of gc_currently_forbidden > and similar variables. This is my other major motivation; portable > though it is, I *hate* GCPRO with a passion. (Besides, walking the > stack is not that unportable; the unportabilities in the Boehm > collector are in other areas, like incremental collection.) > > - and last but not least, it's written and actively maintained by > someone who's very accessible and who's one of the best GC hackers > there is, and it is itself acknowledged as probably the best > general-purpose C garbage collector in existence. > > Plus, I think it's a fun hack. > > I'm implementing it in such a way that the tying of the specific GC > implementation to Emacs is light; much lighter than the current > one's. So if everyone else thinks the boehm-gc sucks, you can just rip > it out and use the infrastructure left behind. > > (btw, I think we should under no circumstances implement a copying > collector; they get less and less impressive the bigger the heap and the > longer-lived its objects, and XEmacs has a large heap and a very large > set of long-lived objects, mainly thanks to the obarray.) > > I'll be paying *no* attention to unexec() and friends in this, at least > at first; I'll keep the portable dumper working, but if unexec() is > totally broken by some interaction with the boehm gc, I will not mourn > unduly. > > I'm doing the changes to 21.4.3 at first, because I know it's pretty > stable otherwise, so that any crashes I may encounter are my fault. Once > I've got it working fairly stably in there, I'll post the patches (and > yes, I'll split the patches up into pieces; I don't want the > GCPRO-removal to drown out the interesting stuff) and let everyone rip > into them... and then I guess I'll forward-port it to 2.5, and everyone > can let GCPRO fade into the mists of memory (maybe with the aid of > a psychiatrist). > > -- > `LARTing lusers is supposed to be satisfying. This is just tedious. The > silly shite I'm doing now is like trying to toothpick to death a Black > Knight made of jelly.' --- RDD -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From Adrian.Aichner@t-online.de Sat May 26 08:40:13 2001 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA03263 for ; Sat, 26 May 2001 08:40:12 -0400 Received: from fwd05.sul.t-online.de by mailout06.sul.t-online.de with smtp id 153dMZ-0005dC-03; Sat, 26 May 2001 14:40:11 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.28]) by fwd05.sul.t-online.com with esmtp id 153dND-10A9U8C; Sat, 26 May 2001 14:40:51 +0200 To: XEmacs Beta List , Glyn Millington Subject: [comp.emacs.xemacs] Reluctant Rodent in 21.4.3 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Sender: 520002458184-0001@t-dialin.net --=-=-= Hello Glyn, I am forwarding your mail to xemacs-beta. That's where the XEmacs developers hang out. See http://www.xemacs.org/Lists/index.html#xemacs-beta Best regards, Adrian --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Path: news.t-online.com!newsmm00.sul.t-online.com!newsfeed00.sul.t-online.de!t-online.de!skynet.be!diablo.theplanet.net!news.theplanet.net!newspost.theplanet.net!127.0.0.1!nobody From: Glyn Millington Newsgroups: comp.emacs.xemacs Subject: Reluctant Rodent in 21.4.3 Date: 26 May 2001 12:54:59 +0100 Lines: 26 Sender: glyn@glynthebearded Message-ID: <87itioz5nw.fsf@mill29.fsnet.co.uk> NNTP-Posting-Host: modem-537.chartreux.dialup.pol.co.uk X-Trace: newsg2.svr.pol.co.uk 990878017 10032 217.134.70.25 (26 May 2001 11:53:37 GMT) NNTP-Posting-Date: 26 May 2001 11:53:37 GMT X-Complaints-To: abuse@theplanet.net User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103 Xref: news.t-online.com comp.emacs.xemacs:53876 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii When I try to select an area with the mouse (Xemacs21.4.3)I get this error message Signaling: (wrong-type-argument windowp nil) select-window(nil) default-mouse-track-set-point-in-window(# nil) default-mouse-track-return-dragged-selection(#) default-mouse-track-drag-up-hook(# 1) apply(default-mouse-track-drag-up-hook # 1) mouse-track-run-hook(mouse-track-drag-up-hook # 1) mouse-track(#) call-interactively(mouse-track) Can anyone suggest what I need to do to get this work? TIA Glyn -- so here we are then.... http://members.tripod.co.uk/Christchurch2000uk ==== Running Debian/Gnu Linux ==== 12:52pm up 1:40, 2 users, load average: 0.86, 0.92, 0.80 --=-=-= -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-115 D-81673 MUENCHEN E-mail adrian.aichner@teradyne.com --=-=-=-- From Adrian.Aichner@t-online.de Sat May 26 08:43:38 2001 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA03387; Sat, 26 May 2001 08:43:37 -0400 Received: from fwd05.sul.t-online.de by mailout06.sul.t-online.de with smtp id 153dPs-0005fM-05; Sat, 26 May 2001 14:43:36 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.28]) by fwd05.sul.t-online.com with esmtp id 153dQP-1IDKXQC; Sat, 26 May 2001 14:44:09 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "SY" == Steve Youngs writes: SY> |--==> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Steve Youngs writes: >>> Building all the packages from scratch for me is a *BIG PAIN* because >>> I would have to re-release each and every package each time I wanted >>> to release a single package. Because of the md5sums. Each time you >>> build a package you get a *different* md5sum, regardless of whether >>> anything has changed in the package. Hrvoje> a. Why? SY> Personally, I blame GNU/tar. Try doing this: SY> tar cvzf test.tar.gz /some/directory/ SY> md5sum test.tar.gz > test.md5 SY> rm test.tar.gz SY> tar cvzf test.tar.gz /some/directory/ SY> md5sum test.tar.gz >> test.md5 SY> cat test.md5 SY> For some reason you'll have two different md5's. Could this be some kind of a calendar date, which becomes part of the tarball and thereby part of the calculation? Hrvoje> b. Can that be changed? SY> Don't know. SY> -- SY> |---------------------| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |---------------------------------------| -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From youngs@xemacs.org Sat May 26 08:50:54 2001 Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [203.2.75.244]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA03725 for ; Sat, 26 May 2001 08:50:53 -0400 Received: from slackware.mynet.pc (wdcax13-218.dialup.optusnet.com.au [198.142.220.218]) by mail001.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4QCone21281 for ; Sat, 26 May 2001 22:50:50 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4QCjCtc019091; Sat, 26 May 2001 22:45:12 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 26 May 2001 22:45:06 +1000 In-Reply-To: (Adrian.Aichner@t-online.de's message of "26 May 2001 12:06:59 +0200") Message-ID: Lines: 24 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "APA" == Adrian Aichner writes: >>>>>>"SY" == Steve Youngs writes: SY> |--==> "APA" == Adrian Aichner writes: APA> Hello All, Hello Steve, APA> many of you must be experiencing the same problems. SY> Not if you're careful. APA> Rephrase that to: Not if your're not using a native Windows XEmacs. APA> Perhaps that is what you mean by being careful :-) Well it wasn't, but if the shoe fits... :-) Seriously, Adrian, it didn't even occur to me that this could be a platform specific problem. And as I don't have access to any Windows machines, I probably won't be able to help, sorry. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From Valdis.Kletnieks@vt.edu Sat May 26 15:36:15 2001 Received: from foo-bar-baz.cc.vt.edu (foo-bar-baz.cc.vt.edu [128.173.14.103]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA17910; Sat, 26 May 2001 15:36:13 -0400 From: Valdis.Kletnieks@vt.edu Received: from foo-bar-baz.cc.vt.edu (valdis@localhost [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.11.3/8.11.3) with ESMTP id f4QJaC123827; Sat, 26 May 2001 15:36:12 -0400 Message-Id: <200105261936.f4QJaC123827@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4+dev To: Steve Youngs Cc: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system In-Reply-To: Your message of "Sat, 26 May 2001 22:26:24 +1000." X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1738021120P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 26 May 2001 15:36:12 -0400 --==_Exmh_1738021120P Content-Type: text/plain; charset=us-ascii On Sat, 26 May 2001 22:26:24 +1000, Steve Youngs said: > Personally, I blame GNU/tar. Try doing this: > > tar cvzf test.tar.gz /some/directory/ > md5sum test.tar.gz > test.md5 > rm test.tar.gz > tar cvzf test.tar.gz /some/directory/ > md5sum test.tar.gz >> test.md5 > cat test.md5 > > For some reason you'll have two different md5's. The i_node.st_atime fields have been changed on the files because the first tar command referenced the files. That's my first guess, anyhow. 'man tar' and look for --atime-preserve. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_1738021120P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOxAFrHAt5Vm009ewEQIjEwCaA4tBXrmlkof6J87OpMPz9mHSjUIAoINo 7OdCqBgIscmZufuP36usuqvb =F2Ye -----END PGP SIGNATURE----- --==_Exmh_1738021120P-- From hniksic@arsdigita.com Sat May 26 15:42:01 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA18131 for ; Sat, 26 May 2001 15:41:59 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 153jwg-0001C1-00 for ; Sat, 26 May 2001 21:41:54 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: BAD: Handling of package-index by package release and install system References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 26 May 2001 21:41:54 +0200 In-Reply-To: (Steve Youngs's message of "26 May 2001 22:26:24 +1000") Message-ID: Lines: 35 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Steve Youngs writes: > Personally, I blame GNU/tar. Try doing this: > > tar cvzf test.tar.gz /some/directory/ > md5sum test.tar.gz > test.md5 > rm test.tar.gz > tar cvzf test.tar.gz /some/directory/ > md5sum test.tar.gz >> test.md5 > cat test.md5 The first fault in the reasoning is that you're actually using two programs: tar and gzip. If I try the test like this: tar cf x.tar test-dir tar cf y.tar test-dir ...the resulting files are the same. However, if I do this: tar czf x.tar.gz test-dir tar czf y.tar.gz test-dir ...they differ. The problem is that `gzip' "helpfully" adds a timestamp to the file, even it is completely unneeded for TAR files which keep their own timestamp information. Hopefully, there is a flag that removes this. So if I try: tar cf - test-dir | gzip -cn > x.tar.gz tar cf - test-dir | gzip -cn > y.tar.gz ...the files are the same. Does this work for you? From hniksic@arsdigita.com Sat May 26 15:42:23 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA18152 for ; Sat, 26 May 2001 15:42:22 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 153jx7-0001CM-00 for ; Sat, 26 May 2001 21:42:21 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: BAD: Handling of package-index by package release and install system References: X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 26 May 2001 21:42:21 +0200 In-Reply-To: (Adrian.Aichner@t-online.de's message of "26 May 2001 14:43:23 +0200") Message-ID: Lines: 6 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Adrian.Aichner@t-online.de (Adrian Aichner) writes: > Could this be some kind of a calendar date, which becomes part of > the tarball and thereby part of the calculation? Yes. See my response to Steven. From Adrian.Aichner@t-online.de Sat May 26 17:29:43 2001 Received: from mailout01.sul.t-online.de (mailout01.sul.t-online.com [194.25.134.80]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA21401; Sat, 26 May 2001 17:29:42 -0400 Received: from fwd03.sul.t-online.de by mailout01.sul.t-online.de with smtp id 153lcw-0007GO-04; Sat, 26 May 2001 23:29:38 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.203]) by fwd03.sul.t-online.com with esmtp id 153ldY-07HWIyC; Sat, 26 May 2001 23:30:16 +0200 To: Steve Youngs Cc: XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 76 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "SY" == Steve Youngs writes: SY> |--==> "APA" == Adrian Aichner writes: >>>>>>> "SY" == Steve Youngs writes: SY> |--==> "APA" == Adrian Aichner writes: APA> Hello All, Hello Steve, APA> many of you must be experiencing the same problems. SY> Not if you're careful. APA> Rephrase that to: Not if your're not using a native Windows APA> XEmacs. Perhaps that is what you mean by being careful :-) SY> Well it wasn't, but if the shoe fits... :-) SY> Seriously, Adrian, it didn't even occur to me that this could SY> be a platform specific problem. And as I don't have access to SY> any Windows machines, I probably won't be able to help, sorry. That's OK. I have stumbled around a bit and here is the story: package-info is created from package-info.in by batch-update-package-info in package-info.el. batch-hack-package-index in hack-package-index.el creates package-index.LATEST.pgp. Both defuns use insert-file-contents-literally to insert file contents. All this literal handling of file content is in vain because package-info.in is not treated as a binary file in CVS. My package-info.in files contain CRLF line-endings when checked out under Windows. The file is literally inserted into package-index.LATEST.pgp and the CR characters cause the replacement of old entries to fail. I think the resulting package-index.LATEST.pgp needs to be a binary file. Windows and MacOS, who make a distinction between text files and binary files, need to be able to create the same file as would be generated on UNIX. I can think of these reasons, why: o PGP signing o MD5 checksum o MULE characters may be embedded in package-info, at least for mule-packages. So, should we make the package-info.in files in the packages tree be of type binary in CVS? Best regards, Adrian SY> -- SY> |---------------------| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |---------------------------------------| -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From ben@666.com Sat May 26 23:46:40 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id XAA04133 for ; Sat, 26 May 2001 23:46:40 -0400 Received: (qmail 8143 invoked by alias); 27 May 2001 03:37:19 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 7083 invoked by uid 0); 27 May 2001 03:36:35 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 27 May 2001 03:36:35 -0000 Message-ID: <3B1076A3.66A6504@666.com> Date: Sat, 26 May 2001 20:38:11 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Stodghill CC: ding@gnus.org, xemacs-beta@xemacs.org Subject: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Stodghill wrote: > > Recipe for disaster: > > milhouse$ uname -a > CYGWIN_NT-5.0 MILHOUSE 1.3.1(0.38/3/2) 2001-04-24 20:01 i686 unknown > milhouse$ xemacs -vanilla > > M-: (setq load-path (cons "/path/for/oort-gnus/" load-path)) > M-x load-library message > M-x message-mail > M-x filladapt-mode > (insert the following in the body of the message) > > this is some citation > > text that needs to be filled. > (now put the cursor on this text and press) > M-q > > XEmacs enters an infinite loop which cannot be broken with C-g. > > For the ding list: Oort v0.03 and filladapt don't work together under > Cygwin XEmacs. This problem does not exist in 5.8.8. > > For the xemacs-beta: It would be really nice if C-g broken out of the > loop. I realize that this may not be possible, though. > > Further details > > o Cygwin 1.3.1, most recent version of everything > o Oort Gnus v0.03 > o xemacs-21.4.3 and xemacs-21.5-b1, up-to-date with pre-release packages. > > If there are any other details that you need, please let me know. [1] i just reenabled BROKEN_SIGIO on cygwin and checked it in. [testing revealed no lockups; last reported lockups were b21, which was ages ago.] [2] "critical quit" C-Sh-g is supposed to break out of all loops, even those where inhibit-quit is set; furthermore, it should give you an immediate backtrace in all circumstances. [it's possible that someone broke this on unix. it was broken on windows until very recently. can someone please verify whether it works on unix?] [3] if you can, please update to the latest xemacs 21.5 cvs on cygwin, and check whether C-g works for you by typing (while t) in a scratch buffer, hitting C-j, then C-g and/or C-Sh-g. > --- > Paul Stodghill > Dept. of Computer Science, Upson Hall, Ithaca, NY 14853 > Phone: 607-254-8838 FAX: 607-255-4428 > http://www.cs.cornell.edu/stodghil/ -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ge204@eng.cam.ac.uk Sun May 27 07:29:10 2001 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA29421; Sun, 27 May 2001 07:29:09 -0400 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by spanner.eng.cam.ac.uk with ESMTP id MAA17535; Sun, 27 May 2001 12:29:07 +0100 (BST) Received: from massalia.eng.cam.ac.uk (via IDENT:mailuser@massalia [129.169.82.65]) by tigger.eng.cam.ac.uk with ESMTP id MAA07436; Sun, 27 May 2001 12:29:05 +0100 (BST) Received: (via ge204@localhost) by massalia.eng.cam.ac.uk id f4RBT4X31539; Sun, 27 May 2001 12:29:04 +0100 To: Martin Buchholz Cc: Hrvoje Niksic , XEmacs Beta List Subject: Re: [BUG] xemacs-21.4.* Digital UNIX and regex.c with REGEX_MALLOC References: <15106.17381.518662.490583@turnbull.sk.tsukuba.ac.jp> <15107.15547.488315.295310@turnbull.sk.tsukuba.ac.jp> <9995-Thu17May2001095512+0100-starksb@ebi.ac.uk> <15111.21486.950587.886157@gargle.gargle.HOWL> From: Gunnar Evermann In-Reply-To: <15111.21486.950587.886157@gargle.gargle.HOWL> Date: 27 May 2001 12:29:04 +0100 Message-ID: Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Martin Buchholz writes: > >>>>> "Hrvoje" == Hrvoje Niksic writes: > > Hrvoje> People don't read PROBLEMS. People prefer programs that work, and I > Hrvoje> can understand that sentiment. It should be really easy to increase > Hrvoje> the stack size programatically. > > Agreed. > > The stack size should be automatically increased. > > Doing it portably requires some autoconfing, etc. > > OSF aka Digital Unix aka Tru64 has a low stack size (2MB), but MacOS X > has an insanely low stack size (512kb), especially considering there > are no backward compatibility considerations. just for reference, in case somebody gets around to implementing & testing this: There were some reports of problems on OpenBSD as well. I think their default limit is 2MB. Gunnar From ge204@eng.cam.ac.uk Sun May 27 07:37:07 2001 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA29631 for ; Sun, 27 May 2001 07:37:06 -0400 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by spanner.eng.cam.ac.uk with ESMTP id MAA18084; Sun, 27 May 2001 12:37:01 +0100 (BST) Received: from massalia.eng.cam.ac.uk (via IDENT:mailuser@massalia [129.169.82.65]) by tigger.eng.cam.ac.uk with ESMTP id MAA07532; Sun, 27 May 2001 12:36:58 +0100 (BST) Received: (via ge204@localhost) by massalia.eng.cam.ac.uk id f4RBawn31545; Sun, 27 May 2001 12:36:58 +0100 To: "Jason R. Mastaler" Cc: Gabe Foster , xemacs-beta@xemacs.org Subject: Re: [21.4.1] png.h errors on mips-sgi-irix6.5 References: <3AF3332F.D4D65685@sgrail.com> From: Gunnar Evermann In-Reply-To: Date: 27 May 2001 12:36:58 +0100 Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Jason R. Mastaler" writes: > Gabe Foster writes: > > > I've seen this problem as well. SGI install an old version of png > > in /usr/include and /usr/lib{n32,64,}. What I did was to point to > > versions I had installed from from SGI's freeware base (and other > > libraries I installed myself in /usr/include.) > > The problem went away after I installed the libpng package from SGI > freeware. Thanks. Could you write this up for our PROBLEMS file, please? thanks. Gunnar From nix@esperi.demon.co.uk Sun May 27 09:30:12 2001 Received: from esperi.demon.co.uk (esperi.demon.co.uk [194.222.138.8]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id JAA00826 for ; Sun, 27 May 2001 09:30:09 -0400 Received: from loki.wkstn.nix (0@loki.wkstn.nix [192.168.1.16]) by esperi.demon.co.uk (8.9.3/8.9.3) with ESMTP id OAA32654; Sun, 27 May 2001 14:21:47 +0100 Received: (from nix@localhost) by loki.wkstn.nix (8.9.3/8.9.3) id OAA13768; Sun, 27 May 2001 14:21:45 +0100 Sender: nix@esperi.demon.co.uk To: Ben Wing Cc: xemacs-beta@xemacs.org Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack References: <87k83al78z.fsf@loki.wkstn.nix> <3B0FA44F.6B1FA8A5@666.com> X-Emacs: Our Lady of Perpetual Garbage Collection From: Nix Date: 27 May 2001 14:21:38 +0100 In-Reply-To: <3B0FA44F.6B1FA8A5@666.com> Message-ID: <87r8xb9bbx.fsf@loki.wkstn.nix> Lines: 167 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Developer-Friendly Unix APIs) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sat, 26 May 2001, Ben Wing yowled: > hi. i've read some of this thread, and i wish you luck. Thank you! > a few comments: > > 1. awhile ago i wrote this: > > http://www.xemacs.org/Architecting-XEmacs/lisp-engine-replacement.html Hmm. Interesting. I agree with most of what that says, and it's nice to see I'm not going down an untrodden thought-path. I disagree that a self-hosting preprocessor (i.e. a preprocessor whose language is Emacs Lisp) would be terribly difficult. The Lisp reader and string manipulation code is fairly self-contained as it goes; rendering it completely so ought not to be too hard. All that would need to be done after that is to produce a bootstrap elisp interpreter by basically taking lread.c and eval.c and tying them together with a framework that simply doesn't bother to GC at all (so the lack of GCPROs in the interpreter is irrelevant). Then the makefile uses that to generate a `real' preprocessor by running it over the Lisp reader, runs *that* preprocessor over the Lisp reader and diffs the two. If there are no differences, we know the preprocessor works, and the makefile proceeds to use it to build all the rest of XEmacs. Self-hosting has a single really dull bit of slogwork (the initial construction of the bootstrap Lisp interpreter), but that only needs to be done occasionally, and it doesn't matter if it gets out of synch with the real Lisp interpreter, as long as it can understand enough of the subset of the language used by the preprocessor to preprocess itself. I also disagree that replacing GCPROs with a conservative collector is necessarily a good idea; I thought so until recently, but if it's already been tried and it was really inefficient; if incorrect identification of possible pointers on the stack was leaking a lot of memory, we can't do that and we need GCPRO. (Or rather, we need automatically inserted GCPROs.) I also don't think we can say anything much about how much time automatically inserted `GCPROs everywhere' can take until we've tried it; updating a GCPRO list is not a very expensive operation, after all. > 2. my biggest concern is "the last 20%". [it worries me, for example, that > michael sperber's student may never get to merging his code and hasn't worked > out his plans to do so.] i have seen a great number of efforts in the past I'm doing *that* now, if you mean merging the gc branch back to the head. (At least, I'm merging it to 2.4, and that's nearly the head as volume-of-changes goes.) > "the last 20%" actually takes at least > 50%-75% of the total time of the project, and isn't the fun part. programmers For me, the *really* fun part will be when I can run XEmacs without either weird GCPRO-related crashes (rare, but how can we ever be sure all of them are gone without automated insertion?) or massive disk churning due to the garbage collector's mega-paging :) > rarely account for this, and so they typically end up biting off more than they > can chew, get stuck somewhere in the middle of the "last 20%", get disheartened > and give up. i recommend that you spend some time right now and [a] consider > what your plan is for (1) getting the code merged, Wrong order. I do the docs *first*; that way I find design faults before the code is written, and don't have to write the docs later. (I just have to revise them.) (In this case it's complicated by needing to understand the system before I write the docs; I'm counting forward-porting Richard's changes as `writing the docs'; see below.) > (2) testing it on all major > platforms and in all important configurations, What's an `important configuration'? I can test on i586-pc-linux-gnu, sparc-sun-solaris2.5.1, hppa2.0-hp-hpux10.20, alphaev56-dec-osf4.0d, i586-pc-cygwin32, and I think I can manage an NT-native Visual C++ build too. I'll be frequently testing on i586-pc-linux-gnu, as it's my development box and I have easy access to it; the others will get big periodic tests. > (3) writing up detailed docs [ala > my XEmacs Internals Manual] so others can maintain it, That happens first :) and any changes I make should I think go into the garbage collection and memory allocation nodes in the internals manual. > and (4) working out any > rough edges [e.g. can we easily configure with your new code either on or off? I *hate* rough edges :) In practice I think configuring with code that rips out GCPRO would have to mean that the GCPROs stay and gets sedded out by configure, or #defined away, and of course that removes all the benefit of removing the GCPROs (said benefit being maintainability, not anything the user sees). GCPRO-removal is one of those things that there's little point configuring out. (Richard's changes, again, probably can't be configured out. Too big, too pervasive. But I'm not sure about this, and I'll *try* to make them configurable out...) The GC changes with functional effect themselves; yes, I plan to make that configurable --- although if it causes functional changes I'll count that as a bug. > in practice we can't afford to throw away the old code until long after the new > code is in place, made the default, and hammered on to no end]; and [b] compute > how much effort you think the "last 20%" will take, and then multiply by 3. 3? You're lucky. I normally multiply by 5 ;) > i don't mean to sound pessimistic; i just really want your project to succeed, This is just allowable paranoia :) `Anything that can go wrong, will'; yes, sure, but then lots of things you didn't think could go wrong will go wrong *too*. > you probably want to reduce the scope of your first pass down to a bare minimum, Forward-porting Richard's changes is pass 1. (And testing it, and documenting it... it appears to be completely undocumented; not even the changelogs are updated. Fixing *that* latter should be fun; I'd like to get real changelog entries if they exist, but... the CVS changelog entries don't really count, they're not detailed enough.) The forward-porting /per se/ shouldn't be too hard. Just a lot of slogwork. Bringing the docs up to date will probably take at *least* as long :) I'm thinking of the forward-port as a documentation job as much as anything else. > i am offering to help you in whatever capacity i can. e.g. i probably have a > better overall sense of how the internals work than anyone else and can help you > understand unclear areas or interactions between areas. also due to unfortunate Thank you! I may well take you up on that :) > personal circumstances i have learned how to do the planning and structuring i I'm perenially disorganized unless I force myself to be organized. As a result, on anything I care about I organize *first* so I can forget about it later on. I already have a plan of attack for the merge, and I know what order I'm doing the rest in and why. (It might change, as is usual with such things...) > mentioned above so that i could get done long and difficult tasks given > sometimes failing motivation or physical ability, and i'll gladly review any I think of this as `rewarding', not `difficult'. I *like* cleaning up horrible messes, because I hate the messes so much (GCPRO sounds like a good candidate ;) ) > plan of action you come up with and/or help you construct such a plan. I may well lob my plan of attack in your direction so you can laugh at it for being hopelessly impractical then :) -- `Technology is meaningless. What matters is how people _think_ of it.' --- Linus Torvalds From rendhalver@users.sourceforge.net Sun May 27 10:30:23 2001 Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA02727 for ; Sun, 27 May 2001 10:30:19 -0400 Received: from ulthwe.dyndns.org (p182-tnt1.brs.ihug.com.au [203.173.188.182]) by new-smtp2.ihug.com.au (8.9.3/8.9.3) with ESMTP id AAA04943; Mon, 28 May 2001 00:30:08 +1000 X-Authentication-Warning: new-smtp2.ihug.com.au: Host p182-tnt1.brs.ihug.com.au [203.173.188.182] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15121.3813.802715.996495@ulthwe.dyndns.org> Date: Mon, 28 May 2001 00:27:49 +1000 To: npak@ispras.ru (Nick Pakoulin) Cc: rendhalver@users.sourceforge.net, Adrian.Aichner@t-online.de (Adrian Aichner), "Stephen J. Turnbull" , Hrvoje Niksic , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge In-Reply-To: References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> <15116.14683.528468.483722@ulthwe.dyndns.org> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Nick Pakoulin writes: > intro: "PB" == Peter Brown writes: > IMHO, eXtensible is a greate idea! > > XEmacs - extensible multi-platform editing and development environment :) > >> The XEmacs Multi-OS Editing & Development Environment XEmacs - Open > >> Source, Multi-platform, Multi-Language, and _More_ Than Just an Editor > >> XEmacs - Open Source, Multi-platform, Multi-Language, and a Way Of Life > >> XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor > >> XEmacs - The Multi-Platform Open Source Editor. XEmacs - the > >> Multi-Platform Open Source Editor and Environment XEmacs - the > >> Multi-Platform Platform XEmacs Multi-Platform Open Source Editor XEmacs, > >> an Open Source Editor for MS Windows and Unix so whats happening with this guys ?? has a decision been made ??? -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From ge204@eng.cam.ac.uk Sun May 27 11:46:53 2001 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA05626 for ; Sun, 27 May 2001 11:46:53 -0400 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by spanner.eng.cam.ac.uk with ESMTP id QAA01592; Sun, 27 May 2001 16:46:47 +0100 (BST) Received: from massalia.eng.cam.ac.uk (via IDENT:mailuser@massalia [129.169.82.65]) by tigger.eng.cam.ac.uk with ESMTP id QAA10435; Sun, 27 May 2001 16:46:45 +0100 (BST) Received: (via ge204@localhost) by massalia.eng.cam.ac.uk id f4RFkjm32116; Sun, 27 May 2001 16:46:45 +0100 To: XEmacs Developers Cc: xemacsbugs@cvs.xemacs.org Subject: Re: smtpmail.el fix for AUTH LOGIN (PR#1687) References: <200105161917.MAA02057@camelot-soft.camelot-soft.com> From: Gunnar Evermann In-Reply-To: <200105161917.MAA02057@camelot-soft.camelot-soft.com> Date: 27 May 2001 16:46:45 +0100 Message-ID: Lines: 65 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Simon, could you look into this? Gunnar donpellegrino@computer.org writes: > Full_Name: Don Pellegrino > OS: Windows 2000 Pro > Version: 21.4 Solid Vapor > mule: no > severity: Aggravating > Submission from: (NULL) (151.197.120.90) > > > The current version of smtpmail.el in the mail-lib package > (mail-lib-1.37-pkg.tar.gz) only supports the SMTP AUTH mechanism "cram-md5". > There is code in the file to handle the SMTP AUTH "login" mechanism but due to > bug/typo the login mechanism is never used. Below are pasted the ediff of the > changes I made and the original file. AUTH LOGIN is now working fine for me. > On another note, perhaps there is an easier way to implemented all of the AUTH > SASL mechanisms by tying some sort of SASL package with the SMTP AUTH function? > Let me know if you need more info on this bug. > > *** C:\DOCUME~1\don\LOCALS~1\Temp\smtpmail.el Wed May 16 15:09:58 2001 > --- C:\DOCUME~1\don\LOCALS~1\Temp\smtpmail.elIUAeow Wed May 16 15:09:58 2001 > *************** > *** 185,191 **** > (defvar smtpmail-queue-index (concat smtpmail-queue-dir > smtpmail-queue-index-file)) > > ! (defconst smtpmail-auth-supported '(cram-md5) > "List of supported SMTP AUTH mechanisms.") > > ;;; > --- 185,191 ---- > (defvar smtpmail-queue-index (concat smtpmail-queue-dir > smtpmail-queue-index-file)) > > ! (defconst smtpmail-auth-supported '(cram-md5 login) > "List of supported SMTP AUTH mechanisms.") > > ;;; > *************** > *** 510,516 **** > (not (integerp (car response-code))) > (>= (car response-code) 400)) > (throw 'done nil))))) > ! ((member 'auth=login supported-extensions) > (smtpmail-send-command process "AUTH LOGIN") > (if (or (null (car (setq response-code (smtpmail-read-response > process)))) > (not (integerp (car response-code))) > --- 510,518 ---- > (not (integerp (car response-code))) > (>= (car response-code) 400)) > (throw 'done nil))))) > ! ( > ! ;(member 'auth=login supported-extensions) > ! (eq mech 'login) > (smtpmail-send-command process "AUTH LOGIN") > (if (or (null (car (setq response-code (smtpmail-read-response > process)))) > (not (integerp (car response-code))) > From Adrian.Aichner@t-online.de Sun May 27 12:12:13 2001 Received: from mailout00.sul.t-online.de (mailout00.sul.t-online.com [194.25.134.16]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA06724 for ; Sun, 27 May 2001 12:12:13 -0400 Received: from fwd05.sul.t-online.de by mailout00.sul.t-online.de with smtp id 15439F-0005au-0E; Sun, 27 May 2001 18:12:09 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.100]) by fwd05.sul.t-online.com with esmtp id 15439y-1RqJiSC; Sun, 27 May 2001 18:12:54 +0200 To: rendhalver@users.sourceforge.net Cc: npak@ispras.ru (Nick Pakoulin), Adrian.Aichner@t-online.de (Adrian Aichner), "Stephen J. Turnbull" , Hrvoje Niksic , XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> <15116.14683.528468.483722@ulthwe.dyndns.org> <15121.3813.802715.996495@ulthwe.dyndns.org> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Peter" == Peter Brown writes: Peter> Nick Pakoulin writes: >> intro: "PB" == Peter Brown writes: >> IMHO, eXtensible is a greate idea! >> >> XEmacs - extensible multi-platform editing and development environment Peter> :) >> >> The XEmacs Multi-OS Editing & Development Environment XEmacs - Open >> >> Source, Multi-platform, Multi-Language, and _More_ Than Just an Editor >> >> XEmacs - Open Source, Multi-platform, Multi-Language, and a Way Of Life >> >> XEmacs - Open Source, Multi-platform, and _More_ Than Just an Editor >> >> XEmacs - The Multi-Platform Open Source Editor. XEmacs - the >> >> Multi-Platform Open Source Editor and Environment XEmacs - the >> >> Multi-Platform Platform XEmacs Multi-Platform Open Source Editor XEmacs, >> >> an Open Source Editor for MS Windows and Unix Peter> so whats happening with this guys ?? Not much. Deciding on names and descriptions by comitee seems to be one of the most difficult things. Peter> has a decision been made ??? No. Peter> -- Peter> ------------------------------------------------------------------------- Peter> Peter Brown Peter> Web Programmer/Sys Admin/Apache Admin Education Development Web Peter> peter@edw.com.au www.edw.com.au Peter> rendhalver@users.sourceforge.net Peter> ------------------------------------------------------------------------- -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From hniksic@arsdigita.com Sun May 27 13:47:07 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA09922 for ; Sun, 27 May 2001 13:47:06 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 1544d6-00062H-00; Sun, 27 May 2001 19:47:04 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List , Ben Wing Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 27 May 2001 19:47:04 +0200 In-Reply-To: <3B1076A3.66A6504@666.com> (Ben Wing's message of "Sat, 26 May 2001 20:38:11 -0700") Message-ID: Lines: 14 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > [2] "critical quit" C-Sh-g is supposed to break out of all loops, even those > where inhibit-quit is set; It does break out of inhibit-quit. C-g doesn't break this, but C-Sh-g does: (let ((inhibit-quit t)) (while t)) However, delays where slow_down_interrupts is involved, such as `connect', are *not* broken with C-Sh-g, and that's extremely annoying. Any way to fix that? From ge204@eng.cam.ac.uk Sun May 27 14:50:19 2001 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA11842 for ; Sun, 27 May 2001 14:50:19 -0400 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by spanner.eng.cam.ac.uk with ESMTP id TAA10277; Sun, 27 May 2001 19:50:09 +0100 (BST) Received: from massalia.eng.cam.ac.uk (via IDENT:mailuser@massalia [129.169.82.65]) by tigger.eng.cam.ac.uk with ESMTP id TAA13023; Sun, 27 May 2001 19:50:07 +0100 (BST) Received: (via ge204@localhost) by massalia.eng.cam.ac.uk id f4RIo7l32560; Sun, 27 May 2001 19:50:07 +0100 To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> From: Gunnar Evermann In-Reply-To: Date: 27 May 2001 19:50:07 +0100 Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hrvoje Niksic writes: > Ben Wing writes: > > > [2] "critical quit" C-Sh-g is supposed to break out of all loops, even those > > where inhibit-quit is set; > > It does break out of inhibit-quit. C-g doesn't break this, but C-Sh-g > does: > > (let ((inhibit-quit t)) > (while t)) > > However, delays where slow_down_interrupts is involved, such as > `connect', are *not* broken with C-Sh-g, and that's extremely > annoying. Any way to fix that? slow_down_interrupts() is not used around connect() anymore. This was discussed here a while ago and Ben recently made the change: 2001-04-23 Ben Wing ---------------- process/SIGIO improvements ------------------- * process-unix.c: don't disable SIGIO and other interrupts unless CONNECT_NEEDS_SLOWED_INTERRUPTS is defined -- don't penalize OS's without bugs. similarly for a freebsd bug that was affecting all OS's. * s\ultrix.h: define CONNECT_NEEDS_SLOWED_INTERRUPTS, since that's the OS mentioned as having a kernel bug. * sysdep.c (request_sigio_on_device): * sysdep.c (unrequest_sigio_on_device): fix SIGIO problems on Linux. add check for O_ASYNC in case it's defined and FASYNC isn't. add comment about other ways to do SIGIO on Linux. From hniksic@arsdigita.com Sun May 27 14:52:22 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA11907 for ; Sun, 27 May 2001 14:52:22 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 1545e5-0006Gz-00; Sun, 27 May 2001 20:52:09 +0200 Sender: hniksic@florida.arsdigita.de To: Gunnar Evermann Cc: XEmacs Beta List Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 27 May 2001 20:52:09 +0200 In-Reply-To: (Gunnar Evermann's message of "27 May 2001 19:50:07 +0100") Message-ID: Lines: 5 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Gunnar Evermann writes: > slow_down_interrupts() is not used around connect() anymore. I see. This is very cool. I'll have to try it out! From simon@josefsson.org Sun May 27 15:16:09 2001 Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA12780 for ; Sun, 27 May 2001 15:16:08 -0400 Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f4RJG9q27694; Sun, 27 May 2001 21:16:09 +0200 To: donpellegrino@computer.org Cc: xemacs-beta@xemacs.org, xemacsbugs@cvs.xemacs.org Subject: Re: smtpmail.el fix for AUTH LOGIN (PR#1687) References: <200105161917.MAA02057@camelot-soft.camelot-soft.com> From: Simon Josefsson In-Reply-To: (Gunnar Evermann's message of "27 May 2001 16:46:45 +0100") Mail-Copies-To: nobody Date: 27 May 2001 21:16:05 +0200 Message-ID: Lines: 22 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii donpellegrino@computer.org writes: > The current version of smtpmail.el in the mail-lib package > (mail-lib-1.37-pkg.tar.gz) only supports the SMTP AUTH mechanism > "cram-md5". There is code in the file to handle the SMTP AUTH > "login" mechanism but due to bug/typo the login mechanism is never > used. Below are pasted the ediff of the changes I made and the > original file. AUTH LOGIN is now working fine for me. Thanks for the patch! It's committed. I was never able to test the AUTH LOGIN stuff, so I didn't know if it worked. (AUTH=LOGIN was never blessed by IETF, I suspect only some Windows server implement it.) > On another note, perhaps there is an easier way to implemented all > of the AUTH SASL mechanisms by tying some sort of SASL package with > the SMTP AUTH function? Yes. I think SLIM does this, but I don't think it has been packaged for XEmacs (even FLIM doesn't seem packaged for XEmacs). Also I'm not sure if SLIM is considered stable. From steve@turnbull.sk.tsukuba.ac.jp Sun May 27 20:21:33 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA22726; Sun, 27 May 2001 20:21:32 -0400 Received: by localhost id m154Amm-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 28 May 2001 09:21:28 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15121.39432.404661.164203@turnbull.sk.tsukuba.ac.jp> Date: Mon, 28 May 2001 09:21:28 +0900 To: "Kirill 'Big K' Katsnelson" Cc: xemacs-beta@xemacs.org, xemacs-review@xemacs.org Subject: Re: [PATCH] Allows preemtion of redisplay In-Reply-To: <4.3.2.7.2.20010525154812.02e386f8@pop> References: <4.3.2.7.2.20010524161505.02de0af8@pop> <4.3.2.7.2.20010525154812.02e386f8@pop> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "kkm" == Kirill 'Big K' Katsnelson writes: kkm> Some time ago, Stephen J. Turnbull wrote... >> I don't understand; the check at l. 6457 looks OK. Comment in >> redisplay_frame() indicates this is intentional. Or do you >> just mean all frames on the current device? That's bad enough >> to justify this patch, though. kkm> Stephen, what comment are you referring to? There's a comment at line 6281 if (preemption_check) { /* The preemption check itself takes a lot of time, so normally don't do it here. We do it if called from Lisp, though (`redisplay-frame'). */ int preempted; REDISPLAY_PREEMPTION_CHECK; if (preempted) return 1; } An identical check is done in redisplay_device() at l 6457, basically the first thing that redisplay_device() does: REDISPLAY_PREEMPTION_CHECK; if (preempted) return 1; kkm> I may have modified the file, so line numbers are off. The lines in your patch were exact, so I assumed redisplay.c is the same in 21.4.3 and 21.5 (the above excerpts are from 21.4.3). kkm> because there was obvious nonsense in the above lines: As I say, it appears to be intentional. A misjudgement, I think after light testing, but intentional. kkm> r_f() never gets preempted, and thus never returns non-zero when kkm> its second parameter equal 0. kkm> That is, preemption never happened! CVS revision 1.1.1.1, kkm> the oldest one, also has the preemption check turned off. AFAICT it happens once per call of redisplay_device(). >> Maybe you should post patches of this type to xemacs-beta? kkm> What I meant by testing was that I wanted everybody to keep kkm> an eye open on glitches in display appearance. Oh I understood that. What I meant is that "count(everybody)" is a lot bigger on xemacs-beta. Everybody on xemacs-beta (pretty much) can read patches; with that and the description they can probably give it a lot more thorough workout than the few on xemacs-review. Especially with the commit-for-review policy, it's important to keep the testers aware of changes where the developers don't fully understand the consequences. kkm> Thank you for checking it, in any case! I'm in swap now, and VM still seems faster. :-) I like this patch, a lot! -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Sun May 27 21:07:33 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA24131; Sun, 27 May 2001 21:07:32 -0400 Received: by localhost id m154BVE-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 28 May 2001 10:07:24 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15121.42188.311896.838961@turnbull.sk.tsukuba.ac.jp> Date: Mon, 28 May 2001 10:07:24 +0900 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Steve Youngs , XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "APA" == Adrian Aichner writes: APA> So, should we make the package-info.in files in the packages APA> tree be of type binary in CVS? No. CVS binary has different semantics from MS-DOS/Mac binary. I think this is a dangerous idea. Fix the files that call i-f-c-l to include text to do a post-processing phase of undossing the buffer. Or maybe you don't need to i-f-c-l at all, just i-f-c. Or maybe the manipulations on package-index should be done on Lisp structures, not on buffer text. I'm working on the package code at the moment, I'll add that to the list. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From youngs@xemacs.org Mon May 28 01:15:36 2001 Received: from mail008.syd.optusnet.com.au (mail008.syd.optusnet.com.au [203.2.75.232]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA00868 for ; Mon, 28 May 2001 01:15:35 -0400 Received: from slackware.mynet.pc (wdcax13-103.dialup.optusnet.com.au [198.142.220.103]) by mail008.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f4S5FRH18859 for ; Mon, 28 May 2001 15:15:28 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f4S10U4n026744; Mon, 28 May 2001 11:00:30 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Subject: gcc-2.95.3 and Athena scrollbars. From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 28 May 2001 11:00:29 +1000 Message-ID: Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Building XEmacs (21.4 and 21.5) with gcc-2.95.3 and Athena scrollbars results in some strange scrollbar behaviour. Sometimes you get scrollbars where you shouldn't (small buffers that wouldn't need them), sometimes you don't get them where you need them (buffers that are longer than the frame size). Also the scrollbars will disappear once they have been moved. The problem goes away if you build with lucid scrollbars, or use gcc-2.95.2. Martin, you were doing something with gcc-2.95.3 a little while back, would this fall into your area of expertise? What can I do to help you with this? -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From kokada@vlsi.kuee.kyoto-u.ac.jp Mon May 28 03:29:30 2001 Received: from inari.kuee.kyoto-u.ac.jp (inari.kuee.kyoto-u.ac.jp [130.54.208.213]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA05357 for ; Mon, 28 May 2001 03:28:58 -0400 Received: from inari.kuee.kyoto-u.ac.jp (inari.kuee.kyoto-u.ac.jp [130.54.208.213]) (authenticated as kokada with DIGEST-MD5) by inari.kuee.kyoto-u.ac.jp (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f4S7Skd4011310 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168bits)) for ; Mon, 28 May 2001 16:28:52 +0900 Date: Mon, 28 May 2001 16:28:46 +0900 Message-ID: <8zji0w5t@opaopa.org> From: Kenichi Okada Subject: Re: smtpmail.el fix for AUTH LOGIN (PR#1687) To: xemacs-beta@xemacs.org In-Reply-To: References: <200105161917.MAA02057@camelot-soft.camelot-soft.com> User-Agent: Wanderlust/2.5.8 (Smooth Criminal) NISEMI/1.14.1 (=?ISO-2022-JP?B?GyRCRXswZjkwGyhC?=) SLIM/1.14.6 (=?ISO-2022-JP?B?GyRCR09ePDFRTiQyPxsoQg==?=) APEL/10.3 MULE XEmacs/21.5 (beta1) (anise) (i686-pc-linux) X-Prom-WL: Prom-WL 2.8.0 (lunafy) (procmail reader for Wanderlust) X-Face: #jr,kSza5vkiq5`E/7Ib$}[\IYN{Tubr>.PT+moICV=Os/#T) Yc@_*)FC-]>5E|d+Eu@4Q+>[:q|w:E-^q:tl+MwljZb=\L!p{h}.Lf(T@_P3Xbpg;OjIDD+o!JrR7E rS8!Cu'c#?I?[Rnn{A_Si`4BpCa'swJd@(W>[A$g#M4YG#:7AKEX4DY,d_VCH{QlX;qz`v`jua5j}s O`6'9-k@gi\~I0MK.,SC2eC_v/65+} simon@josefsson.org (Simon Josefsson) wrote: > > On another note, perhaps there is an easier way to implemented all > > of the AUTH SASL mechanisms by tying some sort of SASL package with > > the SMTP AUTH function? > Yes. I think SLIM does this, but I don't think it has been packaged > for XEmacs (even FLIM doesn't seem packaged for XEmacs). Also I'm not > sure if SLIM is considered stable. SLIM have been integrated into FLIM, which is the main trunk of SLIM. FLIM will be ported to FSF Emacs 21 for leim, so I think SASL API of FLIM is stable. SLIM prepares next mechanisms. "CRAM-MD5" "DIGEST-MD5" "PLAIN" "LOGIN" "ANONYMOUS" "NTLM" "SCRAM-MD5" Regards, -- Kenichi Okada mailto:okada@opaopa.org From sperber@informatik.uni-tuebingen.de Mon May 28 04:56:53 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA08535 for ; Mon, 28 May 2001 04:56:48 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id 43059439; Mon, 28 May 2001 10:56:46 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4S8uiI19928; Mon, 28 May 2001 10:56:44 +0200 (CEST) (envelope-from sperber) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 28 May 2001 10:56:44 +0200 In-Reply-To: (Hrvoje Niksic's message of "23 May 2001 22:03:26 +0200") Message-ID: Lines: 33 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> Raymond Toy writes: >> Then why not use gcl then? Hrvoje> Because it's highly questionable how useful Gcl is. Hrvoje> To be useful in short-term future, an elisp-to-C translator should not Hrvoje> try to reimplement XEmacs from scratch or to turn Elisp into Common Hrvoje> Lisp (or, for that matter, CLtL1). Hrvoje> My favorite strategy for elisp-to-C is the one (I think) originally Hrvoje> proposed by Kyle Jones some time ago: look at the opcodes that our Hrvoje> current compiler generates. Now look at the code in bytecode.c that Hrvoje> interprets it. A simple translator would simply take byte-compiled Hrvoje> code and translate it into C that looks like bytecode.c, but inlined Hrvoje> to directly *do* the stuff that P-code wants to do instead of Hrvoje> interpreting the P-code. Hrvoje> Although this looks simple-minded, I believe it would be a *huge* Hrvoje> speed win over the current virtual machine. This strategy has been used many times before. (In Gofer and MzScheme, to name two examples.) It has its benefits, but a significant speed gain is, perhaps surprisingly at first, usually not among them. (People tend to overestimate the time spent on syntax dispatch.) Of course, I may be underestimating the interpretive overhead in XEmacs, but I rather doubt it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From sperber@informatik.uni-tuebingen.de Mon May 28 04:59:11 2001 Received: from mx1.informatik.uni-tuebingen.de (mx1.Informatik.Uni-Tuebingen.De [134.2.12.5]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA08659 for ; Mon, 28 May 2001 04:59:09 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx1.informatik.uni-tuebingen.de (Postfix) with ESMTP id B0DE043A; Mon, 28 May 2001 10:59:07 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4S8x5g19931; Mon, 28 May 2001 10:59:05 +0200 (CEST) (envelope-from sperber) To: Hrvoje Niksic Cc: XEmacs Beta List Subject: Re: Preprocessor References: <15115.28456.826611.66425@gargle.gargle.HOWL> <15115.47171.280162.963844@gargle.gargle.HOWL> <4nsnhwdk4l.fsf@rtp.ericsson.se> <15116.237.987151.376189@craigl.lanning.net> <4npuczzyoo.fsf@rtp.ericsson.se> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 28 May 2001 10:59:05 +0200 In-Reply-To: (Hrvoje Niksic's message of "23 May 2001 22:03:26 +0200") Message-ID: Lines: 12 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >>>>> "Hrvoje" == Hrvoje Niksic writes: Hrvoje> My favorite strategy for elisp-to-C [...] Yet another strategy is writing a metacircular compiler. A student of mine has one. Preliminary benchmarks indicate it's pretty fast even running *on top* of a byte-code implementation of Scheme. We intend to move to a faster Scheme implementation within the next few weeks. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From rendhalver@users.sourceforge.net Mon May 28 06:58:11 2001 Received: from new-smtp1.ihug.com.au (new-smtp1.ihug.com.au [203.109.250.27]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id GAA12666 for ; Mon, 28 May 2001 06:58:09 -0400 Received: from ulthwe.dyndns.org (p182-tnt1.brs.ihug.com.au [203.173.188.182]) by new-smtp1.ihug.com.au (8.9.3/8.9.3) with ESMTP id UAA30143; Mon, 28 May 2001 20:58:03 +1000 X-Authentication-Warning: new-smtp1.ihug.com.au: Host p182-tnt1.brs.ihug.com.au [203.173.188.182] claimed to be ulthwe.dyndns.org From: Peter Brown Message-ID: <15122.11953.961803.139459@ulthwe.dyndns.org> Date: Mon, 28 May 2001 20:55:45 +1000 To: Jani Averbach Cc: xemacs-beta@xemacs.org Subject: Re: Packages installer doesn't work + other weirdiness In-Reply-To: References: <15117.56613.159294.451271@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Reply-To: rendhalver@users.sourceforge.net Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Jani Averbach writes: > I can't customise efs (The info tells that there is customise group for > efs, but there isn't) or I can't find from help how to change efs to use > ftp-client in the passive mode. So I changed system's ftp binary to > shell-script which calls ftp with -p. That's help, and everything works > after that like charm. the efs customise section is under Options -> Customise -> Emacs -> Files -> Efs have a look there if its not there there is something wrong with your package install -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter@edw.com.au www.edw.com.au rendhalver@users.sourceforge.net ------------------------------------------------------------------------- From steve@turnbull.sk.tsukuba.ac.jp Mon May 28 07:17:20 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA13211 for ; Mon, 28 May 2001 07:17:19 -0400 Received: by localhost id m154L12-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Mon, 28 May 2001 20:16:52 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15122.13220.331387.748948@turnbull.sk.tsukuba.ac.jp> Date: Mon, 28 May 2001 20:16:52 +0900 To: Jani Averbach Cc: xemacs-beta@xemacs.org, sperber@informatik.uni-tuebingen.de Subject: Re: Packages installer doesn't work + other weirdiness In-Reply-To: References: <15117.56613.159294.451271@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "Jani" == Jani Averbach writes: Jani> I can't customise efs (The info tells that there is Jani> customise group for efs, but there isn't) Of course there ... isn't. Not in an XEmacs that hasn't loaded efs yet. Oops. Do M-: (require 'efs) RET and _then_ customize. Follow Options | Emacs | Files | EFS | Programs | EFS FTP Program Arguments from the menubar. (There's probably a shorter path, but that one seems pretty canonical.) Or M-x customize-variable RET efs-ftp-program-arguments RET. Michael, EFS doesn't have custom-load.el. Is there a reason for that? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From aichner@ecf.teradyne.com Mon May 28 08:17:26 2001 Received: from showboat.teradyne.com (showboat.teradyne.com [198.51.251.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA15427; Mon, 28 May 2001 08:17:26 -0400 Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id IAA19867; Mon, 28 May 2001 08:17:20 -0400 (EDT) Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id IAA22154; Mon, 28 May 2001 08:17:08 -0400 (EDT) Received: from D5DC120J.ecf.teradyne.com (d5dc120j.ecf.teradyne.com [131.101.192.101]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with ESMTP id OAA26379; Mon, 28 May 2001 14:14:48 +0200 (MET DST) To: "Stephen J. Turnbull" Cc: Adrian.Aichner@t-online.de (Adrian Aichner), Steve Youngs , XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: <15121.42188.311896.838961@turnbull.sk.tsukuba.ac.jp> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Organization: The XEmacs Project Date: 28 May 2001 14:17:03 +0200 In-Reply-To: <15121.42188.311896.838961@turnbull.sk.tsukuba.ac.jp> Message-ID: Lines: 69 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Stephen" == Stephen J Turnbull writes: >>>>> "APA" == Adrian Aichner writes: APA> So, should we make the package-info.in files in the packages APA> tree be of type binary in CVS? Stephen> No. CVS binary has different semantics from MS-DOS/Mac binary. I Stephen> think this is a dangerous idea. Please explain the danger to me. This excerpt from the CVS manual does not convince me: How to store binary files ========================= There are two issues with using CVS to store binary files. The first is that CVS by default converts line endings between the canonical form in which they are stored in the repository (linefeed only), and the form appropriate to the operating system in use on the client (for example, carriage return followed by line feed for Windows NT). The second is that a binary file might happen to contain data which looks like a keyword (*note Keyword substitution::.), so keyword expansion must be turned off. If we store the file with \n line endings in binary form, that's what we'll have inside and outside of CVS. A nuisance will be that CVS cannot merge these files for us. But XEmacs can. Stephen> Fix the files that call i-f-c-l to include text to do a Stephen> post-processing phase of undossing the buffer. Or maybe Stephen> you don't need to i-f-c-l at all, just i-f-c. Or maybe Perhaps. We would just have to make sure that the resulting package-index.LATEST.pgp gets stored with the same line-endings on all platforms packages can be built on. I presume this would be \n line endings only. Stephen> the manipulations on package-index should be done on Lisp Stephen> structures, not on buffer text. Stephen> I'm working on the package code at the moment, I'll add Stephen> that to the list. Great. I'll leave that in your trusting hands and offer to test your new code on Windows 2000. Best regards, Adrian Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From rpluim@corpemea.BayNetworks.COM Mon May 28 10:31:41 2001 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA20175 for ; Mon, 28 May 2001 10:31:41 -0400 Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA01994; Mon, 28 May 2001 07:29:26 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA26767; Mon, 28 May 2001 10:31:22 -0400 (EDT) Received: from localhost ([47.162.101.154]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id KAA16781; Mon, 28 May 2001 10:31:20 -0400 for Received: from rpluim by localhost with local (Exim 3.22 #1 (Debian)) id 154O39-00084q-00; Mon, 28 May 2001 16:31:15 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="vTqm82SR/V" Content-Transfer-Encoding: 7bit Message-ID: <15122.24883.619177.728520@europe.nortel.com> Date: Mon, 28 May 2001 16:31:15 +0200 To: Nix Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), XEmacs Beta Test Subject: Re: Forthcoming revisions to the garbage collector; crazy huge hack In-Reply-To: <87eltfhgt1.fsf@loki.wkstn.nix> References: <87k83al78z.fsf@loki.wkstn.nix> <15113.60622.238546.663823@gargle.gargle.HOWL> <15114.6040.683679.924905@europe.nortel.com> <87eltfhgt1.fsf@loki.wkstn.nix> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Sender: Robert Pluim --vTqm82SR/V Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit nix@esperi.demon.co.uk writes: > On Tue, 22 May 2001, Robert Pluim spake: > > Michael Sperber writes: > > > - Robert Pluim at one time did hook up the Boehm > > > collector to XEmacs in 1999 with rather disappointing results. > > > > That's a mild way of putting it. My notes from that attempt say > > "Leaks like a piece of string" ;-) The investigation I did seemed to > > indicate that the incidence of false positives on the stack was rather > > high > > Was ALL_INTERIOR_POINTERS turned off? (If it wasn't, I'd expect to see > lots of leakage). > I think it was. Anyway, I hooked boehm 5.3 up to XEmacs 21.5 again last night, which took me all of a half hour, and it still stinks (allocation performance is _terrible_, collection is ok, leakage still seems to occur). I tried to turn on the incremental collector, but that causes crashes (in Lstream code, which I don't understand yet). I don't think this works with --pdump. Tested lightly on i686-pc-linux. gnus works ;-) I'm attaching a diff for anyone interested in playing. I'm sure there's smarter things that can be done to make it work better (I just wholesale turned off the XEmacs collector). You need to add "/where/lib/gc/is/installed/gc.a" to the linker flags for xemacs. Boehm I compiled with the following flags: -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DREDIRECT_MALLOC=GC_malloc Have fun! Robert --vTqm82SR/V Content-Type: text/plain Content-Disposition: inline; filename="boehm.patch" Content-Transfer-Encoding: 7bit Index: src/alloc.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/alloc.c,v retrieving revision 1.51 diff -u -r1.51 alloc.c --- src/alloc.c 2001/05/21 05:26:06 1.51 +++ src/alloc.c 2001/05/28 14:26:29 @@ -3244,6 +3244,7 @@ void garbage_collect_1 (void) { +#if 0 #if MAX_SAVE_STACK > 0 char stack_top_variable; extern char *stack_bottom; @@ -3497,6 +3498,7 @@ UNGCPRO; return; +#endif } /* Debugging aids. */ @@ -3530,6 +3532,7 @@ */ ()) { +#if 0 Lisp_Object pl = Qnil; unsigned int i; int gc_count_vector_total_size = 0; @@ -3620,7 +3623,6 @@ HACK_O_MATIC (cons, "cons-storage", pl); pl = gc_plist_hack ("conses-free", gc_count_num_cons_freelist, pl); pl = gc_plist_hack ("conses-used", gc_count_num_cons_in_use, pl); - /* The things we do for backwards-compatibility */ return list6 (Fcons (make_int (gc_count_num_cons_in_use), @@ -3632,6 +3634,8 @@ make_int (gc_count_string_total_size), make_int (gc_count_vector_total_size), pl); +#endif + return Qt; } #undef HACK_O_MATIC Index: src/emacs.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/emacs.c,v retrieving revision 1.99 diff -u -r1.99 emacs.c --- src/emacs.c 2001/05/10 09:59:56 1.99 +++ src/emacs.c 2001/05/28 14:26:30 @@ -3106,8 +3106,10 @@ conversion is applied everywhere. Don't worry about memory leakage because this call only happens once. */ unexec (filename_ext, symfile_ext, (uintptr_t) my_edata, 0, 0); +#if 0 #ifdef DOUG_LEA_MALLOC free (malloc_state_ptr); +#endif #endif #endif /* not PDUMP */ } Index: src/lisp.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp.h,v retrieving revision 1.51 diff -u -r1.51 lisp.h --- src/lisp.h 2001/05/18 04:39:42 1.51 +++ src/lisp.h 2001/05/28 14:26:31 @@ -1938,6 +1938,7 @@ NNGCPROn(). If you need to nest yet another level, create the appropriate macros. */ +#if 0 #ifdef DEBUG_GCPRO void debug_gcpro1 (char *, int, struct gcpro *, Lisp_Object *); @@ -2097,6 +2098,25 @@ #define NNUNGCPRO ((void) (gcprolist = nngcpro1.next)) #endif /* ! DEBUG_GCPRO */ +#endif +#define GCPRO1(v) +#define GCPRO2(v1,v2) +#define GCPRO3(v1,v2,v3) +#define GCPRO4(v1,v2,v3,v4) +#define GCPRO5(v1,v2,v3,v4,v5) +#define UNGCPRO +#define NGCPRO1(v) +#define NGCPRO2(v1,v2) +#define NGCPRO3(v1,v2,v3) +#define NGCPRO4(v1,v2,v3,v4) +#define NGCPRO5(v1,v2,v3,v4,v5) +#define NUNGCPRO +#define NNGCPRO1(v) +#define NNGCPRO2(v1,v2) +#define NNGCPRO3(v1,v2,v3) +#define NNGCPRO4(v1,v2,v3,v4) +#define NNGCPRO5(v1,v2,v3,v4,v5) +#define NNUNGCPRO /* Another try to fix SunPro C compiler warnings */ /* "end-of-loop code not reached" */ --vTqm82SR/V Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit -- --vTqm82SR/V-- From rpluim@corpemea.BayNetworks.COM Mon May 28 10:34:56 2001 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA20300 for ; Mon, 28 May 2001 10:34:56 -0400 Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA02149 for ; Mon, 28 May 2001 07:32:58 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA26796 for ; Mon, 28 May 2001 10:34:54 -0400 (EDT) Received: from localhost ([47.162.101.154]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id KAA16847; Mon, 28 May 2001 10:34:53 -0400 for Received: from rpluim by localhost with local (Exim 3.22 #1 (Debian)) id 154O6e-000852-00 for ; Mon, 28 May 2001 16:34:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15122.25100.226384.620951@europe.nortel.com> Date: Mon, 28 May 2001 16:34:52 +0200 To: XEmacs Beta Subject: Re: Problem with TAGS, but it's probably me. In-Reply-To: References: X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Sender: Robert Pluim Steve Youngs writes: > I wanted to find something buried deep within the XEmacs source. So I > decided to try out this "TAGS" thing. > > make tags > Tools -> Tags -> Set Tags Table File (set to appropriate file) > Tools -> Tags -> Find Tag > infinite loop (escapable with C-g) > > Is it a problem with me, or with XEmacs (21.5-b1)? I get this as well. I haven't tracked it down yet (I haven't looked very hard either). Robert -- From gshapiro@gshapiro.net Mon May 28 12:51:16 2001 Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA25227; Mon, 28 May 2001 12:51:12 -0400 Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.4/8.11.4) id f4SGp2J44233; Mon, 28 May 2001 09:51:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15122.33270.400900.896756@horsey.gshapiro.net> Date: Mon, 28 May 2001 09:51:02 -0700 From: Gregory Neil Shapiro To: Robert Pluim , Steve Youngs Cc: XEmacs Beta Subject: Re: Problem with TAGS, but it's probably me. In-Reply-To: <15122.25100.226384.620951@europe.nortel.com> References: <15122.25100.226384.620951@europe.nortel.com> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid >> infinite loop (escapable with C-g) >> >> Is it a problem with me, or with XEmacs (21.5-b1)? Robert> I get this as well. I haven't tracked it down yet (I haven't looked Robert> very hard either). I've already reported the bug: http://list-archive.xemacs.org/xemacs-beta/200105/msg00239.html I received no responses. For what it's worth, this patch appears to fix it (not included in the message above): --- etags.el~ Fri May 11 20:11:21 2001 +++ etags.el Wed May 23 10:53:57 2001 @@ -193,7 +193,8 @@ ;; Parent directories (when tags-check-parent-directories-for-tag-files (let ((cur default-directory)) - (while (file-exists-p (setq cur (expand-file-name ".." cur))) + (while (and (file-exists-p (setq cur (expand-file-name ".." cur))) + (not (equal cur "/.."))) (let ((parent-tag-file (expand-file-name "TAGS" cur))) (when (file-readable-p parent-tag-file) (push parent-tag-file result)))))) From rpluim@nortelnetworks.com Mon May 28 13:26:36 2001 Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA26341 for ; Mon, 28 May 2001 13:26:36 -0400 Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f4SHQVt22007 for ; Mon, 28 May 2001 18:26:31 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Mon, 28 May 2001 18:26:07 +0100 Received: from zvb1c002.europe.nortel.com (zvbnc0jb.europe.nortel.com [47.162.88.24]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LSY5W24N; Mon, 28 May 2001 18:26:05 +0100 Received: from localhost (WIBBLE [47.162.101.154]) by zvb1c002.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LM3XMCRV; Mon, 28 May 2001 19:26:05 +0200 Received: from rpluim by localhost with local (Exim 3.22 #1 (Debian)) id 154QmM-0001r2-00; Mon, 28 May 2001 19:26:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15122.35374.218307.776450@europe.nortel.com> Date: Mon, 28 May 2001 19:26:06 +0200 To: Gregory Neil Shapiro , XEmacs Beta Subject: Re: Problem with TAGS, but it's probably me. In-Reply-To: <15122.33270.400900.896756@horsey.gshapiro.net> References: <15122.25100.226384.620951@europe.nortel.com> <15122.33270.400900.896756@horsey.gshapiro.net> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid X-Attribution: Robert From: Robert Pluim Sender: "Robert Pluim" Gregory Neil Shapiro writes: > >> infinite loop (escapable with C-g) > >> > >> Is it a problem with me, or with XEmacs (21.5-b1)? > > Robert> I get this as well. I haven't tracked it down yet (I haven't looked > Robert> very hard either). > > I've already reported the bug: > > http://list-archive.xemacs.org/xemacs-beta/200105/msg00239.html > > I received no responses. For what it's worth, this patch appears to fix it > (not included in the message above): Fixes it for me as well, thanks. Robert -- From wmperry@gnu.org Mon May 28 13:45:12 2001 Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA27053 for ; Mon, 28 May 2001 13:45:07 -0400 Received: from hel.bp.aventail.com ([24.12.70.142]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010528174505.GHYS14705.femail18.sdc1.sfba.home.com@hel.bp.aventail.com>; Mon, 28 May 2001 10:45:05 -0700 Received: from hel.bp.aventail.com (wmperry@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4SHj5Dt000576; Mon, 28 May 2001 12:45:05 -0500 Received: (from wmperry@localhost) by hel.bp.aventail.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4SHj1F8000572; Mon, 28 May 2001 12:45:01 -0500 X-Authentication-Warning: hel.bp.aventail.com: wmperry set sender to wmperry@gnu.org using -f Sender: wmperry@aventail.com To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: XEmacs Beta List , Glyn Millington Subject: Re: [comp.emacs.xemacs] Reluctant Rodent in 21.4.3 X-Now-Listening-To: (null) References: X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 (Adrian.Aichner@t-online.de's message of "26 May 2001 14:40:05 +0200") Message-ID: <8666el9xlu.fsf@hel.bp.aventail.com> Lines: 11 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Urania) MIME-Version: 1.0 Adrian.Aichner@t-online.de (Adrian Aichner) writes: > Hello Glyn, > > I am forwarding your mail to xemacs-beta. > > That's where the XEmacs developers hang out. This looks like the GTK lossage... is you XEmacs compiled with GTK? -bp From stodghil@cs.cornell.edu Mon May 28 13:45:20 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA27070 for ; Mon, 28 May 2001 13:45:20 -0400 Received: from milhouse.cs.cornell.edu.cs.cornell.edu (d7b147.dialup.cornell.edu [128.253.157.147]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id NAA25119; Mon, 28 May 2001 13:45:16 -0400 (EDT) Sender: stodghil@milhouse.cs.cornell.edu To: Ben Wing Cc: ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> From: Paul Stodghill In-Reply-To: <3B1076A3.66A6504@666.com> (Ben Wing's message of "Sat, 26 May 2001 20:38:11 -0700") Message-ID: Date: 28 May 2001 13:44:57 -0400 Lines: 14 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben wrote, > [3] if you can, please update to the latest xemacs 21.5 cvs on cygwin, > and check whether C-g works for you by typing (while t) in a scratch > buffer, hitting C-j, then C-g and/or C-Sh-g. Partial success. (while t) - C-g and C-Sh-g both work. M-q in a "*message* buffer - C-g and C-Sh-g both work. (let ((inhibit-quite t)) (while t) - Neither C-g now C-Sh-g work. Ben, your changes are certainly an improvement. Thanks. From alexm@hsys.msk.ru Mon May 28 13:51:28 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA27400 for ; Mon, 28 May 2001 13:51:27 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp101-9.dialup.mtu-net.ru [212.188.101.9]) by mtu.ru (Postfix) with ESMTP id 06F617323 for ; Mon, 28 May 2001 21:51:20 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 17115 invoked by uid 1000); 28 May 2001 17:45:23 -0000 Sender: alexm@tyranny.hsys.msk.ru X-Comment-To: Adrian Aichner To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge References: <3B09E4EF.F70F890E@666.com> <15115.26782.746855.269957@turnbull.sk.tsukuba.ac.jp> <15116.14683.528468.483722@ulthwe.dyndns.org> <15121.3813.802715.996495@ulthwe.dyndns.org> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: Alexey Mahotkin Date: 28 May 2001 21:45:23 +0400 In-Reply-To: Adrian.Aichner@t-online.de's message of "27 May 2001 18:12:08 +0200" Message-ID: <87ae3xiczw.fsf@tyranny.hsys.msk.ru> Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" >>>>> "APA" == Adrian Aichner writes: >>> >> The XEmacs Multi-OS Editing & Development Environment XEmacs - Open >>> >> Source, Multi-platform, Multi-Language, and _More_ Than Just an >>> Editor >> XEmacs - Open Source, Multi-platform, Multi-Language, and a >>> Way Of Life >> XEmacs - Open Source, Multi-platform, and _More_ Than >>> Just an Editor >> XEmacs - The Multi-Platform Open Source Editor. >>> XEmacs - the >> Multi-Platform Open Source Editor and Environment >>> XEmacs - the >> Multi-Platform Platform XEmacs Multi-Platform Open >>> Source Editor XEmacs, >> an Open Source Editor for MS Windows and Unix Peter> so whats happening with this guys ?? APA> Not much. Deciding on names and descriptions by comitee seems to be APA> one of the most difficult things. Randomly rotate description every two-three days. Lots of fun. --alexm From karlheg@hegbloom.net Mon May 28 14:10:45 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA28217 for ; Mon, 28 May 2001 14:10:44 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4SHWRfr002477 for ; Mon, 28 May 2001 10:32:27 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4SHWRCB002474; Mon, 28 May 2001 10:32:27 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: Re: Problem with TAGS, but it's probably me. References: X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Date: 28 May 2001 10:32:27 -0700 Message-ID: <87u225js5w.fsf@bittersweet.intra.hegbloom.net> Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I've been using the etags.el from GNU Emacs for a long time now because I think it works a lot better. I began using it one day when I was trying to find things in the GNU Libc sources. A tags search using the XEmacs etags would land me one place, while a tags search using the GNU Emacs etags would land me somewhere else... the GNU Emacs etags put me in the right place, while the XEmacs etags did not. Perhaps we should switch to the GNU Emacs etags.el, and merge any features added to our etags into that? IIRC it runs out of the box with only a few minor changes. I wonder if it's worth it to support "gtags" (from BSD "global")? "global" (google for it) makes a berkely DB btree index, afaik. If XEmacs berkeley DB supported a btree index where each key can have more than one value associated with it, we could support "gtags" directly in Lisp. From reneky@stud.ntnu.no Mon May 28 14:11:23 2001 Received: from brev.stud.ntnu.no (brev.stud.ntnu.no [129.241.56.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA28240 for ; Mon, 28 May 2001 14:11:22 -0400 Received: from localhost (localhost [127.0.0.1]) by brev.stud.ntnu.no (Postfix) with ESMTP id C88278012 for ; Mon, 28 May 2001 20:11:21 +0200 (CEST) Received: from jeeves.stud.ntnu.no (jeeves [129.241.56.14]) by brev.stud.ntnu.no (Postfix) with ESMTP id 374E88011 for ; Mon, 28 May 2001 20:11:21 +0200 (CEST) Received: from localhost (reneky@localhost) by jeeves.stud.ntnu.no (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id f4SIBJo08153 for ; Mon, 28 May 2001 20:11:19 +0200 (MET DST) X-Authentication-Warning: jeeves.stud.ntnu.no: reneky owned process doing -bs Date: Mon, 28 May 2001 20:11:19 +0200 (MET DST) From: Rene Kyllingstad To: XEmacs Developers Subject: Re: In Search for better Descriptive Group Name on SourceForge In-Reply-To: <87ae3xiczw.fsf@tyranny.hsys.msk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 On 28 May 2001, Alexey Mahotkin wrote: > >>>>> "APA" == Adrian Aichner writes: > > >>> >> The XEmacs Multi-OS Editing & Development Environment XEmacs - Open > >>> >> Source, Multi-platform, Multi-Language, and _More_ Than Just an > >>> Editor >> XEmacs - Open Source, Multi-platform, Multi-Language, and a > >>> Way Of Life >> XEmacs - Open Source, Multi-platform, and _More_ Than > >>> Just an Editor >> XEmacs - The Multi-Platform Open Source Editor. > >>> XEmacs - the >> Multi-Platform Open Source Editor and Environment > >>> XEmacs - the >> Multi-Platform Platform XEmacs Multi-Platform Open > >>> Source Editor XEmacs, >> an Open Source Editor for MS Windows and Unix XEmacs - development environment / mail&news system / tetris and more! =====\ ``The answer to 'Can XEmacs ... ?' is always yes.'' /=========== ----------------------------------------------------- From karlheg@hegbloom.net Mon May 28 14:14:04 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA28349 for ; Mon, 28 May 2001 14:14:03 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4SIE3fr002710 for ; Mon, 28 May 2001 11:14:03 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4SIE3kZ002706; Mon, 28 May 2001 11:14:03 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta List Subject: Re: [comp.emacs.xemacs] Re: xemacs 21.4.3 will not configure unde suse linux 7.1 References: X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Date: 28 May 2001 11:14:03 -0700 Message-ID: <87ofsdjq8k.fsf@bittersweet.intra.hegbloom.net> Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I just helped a guy yesterday on irc.openprojects.net #emacs who was trying to build XEmacs 21.4.3. He used the irc handle "NoZe". It was failing to configure, was looking for "winspool". I looked in "configure.in" and found the string "winspool", and guessed that it was not detecting X11 for some reason. He said he's got a Suse system but that he hates RPM and never uses it, so I believe that most of his configuration is home-brewed. Perhaps he has Wine installed? I suggested that he use the "--with-msw=no" switch, and that worked. This is somewhat of a showstopper... I am not skilled or knowledgable enough in autoconf and that particular environmental problem to be the person who can fix it... Looking forward to reading the patch that cures this. karlheg From hniksic@arsdigita.com Mon May 28 14:36:29 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA29050 for ; Mon, 28 May 2001 14:36:28 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 154RsR-0002or-00 for ; Mon, 28 May 2001 20:36:27 +0200 Sender: hniksic@florida.arsdigita.de To: XEmacs Beta List Subject: Re: Problem with TAGS, but it's probably me. References: <87u225js5w.fsf@bittersweet.intra.hegbloom.net> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 28 May 2001 20:36:27 +0200 In-Reply-To: <87u225js5w.fsf@bittersweet.intra.hegbloom.net> (karlheg@hegbloom.net's message of "28 May 2001 10:32:27 -0700") Message-ID: Lines: 19 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii karlheg@hegbloom.net (Karl M. Hegbloom) writes: > I've been using the etags.el from GNU Emacs for a long time now > because I think it works a lot better. I began using it one day when > I was trying to find things in the GNU Libc sources. A tags search > using the XEmacs etags would land me one place, while a tags search > using the GNU Emacs etags would land me somewhere else... the GNU > Emacs etags put me in the right place, while the XEmacs etags did > not. XEmacs etags should be fixed. The problem with switching to GNU Emacs etags is that it's not always easy to tell which features are unique to our version. I myself have worked on etags repeatedly and don't remember all the stuff I added or fixed. Switching to GNU Emacs code in proposed fashion should be kept as a last resort. From glyn@mill29.fsnet.co.uk Mon May 28 15:17:31 2001 Received: from mail4.svr.pol.co.uk (mail4.svr.pol.co.uk [195.92.193.211]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA30529 for ; Mon, 28 May 2001 15:17:25 -0400 Received: from modem-32.chartreux.dialup.pol.co.uk ([217.134.68.32] helo=glynthebearded) by mail4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 154SVw-00055K-00; Mon, 28 May 2001 20:17:17 +0100 Received: from glyn by glynthebearded with local (Exim 3.12 #1 (Debian)) id 154SYw-0000VV-00; Mon, 28 May 2001 20:20:22 +0100 To: wmperry@gnu.org (William M. Perry) Cc: Adrian.Aichner@t-online.de (Adrian Aichner), XEmacs Beta List Subject: Re: [comp.emacs.xemacs] Reluctant Rodent in 21.4.3 References: <8666el9xlu.fsf@hel.bp.aventail.com> From: Glyn Millington Date: 28 May 2001 20:20:22 +0100 In-Reply-To: <8666el9xlu.fsf@hel.bp.aventail.com> Message-ID: <878zjhnuvd.fsf@mill29.fsnet.co.uk> Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Glyn Millington wmperry@gnu.org (William M. Perry) writes: > Adrian.Aichner@t-online.de (Adrian Aichner) writes: > > > Hello Glyn, > > > > I am forwarding your mail to xemacs-beta. > > > > That's where the XEmacs developers hang out. > > This looks like the GTK lossage... is you XEmacs compiled with GTK? Certainly is. Forgive me - I'm new to all this - is the "GTK lossage" a bug, and therefore beyond my fixing, or an indication that I am missing a vital library? Many thanks for the response Glyn -- so here we are then.... http://members.tripod.co.uk/Christchurch2000uk ==== Running Debian/Gnu Linux ==== 8:16pm up 3:29, 3 users, load average: 0.18, 0.07, 0.02 From Aki.Vehtari@hut.fi Mon May 28 16:01:48 2001 Received: from zeus.lce.hut.fi (zeus.lce.hut.fi [130.233.245.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA32389 for ; Mon, 28 May 2001 16:01:45 -0400 Received: from chaos.lce.hut.fi (root@chaos.lce.hut.fi [130.233.245.160]) by zeus.lce.hut.fi (8.11.3/8.11.3/Revision: 2.1 Author: kim) with ESMTP id f4SK1c614037 for ; Mon, 28 May 2001 23:01:39 +0300 (EET DST) Received: (from ave@localhost) by chaos.lce.hut.fi (8.11.0/8.11.1) id f4SK1cE19101; Mon, 28 May 2001 23:01:38 +0300 X-Authentication-Warning: chaos.lce.hut.fi: ave set sender to Aki.Vehtari@hut.fi using -f Sender: ave@lce.hut.fi To: xemacs-beta@xemacs.org Subject: gud.el? References: X-No-Archive: yes From: Aki Vehtari In-Reply-To: Date: 28 May 2001 23:01:38 +0300 Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Solid Vapor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Aki" == Aki Vehtari writes 1998-12-09: Aki> Btw. gud.el in XEmacs is dated 1993 and gud.el in emacs-20.3 is Aki> dated 1998. Unfortunately gud.el in emacs-20.3 does not work in Aki> XEmacs and I don't know much work it would need to make it work and "SL" == SL Baur writes 1998-12-10: SL> I've done the initial port of gud.el to XEmacs. It mostly works[1], but SL> it sorely lacks the functionality in gdbsrc.el. Making a gudsrc.el SL> mode is on my list of things to do. ... SL> It was delayed integration into the XEmacs packages pending 21.0 SL> release. I have been using Steve's port of gud.el from Emacs distribution since 1998. I fixed one bug and added XEmacs/Emacs-compatibility and easymenu to it and sent it to xemacs-beta 1998-12-14. Today I noticed that gud.el in XEmacs distribution is still dated 1993 (with couple minor fixes mentioned in ChangeLog), so apparently neither Steve's port or my improvments to it never made it to distribution. gud.el in Emacs distribution and gud.el in XEmacs distribution differ in debugger-specific part of code quite much. Does anyone know is there big difference in functionality (i.e., is there any other reason than cautiousness to not update gud.el)? In gdbsrc.el there is following comment: ;;; gdbsrc.el -- Source-based (as opposed to comint-based) debugger ;; interaction mode eventually, this will be unified with GUD ;; (after gud works reliably w/ XEmacs...) Does that mean that current gud.el in XEmacs distribution does not work realiably w/ XEmacs? I have used Steve's port of gud.el from Emacs distribution because it is only one which works with matlab-shell-mode. Today I updated Steve's port with latest changes in latest Emacs distribution (20.7) and I can post it, if anyone is interested. I can also add to it those small changes made to gud.el in XEmacs distribution that are mentioned in ChangeLog. Aki From ge204@eng.cam.ac.uk Mon May 28 16:26:50 2001 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA00860 for ; Mon, 28 May 2001 16:26:48 -0400 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by spanner.eng.cam.ac.uk with ESMTP id VAA25978 for ; Mon, 28 May 2001 21:26:45 +0100 (BST) Received: from massalia.eng.cam.ac.uk (via IDENT:mailuser@massalia [129.169.82.65]) by tigger.eng.cam.ac.uk with ESMTP id VAA02338 for ; Mon, 28 May 2001 21:26:43 +0100 (BST) Received: (via ge204@localhost) by massalia.eng.cam.ac.uk id f4SKQgf28632; Mon, 28 May 2001 21:26:42 +0100 To: XEmacs Developers Subject: buffers tab From: Gunnar Evermann Date: 28 May 2001 21:26:42 +0100 Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I finally got around to trying the buffers tab for normal work and I must admit that I find it very useful. Great work, Andy! One thing I would love to see is the ability to bind different functions to different mouse-button clicks on the tabs. For example bind button1 to the equivalent of switch-to-buffer and button2 to switch-to-buffer-other-window. Is there an easy way to achieve this? Gunnar From ge204@eng.cam.ac.uk Mon May 28 16:57:18 2001 Received: from spanner.eng.cam.ac.uk (spanner.eng.cam.ac.uk [129.169.8.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA02098 for ; Mon, 28 May 2001 16:57:18 -0400 Received: from tigger.eng.cam.ac.uk (via root@tigger.eng.cam.ac.uk [129.169.80.71]) by spanner.eng.cam.ac.uk with ESMTP id VAA27363; Mon, 28 May 2001 21:57:15 +0100 (BST) Received: from massalia.eng.cam.ac.uk (via IDENT:mailuser@massalia [129.169.82.65]) by tigger.eng.cam.ac.uk with ESMTP id VAA02787; Mon, 28 May 2001 21:57:13 +0100 (BST) Received: (via ge204@localhost) by massalia.eng.cam.ac.uk id f4SKvDX30578; Mon, 28 May 2001 21:57:13 +0100 To: XEmacs Developers Cc: xemacsbugs@cvs.xemacs.org Subject: Re: Opening large file (PR#1659) References: <200104260935.CAA12758@camelot-soft.camelot-soft.com> From: Gunnar Evermann In-Reply-To: <200104260935.CAA12758@camelot-soft.camelot-soft.com> Date: 28 May 2001 21:57:13 +0100 Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii something for our signed/unsigned experts: C_Langmann@gmx.de writes: > Full_Name: Christian Langmann > OS: Windows NT 4.0 > Version: 21.1 (patch 9) > > I tried to open a large ascii-file (3,949,747,976 Bytes) and got the message > "File size is negative" Even if xemacs doesn't support files this big it should still give a more useful error message. Maybe this is fixed in 21.4? Gunnar From hniksic@arsdigita.com Mon May 28 17:18:48 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA02943 for ; Mon, 28 May 2001 17:18:47 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 154UPH-0003LB-00; Mon, 28 May 2001 23:18:31 +0200 Sender: hniksic@florida.arsdigita.de To: Gunnar Evermann Cc: XEmacs Developers , xemacsbugs@cvs.xemacs.org Subject: Re: Opening large file (PR#1659) References: <200104260935.CAA12758@camelot-soft.camelot-soft.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 28 May 2001 23:18:31 +0200 In-Reply-To: (Gunnar Evermann's message of "28 May 2001 21:57:13 +0100") Message-ID: Lines: 49 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Gunnar Evermann writes: > something for our signed/unsigned experts: > > C_Langmann@gmx.de writes: > > > Full_Name: Christian Langmann > > OS: Windows NT 4.0 > > Version: 21.1 (patch 9) > > > > I tried to open a large ascii-file (3,949,747,976 Bytes) and got the message > > "File size is negative" > > Even if xemacs doesn't support files this big it should still give a > more useful error message. In this case XEmacs doesn't seem to be at fault. The offending code in fileio.c looks like this: /* Supposedly happens on VMS. */ if (st.st_size < 0) signal_error (Qfile_error, "File size is negative", Qunbound); /* ... code that checks if st.st_size fits into EMACS_INT. */ So XEmacs is directly using the system API to check the file size, and seems to be getting bogus response. I can imagine that Win32 has a "native" way of checking the file size, and that stat() has been kludged to accept whatever value, even if it goes into the negative range of st_size (which is signed). Under Unix, stat() would fail unless your program were 64-bit enabled. >From this conjecture, I can see two solutions: 1. Remove/comment out the "VMS" check. To be sure that we'll fail, integrate it with the "maximum buffer size exceeded check" below, so that the latter says: if (XINT (end) < 0 || XINT (end) != st.st_size) ... 2. Modify the code so that it uses the correct Win32 call that returns the length of a possibly 2G+-sized file. Then throw "maximum buffer size exceeded". For obvious practical reasons, I think #1 would be the right solution, along with a "Happens on Windows" comment that explains why we're checking for negativeness of XINT (end). From Adrian.Aichner@t-online.de Mon May 28 18:25:09 2001 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA05145 for ; Mon, 28 May 2001 18:25:09 -0400 Received: from fwd07.sul.t-online.de by mailout06.sul.t-online.de with smtp id 154VRk-0005IG-01; Tue, 29 May 2001 00:25:08 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.13]) by fwd07.sul.t-online.com with esmtp id 154VRe-1JUFZgC; Tue, 29 May 2001 00:25:02 +0200 To: XEmacs Beta List Subject: SourceForge shell service is slowly coming back X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net I have been able to update the site manually just now (http://www.us.xemacs.org/). Since I'm failing over to another server from shell1.sourceforge.net upon login I wouldn't call the problem fixed. At least http://www.us.xemacs.org/About/XEmacsServices.html#5 is now updated to document the problem. If you ever find an XEmacs web mirror outdated or behaving funny, try other servers. http://www.xemacs.org and http://www.us.xemacs.org are your best bets, since they are directly updated from CVS commits. Adrian -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From pkrause@soundbite.com Mon May 28 18:58:47 2001 Received: from fenway.corp.soundbite.com ([64.55.62.249]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA06172 for ; Mon, 28 May 2001 18:58:47 -0400 Received: from PKRAUSE.soundbite.com ([10.5.10.241]) by fenway.corp.soundbite.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 28 May 2001 18:58:45 -0400 From: Paul Krause To: xemacs-beta@xemacs.org CC: ben@666.com Subject: Build failure (head): unresolved external symbols Message-ID: X-OriginalArrivalTime: 28 May 2001 22:58:46.0001 (UTC) FILETIME=[BFE0FE10:01C0E7C9] Date: 28 May 2001 18:58:46 -0400 In XEmacs 21.5 (beta1) "anise" [Lucid] (i586-pc-win32) of Sun May 20 2001 on PKRAUSE configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I suspect it was related to Ben's change of 5/23. ---------------------------- revision 1.30 date: 2001/05/23 09:59:45; author: ben; state: Exp; lines: +1 -5 database.c, debug.h, device-tty.c, dired-msw.c, glyphs-msw.c: header cleanups (remove places that directly include a system header file, because we have our own layer to do this more cleanly and portably); indentation fixes. ---------------------------- Build->Build xemacs.exe [F7] -------------------Configuration: xemacs - Win32 Debug-------------------- Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. Creating C:\src\xemacs\nt\..\lib-src\config.values -------------------------------------------------------------------- OS version: Microsoft Windows 2000 [Version 5.00.2195] OS: Windows_NT XEmacs 21.5-b1 \"anise\" configured for `i586-pc-win32'. Building XEmacs in \"C:\\src\\xemacs\\nt\". Using compiler \"cl -nologo -W3 -Od -Zi -ML\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b1\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Compiling in extra debug checks. XEmacs will be slow! -------------------------------------------------------------------- bscmake -nologo -oC:\src\xemacs\nt\..\src\temacs.bsc @bscmake.tmp del bscmake.tmp link.exe @C:\DOCUME~1\PKRAUS~1.PKR\LOCALS~1\Temp\nmb07008. glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_id glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_type glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_validate glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_normalize emacs.obj : error LNK2001: unresolved external symbol _syms_of_glyphs_shared C:\src\xemacs\nt\..\src\temacs.exe : fatal error LNK1120: 5 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. Error executing NMAKE. xemacs.exe - 7 error(s), 0 warning(s) From ben@666.com Mon May 28 19:40:27 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA07574 for ; Mon, 28 May 2001 19:40:27 -0400 Received: (qmail 49318 invoked by alias); 28 May 2001 23:40:25 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 49292 invoked by uid 0); 28 May 2001 23:40:25 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 28 May 2001 23:40:25 -0000 Message-ID: <3B12E24C.BB5F0D15@666.com> Date: Mon, 28 May 2001 16:42:04 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krause CC: xemacs-beta@xemacs.org Subject: Re: Build failure (head): unresolved external symbols References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit glyphs-shared isn't getting compiled. perhaps your xemacs.mak is not up-to-date? Paul Krause wrote: > > In XEmacs 21.5 (beta1) "anise" [Lucid] (i586-pc-win32) of Sun May 20 2001 on PKRAUSE > configured using `configure UNKNOWN' > > Please describe exactly what actions triggered the bug > and the precise symptoms of the bug: > > I suspect it was related to Ben's change of 5/23. > > ---------------------------- > revision 1.30 > date: 2001/05/23 09:59:45; author: ben; state: Exp; lines: +1 -5 > database.c, debug.h, device-tty.c, dired-msw.c, glyphs-msw.c: header > cleanups (remove places that directly include a system > header file, because we have our own layer to do this more cleanly > and portably); indentation fixes. > ---------------------------- > > Build->Build xemacs.exe [F7] > > -------------------Configuration: xemacs - Win32 Debug-------------------- > Microsoft (R) Program Maintenance Utility Version 1.62.7022 > Copyright (C) Microsoft Corp 1988-1997. All rights reserved. > Creating C:\src\xemacs\nt\..\lib-src\config.values > -------------------------------------------------------------------- > OS version: > Microsoft Windows 2000 [Version 5.00.2195] > OS: Windows_NT > XEmacs 21.5-b1 \"anise\" configured for `i586-pc-win32'. > Building XEmacs in \"C:\\src\\xemacs\\nt\". > Using compiler \"cl -nologo -W3 -Od -Zi -ML\". > Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b1\". > Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". > Compiling in support for Microsoft Windows native GUI. > Compiling in support for XPM images. > Compiling in support for GIF images. > Compiling in support for PNG images. > Compiling in support for JPEG images. > Compiling in support for toolbars. > Compiling in support for dialogs. > Compiling in support for widgets. > Compiling in support for native sounds. > Compiling in fast dired implementation. > Compiling in extra debug checks. XEmacs will be slow! > -------------------------------------------------------------------- > bscmake -nologo -oC:\src\xemacs\nt\..\src\temacs.bsc @bscmake.tmp > del bscmake.tmp > link.exe @C:\DOCUME~1\PKRAUS~1.PKR\LOCALS~1\Temp\nmb07008. > glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_id > glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_type > glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_validate > glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_normalize > emacs.obj : error LNK2001: unresolved external symbol _syms_of_glyphs_shared > C:\src\xemacs\nt\..\src\temacs.exe : fatal error LNK1120: 5 unresolved externals > NMAKE : fatal error U1077: 'link.exe' : return code '0x460' > Stop. > Error executing NMAKE. > > xemacs.exe - 7 error(s), 0 warning(s) -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Mon May 28 19:45:50 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id TAA07863 for ; Mon, 28 May 2001 19:45:50 -0400 Received: (qmail 57911 invoked by alias); 28 May 2001 23:45:42 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 57491 invoked by uid 0); 28 May 2001 23:45:26 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 28 May 2001 23:45:26 -0000 Message-ID: <3B12E379.7DAD1FB7@666.com> Date: Mon, 28 May 2001 16:47:05 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hrvoje Niksic CC: XEmacs Beta List Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hrvoje Niksic wrote: > > Ben Wing writes: > > > [2] "critical quit" C-Sh-g is supposed to break out of all loops, even those > > where inhibit-quit is set; > > It does break out of inhibit-quit. C-g doesn't break this, but C-Sh-g > does: > > (let ((inhibit-quit t)) > (while t)) > > However, delays where slow_down_interrupts is involved, such as > `connect', are *not* broken with C-Sh-g, and that's extremely > annoying. Any way to fix that? never, or only after 15 seconds? what is the specific example? i recently checked in code that doesn't slow down interrupts during connect except on Ultrix. C-g should break immediately. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From wmperry@gnu.org Mon May 28 20:36:53 2001 Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA09779 for ; Mon, 28 May 2001 20:36:53 -0400 Received: from hel.bp.aventail.com ([24.12.70.142]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010529003652.TIMN14705.femail18.sdc1.sfba.home.com@hel.bp.aventail.com>; Mon, 28 May 2001 17:36:52 -0700 Received: from hel.bp.aventail.com (wmperry@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4T0apDt007780; Mon, 28 May 2001 19:36:51 -0500 Received: (from wmperry@localhost) by hel.bp.aventail.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4T0aoLl007776; Mon, 28 May 2001 19:36:50 -0500 X-Authentication-Warning: hel.bp.aventail.com: wmperry set sender to wmperry@gnu.org using -f Sender: wmperry@aventail.com To: Glyn Millington Cc: Adrian.Aichner@t-online.de (Adrian Aichner), XEmacs Beta List Subject: Re: [comp.emacs.xemacs] Reluctant Rodent in 21.4.3 X-Now-Listening-To: george_of_the_jungle_theme References: <8666el9xlu.fsf@hel.bp.aventail.com> <878zjhnuvd.fsf@mill29.fsnet.co.uk> X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 (Glyn Millington's message of "28 May 2001 20:20:22 +0100") Message-ID: <8666el7zz1.fsf@hel.bp.aventail.com> Lines: 25 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Urania) MIME-Version: 1.0 Glyn Millington writes: > wmperry@gnu.org (William M. Perry) writes: > > > Adrian.Aichner@t-online.de (Adrian Aichner) writes: > > > > > Hello Glyn, > > > > > > I am forwarding your mail to xemacs-beta. > > > > > > That's where the XEmacs developers hang out. > > > > This looks like the GTK lossage... is you XEmacs compiled with GTK? > > Certainly is. Forgive me - I'm new to all this - is the "GTK lossage" a > bug, and therefore beyond my fixing, or an indication that I am missing a > vital library? It is a bug in the XEmacs/GTK port - I've been trying to track down a fix, but have not had any luck. Nothing wrong with your setup. You can select with the keyboard or with double/triple clicks though. -bp -- Ceterum censeo vi esse delendam From pkrause@soundbite.com Mon May 28 21:36:15 2001 Received: from fenway.corp.soundbite.com ([64.55.62.249]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA12281 for ; Mon, 28 May 2001 21:36:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: Build failure (head): unresolved external symbols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 May 2001 21:36:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Build failure (head): unresolved external symbols Thread-Index: AcDnz5UGfEqeDWVqS8ifNUo55EP7ogADi0Tg From: "Paul Krause" To: "Ben Wing" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id VAA12281 My xemacs.mak looks up-to-date. The only difference is that patch I submitted earlier today. C:\src\xemacs\nt>cvs diff xemacs.mak Index: xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.69 diff -u -r1.69 xemacs.mak --- xemacs.mak 2001/05/27 10:50:44 1.69 +++ xemacs.mak 2001/05/29 01:21:13 @@ -327,7 +327,7 @@ # much backslash quoting. This does not happen, of course, with a non- # Cygwin Perl, so in that circumstance, you'd be screwed and would have # to fix this Makefile to not have a special Cygwin case. -! if defined(_) +! if defined(_) || defined(CYGWIN_PATH) || [perl -e "exit $$^O == 'cygwin';"] ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; s/^\\x23e/!e/;" \ -e "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2/;" \ C:\src\xemacs\nt> Ben is right about glyphs-shared not being compiled. Here's the full build output. It's not there. Deleting intermediate files and output files for project 'xemacs - Win32 Debug'. --------------------Configuration: xemacs - Win32 Debug-------------------- Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. WARNING: Compiling without dependency information. Creating C:\src\xemacs\nt\..\lib-src\config.values -------------------------------------------------------------------- OS version: Microsoft Windows 2000 [Version 5.00.2195] OS: Windows_NT XEmacs 21.5-b1 \"anise\" configured for `i586-pc-win32'. Building XEmacs in \"C:\\src\\xemacs\\nt\". Using compiler \"cl -nologo -W3 -Od -Zi -ML\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b1\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Compiling in extra debug checks. XEmacs will be slow! Disabling non-essential build actions. Use with care! -------------------------------------------------------------------- A subdirectory or file C:\src\xemacs\nt\..\nt\obj already exists. 1 File(s) copied 1 File(s) copied 1 File(s) copied cl -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -FoC:\src\xemacs\nt\..\nt\obj\ lastfile.obj -FdC:\src\xemacs\nt\..\nt\obj\lastfile -c C:\src\xemacs\nt\..\src\lastfile.c lastfile.c link.exe -lib -nologo -out:C:\src\xemacs\nt\..\nt\obj\lastfile.lib C:\src\xemacs\nt\..\nt\obj\lastfile.obj cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/etags.exe C:\src\xemacs\nt\..\lib-src/etags.c C:\src\xemacs\nt\..\lib-src/getopt.c C:\src\xemacs\nt\ ..\lib-src/getopt1.c C:\src\xemacs\nt\..\lib-src/../src/regex.c -link -incremental:no setargv.obj etags.c getopt.c getopt1.c regex.c Generating Code... cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/hexl.exe C:\src\xemacs\nt\..\lib-src\hexl.c -link -incremental:no setargv.obj hexl.c cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/i.exe C:\src\xemacs\nt\..\lib-src\i.c -link -incremental:no setargv.obj i.c cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/make-docfile.exe C:\src\xemacs\nt\..\lib-src\make-docfile.c -link -incremental:no setargv.obj make-docfile.c cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/mmencode.exe C:\src\xemacs\nt\..\lib-src\mmencode.c -link -incremental:no setargv.obj mmencode.c cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/movemail.exe C:\src\xemacs\nt\..\lib-src/movemail.c C:\src\xemacs\nt\..\lib-src/pop.c C:\src\xemacs\ nt\..\lib-src/getopt.c C:\src\xemacs\nt\..\lib-src/getopt1.c C:\src\xemacs\nt\..\lib-src/../src/regex.c wsock32.lib -link -incremental:no movemail.c pop.c getopt.c getopt1.c regex.c Generating Code... cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/sorted-doc.exe C:\src\xemacs\nt\..\lib-src\sorted-doc.c -link -incremental:no setargv.obj sorted-doc.c cd C:\src\xemacs\nt\..\nt cd C:\src\xemacs\nt\..\lib-src cl -I. -IC:\src\xemacs\nt\../src -IC:\src\xemacs\nt\../nt/inc -DHAVE_CONFIG_H -DWIN32_NATIVE -nologo -W3 -Od -Zi -ML -FeC:\src\xemacs\nt\..\lib-src/wakeup.exe C:\src\xemacs\nt\..\lib-src\wakeup.c -link -incremental:no setargv.obj wakeup.c cd C:\src\xemacs\nt\..\nt nmake -nologo -f minitar.mak ZLIB="c:\src\zlib-1.1.3" NT="C:\src\xemacs\nt\..\nt" LIB_SRC="C:\src\xemacs\nt\..\lib-src" cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\console-msw.c -FoC:\src\xem acs\nt\..\nt\obj\console-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\console-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb console-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\device-msw.c -FoC:\src\xema cs\nt\..\nt\obj\device-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\device-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb device-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\event-msw.c -FoC:\src\xemac s\nt\..\nt\obj\event-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\event-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb event-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\frame-msw.c -FoC:\src\xemac s\nt\..\nt\obj\frame-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\frame-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb frame-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\glyphs-msw.c -FoC:\src\xema cs\nt\..\nt\obj\glyphs-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\glyphs-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb glyphs-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\gui-msw.c -FoC:\src\xemacs\ nt\..\nt\obj\gui-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\gui-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb gui-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\menubar-msw.c -FoC:\src\xem acs\nt\..\nt\obj\menubar-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\menubar-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb menubar-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\objects-msw.c -FoC:\src\xem acs\nt\..\nt\obj\objects-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\objects-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb objects-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\redisplay-msw.c -FoC:\src\x emacs\nt\..\nt\obj\redisplay-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\redisplay-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb redisplay-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\scrollbar-msw.c -FoC:\src\x emacs\nt\..\nt\obj\scrollbar-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\scrollbar-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb scrollbar-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\select-msw.c -FoC:\src\xema cs\nt\..\nt\obj\select-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\select-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb select-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dired-msw.c -FoC:\src\xemac s\nt\..\nt\obj\dired-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\dired-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dired-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\toolbar.c -FoC:\src\xemacs\ nt\..\nt\obj\toolbar.obj -FrC:\src\xemacs\nt\..\nt\obj\toolbar.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb toolbar.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\toolbar-msw.c -FoC:\src\xem acs\nt\..\nt\obj\toolbar-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\toolbar-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb toolbar-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dialog.c -FoC:\src\xemacs\n t\..\nt\obj\dialog.obj -FrC:\src\xemacs\nt\..\nt\obj\dialog.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dialog.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dialog-msw.c -FoC:\src\xema cs\nt\..\nt\obj\dialog-msw.obj -FrC:\src\xemacs\nt\..\nt\obj\dialog-msw.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dialog-msw.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dgif_lib.c -FoC:\src\xemacs \nt\..\nt\obj\dgif_lib.obj -FrC:\src\xemacs\nt\..\nt\obj\dgif_lib.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dgif_lib.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\gif_io.c -FoC:\src\xemacs\n t\..\nt\obj\gif_io.obj -FrC:\src\xemacs\nt\..\nt\obj\gif_io.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb gif_io.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\debug.c -FoC:\src\xemacs\nt \..\nt\obj\debug.obj -FrC:\src\xemacs\nt\..\nt\obj\debug.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb debug.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\tests.c -FoC:\src\xemacs\nt \..\nt\obj\tests.obj -FrC:\src\xemacs\nt\..\nt\obj\tests.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb tests.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\free-hook.c -FoC:\src\xemac s\nt\..\nt\obj\free-hook.obj -FrC:\src\xemacs\nt\..\nt\obj\free-hook.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb free-hook.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\gmalloc.c -FoC:\src\xemacs\ nt\..\nt\obj\gmalloc.obj -FrC:\src\xemacs\nt\..\nt\obj\gmalloc.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb gmalloc.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\ntheap.c -FoC:\src\xemacs\n t\..\nt\obj\ntheap.obj -FrC:\src\xemacs\nt\..\nt\obj\ntheap.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb ntheap.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\vm-limit.c -FoC:\src\xemacs \nt\..\nt\obj\vm-limit.obj -FrC:\src\xemacs\nt\..\nt\obj\vm-limit.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb vm-limit.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\unexnt.c -FoC:\src\xemacs\n t\..\nt\obj\unexnt.obj -FrC:\src\xemacs\nt\..\nt\obj\unexnt.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb unexnt.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\abbrev.c -FoC:\src\xemacs\n t\..\nt\obj\abbrev.obj -FrC:\src\xemacs\nt\..\nt\obj\abbrev.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb abbrev.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\alloc.c -FoC:\src\xemacs\nt \..\nt\obj\alloc.obj -FrC:\src\xemacs\nt\..\nt\obj\alloc.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb alloc.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\blocktype.c -FoC:\src\xemac s\nt\..\nt\obj\blocktype.obj -FrC:\src\xemacs\nt\..\nt\obj\blocktype.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb blocktype.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\buffer.c -FoC:\src\xemacs\n t\..\nt\obj\buffer.obj -FrC:\src\xemacs\nt\..\nt\obj\buffer.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb buffer.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\bytecode.c -FoC:\src\xemacs \nt\..\nt\obj\bytecode.obj -FrC:\src\xemacs\nt\..\nt\obj\bytecode.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb bytecode.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\callint.c -FoC:\src\xemacs\ nt\..\nt\obj\callint.obj -FrC:\src\xemacs\nt\..\nt\obj\callint.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb callint.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\callproc.c -FoC:\src\xemacs \nt\..\nt\obj\callproc.obj -FrC:\src\xemacs\nt\..\nt\obj\callproc.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb callproc.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\casefiddle.c -FoC:\src\xema cs\nt\..\nt\obj\casefiddle.obj -FrC:\src\xemacs\nt\..\nt\obj\casefiddle.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb casefiddle.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\casetab.c -FoC:\src\xemacs\ nt\..\nt\obj\casetab.obj -FrC:\src\xemacs\nt\..\nt\obj\casetab.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb casetab.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\chartab.c -FoC:\src\xemacs\ nt\..\nt\obj\chartab.obj -FrC:\src\xemacs\nt\..\nt\obj\chartab.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb chartab.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\cmdloop.c -FoC:\src\xemacs\ nt\..\nt\obj\cmdloop.obj -FrC:\src\xemacs\nt\..\nt\obj\cmdloop.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb cmdloop.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\cmds.c -FoC:\src\xemacs\nt\ ..\nt\obj\cmds.obj -FrC:\src\xemacs\nt\..\nt\obj\cmds.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb cmds.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\console-stream.c -FoC:\src\ xemacs\nt\..\nt\obj\console-stream.obj -FrC:\src\xemacs\nt\..\nt\obj\console-stream.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb console-stream.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\console.c -FoC:\src\xemacs\ nt\..\nt\obj\console.obj -FrC:\src\xemacs\nt\..\nt\obj\console.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb console.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\data.c -FoC:\src\xemacs\nt\ ..\nt\obj\data.obj -FrC:\src\xemacs\nt\..\nt\obj\data.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb data.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\device.c -FoC:\src\xemacs\n t\..\nt\obj\device.obj -FrC:\src\xemacs\nt\..\nt\obj\device.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb device.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dired.c -FoC:\src\xemacs\nt \..\nt\obj\dired.obj -FrC:\src\xemacs\nt\..\nt\obj\dired.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dired.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\doc.c -FoC:\src\xemacs\nt\. .\nt\obj\doc.obj -FrC:\src\xemacs\nt\..\nt\obj\doc.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb doc.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\doprnt.c -FoC:\src\xemacs\n t\..\nt\obj\doprnt.obj -FrC:\src\xemacs\nt\..\nt\obj\doprnt.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb doprnt.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dragdrop.c -FoC:\src\xemacs \nt\..\nt\obj\dragdrop.obj -FrC:\src\xemacs\nt\..\nt\obj\dragdrop.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dragdrop.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\dynarr.c -FoC:\src\xemacs\n t\..\nt\obj\dynarr.obj -FrC:\src\xemacs\nt\..\nt\obj\dynarr.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb dynarr.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\editfns.c -FoC:\src\xemacs\ nt\..\nt\obj\editfns.obj -FrC:\src\xemacs\nt\..\nt\obj\editfns.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb editfns.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\elhash.c -FoC:\src\xemacs\n t\..\nt\obj\elhash.obj -FrC:\src\xemacs\nt\..\nt\obj\elhash.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb elhash.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\emacs.c -FoC:\src\xemacs\nt \..\nt\obj\emacs.obj -FrC:\src\xemacs\nt\..\nt\obj\emacs.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb emacs.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\eval.c -FoC:\src\xemacs\nt\ ..\nt\obj\eval.obj -FrC:\src\xemacs\nt\..\nt\obj\eval.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb eval.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\event-stream.c -FoC:\src\xe macs\nt\..\nt\obj\event-stream.obj -FrC:\src\xemacs\nt\..\nt\obj\event-stream.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb event-stream.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\events.c -FoC:\src\xemacs\n t\..\nt\obj\events.obj -FrC:\src\xemacs\nt\..\nt\obj\events.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb events.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\extents.c -FoC:\src\xemacs\ nt\..\nt\obj\extents.obj -FrC:\src\xemacs\nt\..\nt\obj\extents.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb extents.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\faces.c -FoC:\src\xemacs\nt \..\nt\obj\faces.obj -FrC:\src\xemacs\nt\..\nt\obj\faces.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb faces.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\file-coding.c -FoC:\src\xem acs\nt\..\nt\obj\file-coding.obj -FrC:\src\xemacs\nt\..\nt\obj\file-coding.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb file-coding.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\fileio.c -FoC:\src\xemacs\n t\..\nt\obj\fileio.obj -FrC:\src\xemacs\nt\..\nt\obj\fileio.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb fileio.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\filemode.c -FoC:\src\xemacs \nt\..\nt\obj\filemode.obj -FrC:\src\xemacs\nt\..\nt\obj\filemode.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb filemode.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\floatfns.c -FoC:\src\xemacs \nt\..\nt\obj\floatfns.obj -FrC:\src\xemacs\nt\..\nt\obj\floatfns.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb floatfns.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\fns.c -FoC:\src\xemacs\nt\. .\nt\obj\fns.obj -FrC:\src\xemacs\nt\..\nt\obj\fns.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb fns.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\font-lock.c -FoC:\src\xemac s\nt\..\nt\obj\font-lock.obj -FrC:\src\xemacs\nt\..\nt\obj\font-lock.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb font-lock.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\frame.c -FoC:\src\xemacs\nt \..\nt\obj\frame.obj -FrC:\src\xemacs\nt\..\nt\obj\frame.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb frame.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\general.c -FoC:\src\xemacs\ nt\..\nt\obj\general.obj -FrC:\src\xemacs\nt\..\nt\obj\general.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb general.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\getloadavg.c -FoC:\src\xema cs\nt\..\nt\obj\getloadavg.obj -FrC:\src\xemacs\nt\..\nt\obj\getloadavg.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb getloadavg.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\glyphs.c -FoC:\src\xemacs\n t\..\nt\obj\glyphs.obj -FrC:\src\xemacs\nt\..\nt\obj\glyphs.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb glyphs.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\glyphs-eimage.c -FoC:\src\x emacs\nt\..\nt\obj\glyphs-eimage.obj -FrC:\src\xemacs\nt\..\nt\obj\glyphs-eimage.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb glyphs-eimage.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\glyphs-widget.c -FoC:\src\x emacs\nt\..\nt\obj\glyphs-widget.obj -FrC:\src\xemacs\nt\..\nt\obj\glyphs-widget.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb glyphs-widget.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\gui.c -FoC:\src\xemacs\nt\. .\nt\obj\gui.obj -FrC:\src\xemacs\nt\..\nt\obj\gui.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb gui.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\gutter.c -FoC:\src\xemacs\n t\..\nt\obj\gutter.obj -FrC:\src\xemacs\nt\..\nt\obj\gutter.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb gutter.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\hash.c -FoC:\src\xemacs\nt\ ..\nt\obj\hash.obj -FrC:\src\xemacs\nt\..\nt\obj\hash.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb hash.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\indent.c -FoC:\src\xemacs\n t\..\nt\obj\indent.obj -FrC:\src\xemacs\nt\..\nt\obj\indent.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb indent.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\imgproc.c -FoC:\src\xemacs\ nt\..\nt\obj\imgproc.obj -FrC:\src\xemacs\nt\..\nt\obj\imgproc.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb imgproc.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\insdel.c -FoC:\src\xemacs\n t\..\nt\obj\insdel.obj -FrC:\src\xemacs\nt\..\nt\obj\insdel.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb insdel.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\intl.c -FoC:\src\xemacs\nt\ ..\nt\obj\intl.obj -FrC:\src\xemacs\nt\..\nt\obj\intl.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb intl.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\keymap.c -FoC:\src\xemacs\n t\..\nt\obj\keymap.obj -FrC:\src\xemacs\nt\..\nt\obj\keymap.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb keymap.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\line-number.c -FoC:\src\xem acs\nt\..\nt\obj\line-number.obj -FrC:\src\xemacs\nt\..\nt\obj\line-number.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb line-number.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\lread.c -FoC:\src\xemacs\nt \..\nt\obj\lread.obj -FrC:\src\xemacs\nt\..\nt\obj\lread.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb lread.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\lstream.c -FoC:\src\xemacs\ nt\..\nt\obj\lstream.obj -FrC:\src\xemacs\nt\..\nt\obj\lstream.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb lstream.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\macros.c -FoC:\src\xemacs\n t\..\nt\obj\macros.obj -FrC:\src\xemacs\nt\..\nt\obj\macros.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb macros.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\menubar.c -FoC:\src\xemacs\ nt\..\nt\obj\menubar.obj -FrC:\src\xemacs\nt\..\nt\obj\menubar.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb menubar.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\marker.c -FoC:\src\xemacs\n t\..\nt\obj\marker.obj -FrC:\src\xemacs\nt\..\nt\obj\marker.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb marker.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\md5.c -FoC:\src\xemacs\nt\. .\nt\obj\md5.obj -FrC:\src\xemacs\nt\..\nt\obj\md5.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb md5.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\minibuf.c -FoC:\src\xemacs\ nt\..\nt\obj\minibuf.obj -FrC:\src\xemacs\nt\..\nt\obj\minibuf.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb minibuf.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\nt.c -FoC:\src\xemacs\nt\.. \nt\obj\nt.obj -FrC:\src\xemacs\nt\..\nt\obj\nt.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb nt.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\ntplay.c -FoC:\src\xemacs\n t\..\nt\obj\ntplay.obj -FrC:\src\xemacs\nt\..\nt\obj\ntplay.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb ntplay.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\ntproc.c -FoC:\src\xemacs\n t\..\nt\obj\ntproc.obj -FrC:\src\xemacs\nt\..\nt\obj\ntproc.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb ntproc.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\objects.c -FoC:\src\xemacs\ nt\..\nt\obj\objects.obj -FrC:\src\xemacs\nt\..\nt\obj\objects.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb objects.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\opaque.c -FoC:\src\xemacs\n t\..\nt\obj\opaque.obj -FrC:\src\xemacs\nt\..\nt\obj\opaque.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb opaque.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\print.c -FoC:\src\xemacs\nt \..\nt\obj\print.obj -FrC:\src\xemacs\nt\..\nt\obj\print.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb print.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\process.c -FoC:\src\xemacs\ nt\..\nt\obj\process.obj -FrC:\src\xemacs\nt\..\nt\obj\process.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb process.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\process-nt.c -FoC:\src\xema cs\nt\..\nt\obj\process-nt.obj -FrC:\src\xemacs\nt\..\nt\obj\process-nt.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb process-nt.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\profile.c -FoC:\src\xemacs\ nt\..\nt\obj\profile.obj -FrC:\src\xemacs\nt\..\nt\obj\profile.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb profile.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\rangetab.c -FoC:\src\xemacs \nt\..\nt\obj\rangetab.obj -FrC:\src\xemacs\nt\..\nt\obj\rangetab.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb rangetab.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\realpath.c -FoC:\src\xemacs \nt\..\nt\obj\realpath.obj -FrC:\src\xemacs\nt\..\nt\obj\realpath.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb realpath.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\redisplay-output.c -FoC:\sr c\xemacs\nt\..\nt\obj\redisplay-output.obj -FrC:\src\xemacs\nt\..\nt\obj\redisplay-output.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb redisplay-output.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\redisplay.c -FoC:\src\xemac s\nt\..\nt\obj\redisplay.obj -FrC:\src\xemacs\nt\..\nt\obj\redisplay.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb redisplay.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\regex.c -FoC:\src\xemacs\nt \..\nt\obj\regex.obj -FrC:\src\xemacs\nt\..\nt\obj\regex.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb regex.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\scrollbar.c -FoC:\src\xemac s\nt\..\nt\obj\scrollbar.obj -FrC:\src\xemacs\nt\..\nt\obj\scrollbar.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb scrollbar.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\search.c -FoC:\src\xemacs\n t\..\nt\obj\search.obj -FrC:\src\xemacs\nt\..\nt\obj\search.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb search.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\select.c -FoC:\src\xemacs\n t\..\nt\obj\select.obj -FrC:\src\xemacs\nt\..\nt\obj\select.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb select.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\signal.c -FoC:\src\xemacs\n t\..\nt\obj\signal.obj -FrC:\src\xemacs\nt\..\nt\obj\signal.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb signal.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\sound.c -FoC:\src\xemacs\nt \..\nt\obj\sound.obj -FrC:\src\xemacs\nt\..\nt\obj\sound.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb sound.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\specifier.c -FoC:\src\xemac s\nt\..\nt\obj\specifier.obj -FrC:\src\xemacs\nt\..\nt\obj\specifier.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb specifier.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\strftime.c -FoC:\src\xemacs \nt\..\nt\obj\strftime.obj -FrC:\src\xemacs\nt\..\nt\obj\strftime.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb strftime.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\symbols.c -FoC:\src\xemacs\ nt\..\nt\obj\symbols.obj -FrC:\src\xemacs\nt\..\nt\obj\symbols.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb symbols.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\syntax.c -FoC:\src\xemacs\n t\..\nt\obj\syntax.obj -FrC:\src\xemacs\nt\..\nt\obj\syntax.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb syntax.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\sysdep.c -FoC:\src\xemacs\n t\..\nt\obj\sysdep.obj -FrC:\src\xemacs\nt\..\nt\obj\sysdep.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb sysdep.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\tparam.c -FoC:\src\xemacs\n t\..\nt\obj\tparam.obj -FrC:\src\xemacs\nt\..\nt\obj\tparam.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb tparam.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\undo.c -FoC:\src\xemacs\nt\ ..\nt\obj\undo.obj -FrC:\src\xemacs\nt\..\nt\obj\undo.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb undo.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\widget.c -FoC:\src\xemacs\n t\..\nt\obj\widget.obj -FrC:\src\xemacs\nt\..\nt\obj\widget.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb widget.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\window.c -FoC:\src\xemacs\n t\..\nt\obj\window.obj -FrC:\src\xemacs\nt\..\nt\obj\window.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb window.c cl -c -nologo -W3 -Od -Zi -ML -I"c:\src\xpm-3.4k" -I"c:\src\xpm-3.4k\lib" -I"c:\src\png-1.0.3" -I"c:\src\zlib-1.1.3" -I"c:\src\jpeg-6b" -IC:\src\xemacs\nt\..\nt\inc -IC:\src\xemacs\nt\..\src -IC:\src\xemacs\nt\..\lwlib -DHAVE_MS_WINDOWS -DHAVE_ SCROLLBARS -DHAVE_MENUBARS -DHAVE_MSW_C_DIRED -DHAVE_XPM -DFOR_MSW -DHAVE_GIF -DHAVE_PNG -DHAVE_JPEG -DHAVE_TOOLBARS -DHAVE_DIALOGS -DHAVE_WIDGETS -DHAVE_NATIVE_SOUND -DGNU_MALLOC -DQUICK_BUILD -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs - DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b1\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b1\" -DEMACS_PROGNAME=\"xemacs\" -DPATH_PREFIX=\"..\" -DDEBUG_XEMACS -D_DEBUG -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSIO N=1 -DXEMACS_CODENAME=\""anise"\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" -DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages"\" C:\src\xemacs\nt\..\src\win32.c -FoC:\src\xemacs\nt \..\nt\obj\win32.obj -FrC:\src\xemacs\nt\..\nt\obj\win32.sbr -FdC:\src\xemacs\nt\..\nt\obj\temacs.pdb win32.c rc -FoC:\src\xemacs\nt\..\nt\obj\xemacs.res xemacs.rc bscmake -nologo -oC:\src\xemacs\nt\..\src\temacs.bsc @bscmake.tmp del bscmake.tmp link.exe @C:\DOCUME~1\PKRAUS~1.PKR\LOCALS~1\Temp\nmb06696. glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_id glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_type glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_validate glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_normalize emacs.obj : error LNK2001: unresolved external symbol _syms_of_glyphs_shared C:\src\xemacs\nt\..\src\temacs.exe : fatal error LNK1120: 5 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. Error executing NMAKE. xemacs.exe - 7 error(s), 1 warning(s) -----Original Message----- From: Ben Wing [mailto:ben@666.com] Sent: Monday, May 28, 2001 7:42 PM To: Paul Krause Cc: xemacs-beta@xemacs.org Subject: Re: Build failure (head): unresolved external symbols glyphs-shared isn't getting compiled. perhaps your xemacs.mak is not up-to-date? Paul Krause wrote: > > In XEmacs 21.5 (beta1) "anise" [Lucid] (i586-pc-win32) of Sun May 20 2001 on PKRAUSE > configured using `configure UNKNOWN' > > Please describe exactly what actions triggered the bug > and the precise symptoms of the bug: > > I suspect it was related to Ben's change of 5/23. > > ---------------------------- > revision 1.30 > date: 2001/05/23 09:59:45; author: ben; state: Exp; lines: +1 -5 > database.c, debug.h, device-tty.c, dired-msw.c, glyphs-msw.c: header > cleanups (remove places that directly include a system > header file, because we have our own layer to do this more cleanly > and portably); indentation fixes. > ---------------------------- > > Build->Build xemacs.exe [F7] > > -------------------Configuration: xemacs - Win32 Debug-------------------- > Microsoft (R) Program Maintenance Utility Version 1.62.7022 > Copyright (C) Microsoft Corp 1988-1997. All rights reserved. > Creating C:\src\xemacs\nt\..\lib-src\config.values > -------------------------------------------------------------------- > OS version: > Microsoft Windows 2000 [Version 5.00.2195] > OS: Windows_NT > XEmacs 21.5-b1 \"anise\" configured for `i586-pc-win32'. > Building XEmacs in \"C:\\src\\xemacs\\nt\". > Using compiler \"cl -nologo -W3 -Od -Zi -ML\". > Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.5-b1\". > Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". > Compiling in support for Microsoft Windows native GUI. > Compiling in support for XPM images. > Compiling in support for GIF images. > Compiling in support for PNG images. > Compiling in support for JPEG images. > Compiling in support for toolbars. > Compiling in support for dialogs. > Compiling in support for widgets. > Compiling in support for native sounds. > Compiling in fast dired implementation. > Compiling in extra debug checks. XEmacs will be slow! > -------------------------------------------------------------------- > bscmake -nologo -oC:\src\xemacs\nt\..\src\temacs.bsc @bscmake.tmp > del bscmake.tmp > link.exe @C:\DOCUME~1\PKRAUS~1.PKR\LOCALS~1\Temp\nmb07008. > glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_id > glyphs-msw.obj : error LNK2001: unresolved external symbol _Q_resource_type > glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_validate > glyphs-msw.obj : error LNK2001: unresolved external symbol _shared_resource_normalize > emacs.obj : error LNK2001: unresolved external symbol _syms_of_glyphs_shared > C:\src\xemacs\nt\..\src\temacs.exe : fatal error LNK1120: 5 unresolved externals > NMAKE : fatal error U1077: 'link.exe' : return code '0x460' > Stop. > Error executing NMAKE. > > xemacs.exe - 7 error(s), 0 warning(s) -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From xemacs-announce-admin@xemacs.org Mon May 28 22:03:31 2001 Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA13495; Mon, 28 May 2001 22:03:26 -0400 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 154Yko-0002S2-00; Mon, 28 May 2001 18:57:02 -0700 Received: from gwyn.tux.org ([207.96.122.8] ident=ident-user) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.22 #1 (Debian)) id 154YkL-0002Ke-00 for ; Mon, 28 May 2001 18:56:33 -0700 Received: (from jason@localhost) by gwyn.tux.org (8.9.3/8.9.1) id VAA13220; Mon, 28 May 2001 21:56:28 -0400 Date: Tue, 29 May 2001 03:56:28 +0200 (CAT) From: XEmacs Webmaster To: xemacs-announce@xemacs.org Subject: xemacs-users-ru mailing list Message-ID: <20010529035628.A12802@xemacs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: xemacs-announce-admin@xemacs.org Errors-To: xemacs-announce-admin@xemacs.org X-BeenThere: xemacs-announce@xemacs.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: XEmacs Announcements List-Unsubscribe: , Announcing a new mailing list, xemacs-users-ru@xemacs.org. xemacs-users-ru is an open list for discussion and bug reporting for XEmacs. Russian is the preferred language of discussion. It is not gated to comp.emacs.xemacs or the "xemacs-news" list. For fastest response, bugs not specifically related to Russian or Mule features should be reported on xemacs-news (in English). For complete information, see: Enjoy. From ben@666.com Mon May 28 22:11:23 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id WAA13862 for ; Mon, 28 May 2001 22:11:23 -0400 Received: (qmail 9592 invoked by alias); 29 May 2001 02:11:18 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 9573 invoked by uid 0); 29 May 2001 02:11:18 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 29 May 2001 02:11:18 -0000 Message-ID: <3B1305AA.2B16A926@666.com> Date: Mon, 28 May 2001 19:12:58 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krause CC: xemacs-beta@xemacs.org Subject: Re: Build failure (head): unresolved external symbols References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit is glyphs-shared mentioned [twice] in xemacs.mak? i can't really help you diagnose this further at this stage; you'll have to poke around yourself and see what's going on. Paul Krause wrote: > > My xemacs.mak looks up-to-date. The only difference is that patch I > submitted earlier today. From steve@turnbull.sk.tsukuba.ac.jp Mon May 28 22:16:54 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA14181; Mon, 28 May 2001 22:16:52 -0400 Received: by localhost id m154Z3v-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 29 May 2001 11:16:47 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15123.1678.718773.185761@turnbull.sk.tsukuba.ac.jp> Date: Tue, 29 May 2001 11:16:46 +0900 To: Adrian Aichner Cc: Adrian.Aichner@t-online.de (Adrian Aichner), Steve Youngs , XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system In-Reply-To: References: <15121.42188.311896.838961@turnbull.sk.tsukuba.ac.jp> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "APA" == Adrian Aichner writes: Stephen> No. CVS binary has different semantics from MS-DOS/Mac Stephen> binary. I think this is a dangerous idea. APA> Please explain the danger to me. I prefer not to trust that the manual explains completely what the differences are. Especially in the case of CVS; I know that the manual is very incomplete about topics like branches, and I know that the software itself is buggy. I don't like relying on such software to Do The Right Thing, when we can (and should; why are we manipulating Lisp forms as text?) fix the problem internally. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From pkrause@soundbite.com Mon May 28 22:28:28 2001 Received: from fenway.corp.soundbite.com ([64.55.62.249]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA14630 for ; Mon, 28 May 2001 22:28:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: Build failure (head): unresolved external symbols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 May 2001 22:28:23 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Build failure (head): unresolved external symbols Thread-Index: AcDn5Kbq14gn/MhgSK6yMcbsCfvMjQAAGH9Q From: "Paul Krause" To: "Ben Wing" , "Nick V. Pakoulin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id WAA14630 > From: Ben Wing [mailto:ben@666.com] > is glyphs-shared mentioned [twice] in xemacs.mak? It is not. It appears to have been removed by revision 1.69 date: 2001/05/27 10:50:44; author: nick; state: Exp; lines: +31 -28 Suppress overwrite confirmation in xemacs.mak Index: xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.68 retrieving revision 1.69 diff -u -c -r1.68 -r1.69 cvs server: conflicting specifications of output style *** xemacs.mak 2001/05/26 12:24:51 1.68 --- xemacs.mak 2001/05/27 10:50:44 1.69 *************** *** 48,53 **** --- 48,58 ---- # Define a variable for the 'del' command to use DEL=-del + # Define a variable for 'copy' command to use + # Suppress confirmation for overwriting files + COPY=xcopy /q /y + COPYDIR=xcopy /q /y /e + # Program name and version !include "$(XEMACS)\version.sh" *************** *** 325,337 **** ! if defined(_) ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; s/^\\x23e/!e/;" \ -e "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ ! -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2 $(NT:\=\\\\)\\\\config.inc/;" \ < $(SRC)\depend > $(OUTDIR)\depend.tmp] ! endif ! else ! if [perl -p -e "s/^\x23if defined(.+)/!if defined$$1/; s/^\x23e/!e/;" \ -e "s/([\s=^])([\w\d\.\-^]+\.[ch^])/$$1$(SRC:\=\\)\\$$2/g;" \ ! -e "s/^(.+)\.o:(.+)/$(OUTDIR:\=\\)\\$$1.obj:$$2 $(NT:\=\\)\\config.inc/;" \ < $(SRC)\depend > $(OUTDIR)\depend.tmp] ! endif ! endif --- 330,342 ---- ! if defined(_) ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; s/^\\x23e/!e/;" \ -e "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ ! -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2/;" \ < $(SRC)\depend > $(OUTDIR)\depend.tmp] ! endif ! else ! if [perl -p -e "s/^\x23if defined(.+)/!if defined$$1/; s/^\x23e/!e/;" \ -e "s/([\s=^])([\w\d\.\-^]+\.[ch^])/$$1$(SRC:\=\\)\\$$2/g;" \ ! -e "s/^(.+)\.o:(.+)/$(OUTDIR:\=\\)\\$$1.obj:$$2/;" \ < $(SRC)\depend > $(OUTDIR)\depend.tmp] ! endif ! endif *************** *** 502,514 **** $(SRC)\paths.h $(SRC)\config.h: config.h ! copy config.h $(SRC) $(SRC)\Emacs.ad.h: Emacs.ad.h ! copy Emacs.ad.h $(SRC) $(SRC)\paths.h: paths.h ! copy paths.h $(SRC) #----------------------------------------------------------------------- ------- --- 507,519 ---- $(SRC)\paths.h $(SRC)\config.h: config.h ! @$(COPY) config.h $(SRC) $(SRC)\Emacs.ad.h: Emacs.ad.h ! @$(COPY) Emacs.ad.h $(SRC) $(SRC)\paths.h: paths.h ! @$(COPY) paths.h $(SRC) #----------------------------------------------------------------------- ------- *************** *** 605,611 **** link.exe -lib -nologo -out:$@ $(LASTFILE_OBJS) $(OUTDIR)\lastfile.obj: $(LASTFILE_SRC)\lastfile.c ! $(CCV) $(LASTFILE_FLAGS) $(LASTFILE_SRC)\$(@B).c !endif --- 610,616 ---- link.exe -lib -nologo -out:$@ $(LASTFILE_OBJS) $(OUTDIR)\lastfile.obj: $(LASTFILE_SRC)\lastfile.c ! $(CCV) $(LASTFILE_FLAGS) $** !endif *************** *** 632,653 **** link.exe -lib -nologo -out:$@ $(LWLIB_OBJS) $(OUTDIR)\lwlib-utils.obj: $(LWLIB_SRCDIR)\lwlib-utils.c ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c $(OUTDIR)\lwlib-Xaw.obj: $(LWLIB_SRCDIR)\lwlib-Xaw.c ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c $(OUTDIR)\lwlib-Xlw.obj: $(LWLIB_SRCDIR)\lwlib-Xlw.c ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c $(OUTDIR)\lwlib.obj: $(LWLIB_SRCDIR)\lwlib.c ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c $(OUTDIR)\xlwmenu.obj: $(LWLIB_SRCDIR)\xlwmenu.c ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c $(OUTDIR)\xlwscrollbar.obj: $(LWLIB_SRCDIR)\xlwscrollbar.c ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c !endif #----------------------------------------------------------------------- ------- --- 637,658 ---- link.exe -lib -nologo -out:$@ $(LWLIB_OBJS) $(OUTDIR)\lwlib-utils.obj: $(LWLIB_SRCDIR)\lwlib-utils.c ! $(CCV) $(LWLIB_FLAGS) $** $(OUTDIR)\lwlib-Xaw.obj: $(LWLIB_SRCDIR)\lwlib-Xaw.c ! $(CCV) $(LWLIB_FLAGS) $** $(OUTDIR)\lwlib-Xlw.obj: $(LWLIB_SRCDIR)\lwlib-Xlw.c ! $(CCV) $(LWLIB_FLAGS) $** $(OUTDIR)\lwlib.obj: $(LWLIB_SRCDIR)\lwlib.c ! $(CCV) $(LWLIB_FLAGS) $** $(OUTDIR)\xlwmenu.obj: $(LWLIB_SRCDIR)\xlwmenu.c ! $(CCV) $(LWLIB_FLAGS) $** $(OUTDIR)\xlwscrollbar.obj: $(LWLIB_SRCDIR)\xlwscrollbar.c ! $(CCV) $(LWLIB_FLAGS) $** !endif #----------------------------------------------------------------------- ------- *************** *** 696,702 **** $(SRC)\getloadavg.c \ $(SRC)\glyphs.c \ $(SRC)\glyphs-eimage.c \ - $(SRC)\glyphs-shared.c \ $(SRC)\glyphs-widget.c \ $(SRC)\gui.c \ $(SRC)\gutter.c \ --- 701,706 ---- *************** *** 988,994 **** $(OUTDIR)\getloadavg.obj \ $(OUTDIR)\glyphs.obj \ $(OUTDIR)\glyphs-eimage.obj \ - $(OUTDIR)\glyphs-shared.obj \ $(OUTDIR)\glyphs-widget.obj \ $(OUTDIR)\gui.obj \ $(OUTDIR)\gutter.obj \ --- 992,997 ---- *************** *** 1053,1062 **** $(OUTDIR)\emacs.obj: $(XEMACS)\version.sh $(OUTDIR)\TopLevelEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TOP_LEVEL_EMACS_SHELL $(TEMACS_SRC)\$(@B).c -Fo$@ $(OUTDIR)\TransientEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TRANSIENT_EMACS_SHELL $(TEMACS_SRC)\$(@B).c -Fo$@ $(OUTDIR)\alloc.obj: $(TEMACS_SRC)\alloc.c --- 1056,1065 ---- $(OUTDIR)\emacs.obj: $(XEMACS)\version.sh $(OUTDIR)\TopLevelEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TOP_LEVEL_EMACS_SHELL $** -Fo$@ $(OUTDIR)\TransientEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TRANSIENT_EMACS_SHELL $** -Fo$@ $(OUTDIR)\alloc.obj: $(TEMACS_SRC)\alloc.c *************** *** 1407,1428 **** cd $(NT) @echo Installing in $(INSTALL_DIR) ... @echo PlaceHolder > PlaceHolder ! @xcopy /q PROBLEMS "$(INSTALL_DIR)\" ! @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" ! @xcopy /q $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" ! @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" ! @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" ! @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" ! @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" ! @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" ! @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" $(DEL) PlaceHolder --- 1410,1431 ---- cd $(NT) @echo Installing in $(INSTALL_DIR) ... @echo PlaceHolder > PlaceHolder ! @$(COPY) PROBLEMS "$(INSTALL_DIR)\" ! @$(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" ! @$(COPY) $(LIB_SRC)\*.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" ! @$(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" ! @$(COPY) $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" ! @$(COPY) $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" ! @$(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" ! @$(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" ! @$(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" $(DEL) PlaceHolder From lipp@primus.com Mon May 28 22:39:34 2001 Received: from exchange1.primus.com (mail.primus.com [206.253.199.54] (may be forged)) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA14980 for ; Mon, 28 May 2001 22:39:33 -0400 Received: by exchange1.primus.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 May 2001 19:38:11 -0700 Message-ID: <29FD2733D847D511B7580008C73BFD002CCBE9@exchange1.primus.com> From: Damon Lipparelli To: "'Ben Wing '" , "'Paul Krause '" Cc: "'xemacs-beta@xemacs.org '" Subject: RE: Build failure (head): unresolved external symbols Date: Mon, 28 May 2001 19:37:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) List-Help: List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0E7E8.3E10C810" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0E7E8.3E10C810 Content-Type: text/plain; charset="iso-8859-1" I'm seeing the same thing here; my "nt/xemacs.mak" is up-to-date. The attached (obvious) patch fixes things. -lipp -----Original Message----- From: Ben Wing To: Paul Krause Cc: xemacs-beta@xemacs.org Sent: 5/28/2001 7:12 PM Subject: Re: Build failure (head): unresolved external symbols is glyphs-shared mentioned [twice] in xemacs.mak? i can't really help you diagnose this further at this stage; you'll have to poke around yourself and see what's going on. Paul Krause wrote: > > My xemacs.mak looks up-to-date. The only difference is that patch I > submitted earlier today. ------_=_NextPart_000_01C0E7E8.3E10C810 Content-Type: application/octet-stream; name="patch1.txt" Content-Disposition: attachment; filename="patch1.txt" Index: xemacs.mak =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v retrieving revision 1.69 diff -u -r1.69 xemacs.mak --- xemacs.mak 2001/05/27 10:50:44 1.69 +++ xemacs.mak 2001/05/29 02:35:36 @@ -701,6 +701,7 @@ $(SRC)\getloadavg.c \ $(SRC)\glyphs.c \ $(SRC)\glyphs-eimage.c \ + $(SRC)\glyphs-shared.c \ $(SRC)\glyphs-widget.c \ $(SRC)\gui.c \ $(SRC)\gutter.c \ @@ -992,6 +993,7 @@ $(OUTDIR)\getloadavg.obj \ $(OUTDIR)\glyphs.obj \ $(OUTDIR)\glyphs-eimage.obj \ + $(OUTDIR)\glyphs-shared.obj \ $(OUTDIR)\glyphs-widget.obj \ $(OUTDIR)\gui.obj \ $(OUTDIR)\gutter.obj \ ------_=_NextPart_000_01C0E7E8.3E10C810-- From andyp@bea.com Mon May 28 22:41:10 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id WAA15037 for ; Mon, 28 May 2001 22:40:56 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA12671; Mon, 28 May 2001 19:41:01 -0700 (PDT) Received: from C1513231-A.bea.com (wsp001358wss.beasys.com [192.168.6.189]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id TAA12924; Mon, 28 May 2001 19:41:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20010528194039.00b20a70@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 May 2001 19:41:03 -0700 To: Gunnar Evermann , XEmacs Developers From: Andy Piper Subject: Re: buffers tab In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:26 PM 5/28/01 +0100, Gunnar Evermann wrote: >One thing I would love to see is the ability to bind different >functions to different mouse-button clicks on the tabs. For example >bind button1 to the equivalent of switch-to-buffer and button2 to >switch-to-buffer-other-window. Is there an easy way to achieve this? No. Mouse-handling in the gutter is pretty limited and defers to the widgets in there. andy From mta@arbortext.com Tue May 29 01:03:47 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA22039; Tue, 29 May 2001 01:02:22 -0400 Date: Tue, 29 May 2001 01:01:47 -0400 From: Mike Alexander To: "08.58016472@telia.com" <08.58016472@telia.com>, "Michael Sperber [Mr. Preprocessor]" cc: Thomas Nichols , Mats Lidell , "xemacs-beta@xemacs.org" , "xemacs-nt@xemacs.org" Subject: RE: Help test EFS Message-ID: <62478608.3200086907@[148.59.233.133]> In-Reply-To: <01C0E439.CE4C2760.08.58016472@telia.com> X-Mailer: Mulberry/2.0.6 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit I did some debugging tonight and it appears that this problem is being caused by "200 PORT command successful" messages coming from the cygwin FTP client after the get command is issued. EFS was thinking that this response meant the get command was done when in fact it had only just started. I fixed it by adding this to my custom.el file: '(efs-skip-msgs-alist (quote (("" . "^110 \\|^125 \\|^150 ") ("^ls \\|^put \\|^get \\|^append \\|passive" . "^500 EPSV not understood") ("^ls \\|^put \\|^get \\|^append " . "^200 PORT command successful"))) t) Only the last entry is new. I have no idea what changed in efs or cygwin to make this start failing since I'm pretty sure it worked until recently. Mike Alexander Arbortext, Inc. +1-734-997-0200 --On Thursday, May 24, 2001 10:10 AM +0200 Jerker Haglund <08.58016472@telia.com> wrote: >> I've been having trouble with this on a machine running the native >> build of XEmacs (from the current CVS trunk) on Windows NT 4.0 using >> the cygwin ftp client. When I try to open a file on an FTP server >> (I've tried several and it doesn't seem to matter which server) the >> file is truncated at a random location a few thousand bytes into the >> file. If you look at the ftp log everything seems to be ok, but efs >> doesn't seem to wait for the file to be transfered before using the >> result. I've tried to debug this a bit, but haven't learned very >> much. Has anyone else seen problems like this? > > I've noticed that EFS says 'Done' long before the result is visible. > That's with an ADSL connection, native 21.4.3 on Win2k. If it > doesn't wait properly, this could explain why the experimental > EFS seems shaky, with both cygwin and windows ftp. Things fail > 1st time, try again (when things are cached) and it works. > > /J. Haglund > >> >> I'm connected via an ISDN line so ftp transfers are not too fast. >> This might have something to do with it. I'll try it on other >> machines with faster net connections and see if that affects things. >> If I can provide any more information let me know. > From kvaav454f2v56@yahoo.com Tue May 29 02:57:51 2001 Received: from diap-nt003.diap.com.sg (diap-nt003.diap.com.sg [203.126.255.126]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA27825 for ; Tue, 29 May 2001 02:57:49 -0400 From: kvaav454f2v56@yahoo.com Received: from Wm5ZWBaRN (slip-32-101-105-205.ca.us.prserv.net [32.101.105.205]) by diap-nt003.diap.com.sg with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L6QY0J6R; Tue, 29 May 2001 14:56:54 +0800 DATE: 28 May 02 10:55:05 PM Message-ID: <4wJJof4Hg4rAci> Content-Type: text/html SUBJECT: (None) To: undisclosed-recipients:; Untitled Document Educate yourself about everything you ever wanted to know !!!

Individually, these products often sell for as much as $100!!!

1. Satellite TV/RCA Dish Descrambler

Our unique, complete plans for building your own home satellite TV descrambler. For access to a clear reception of pay TV signals on your home satellite dish! It does not require any additional equipment! Complete PC board template & instructions! This also includes a manual for accessing the RCA/DSS satellite dish to receive free pay channels. All the latest information for doing it right.

2. X-Ray Envelope Spray

Have you ever wanted to read the contents of an envelope without opening it? Many government and other organizations use what is known as X-Ray Envelope Spray to do this! An envelope is sprayed with this secret chemical and it becomes translucent for a short period of time which allows the contents to be read without opening. Private supply houses sell small cans of this aerosol spray for up to $50 a can! The spray is actually a commonly available item found in major grocery and discount stores. No modification of the spray is needed, as it is ready to use as X-Ray Envelope Spray and sells for about $1.99 in retail stores!

3. How to Find Anyone and Obtain Unlisted Phone Numbers.

Tired of getting the wrong number? Stop looking! We can help! We'll show you how to get the unlisted phone number of anyone. No one can hide now! Simple. Skip tracers use these tricks. We also include everything you need to know about finding missing people or loved ones from the comfort of your home. Why pay money when you can do it yourself?

4. Radar Zapper

This simply technique converts existing radar detectors into a device that will jam police radar. This device sends false readings back to the police radar! Works on virtually all detectors and easy to use!

5. Untraceable E-Mail

How to send totally anonymous and untraceable E-mail. We're not talking about those generic Yahoo! accounts -- this is the real McCoy, anonymous email. Everything explained. Absolutely untraceable.

6. Underground Guide to Utility Meters

The illustrated guide to gas, water & electric meters! We show you in detail methods many people use to stop, slow down, even reverse all three types! This underground manual is one of our most popular items! Complete illustrated techniques and easy to do. Shows how to defeat all major brands & models of gas, water & electric meters.

7. Scan-Tron Genius

Here at last!! This very controversial report describes in detail how any student can easily defeat Scan-Tron test readers to pass a test even though he does not know the answer! This simple method will fool the scan reader into thinking your answered correctly! No tools needed. Completely tested. You won't believe how simple this method is!

8. Bad Credit Cleaning Manual

Simple ways to restore your bad credit rating to A++. Don't pay a credit counselor good money to do what you can do yourself. Many methods presented here - some legal & some "not so legal". Wipe your slate clean from your own home. Get a fresh start.

9. Pass Drug Tests

Don't use of drugs! However, many innocent people are victims of drug testing. Some over the counter medicine can trigger false results & cost you your job. Proven methods to beat drug tests. We show you how to build a simple device that can fool the best! Protect yourself & your job, even if you don't use drugs.

10.Cable TV Decoders

How to get cable TV and turn your converter box into "full service" mode. This is the latest and best way to gain access. Also, how to build your own "snooper stopper" for pennies. Prevents cable companies from spying on you.

11. Free Long Distance

You can make long distance calls to other countries at no cost! The information in these reports explains everything you need to call other countries! Country codes, city codes, overseas sender codes! Call England, Germany, the UK, practically anywhere!

12. Dissolving Checks

We show you in detail the "insufficient funds" checks scam used by people to obtain goods & cash without having any money in the account. Many people do not even use false ID's in pulling this scam off. Complete detailed instructions plus rare information on the famous "dissolving" checks. These checks "dissolve" after being chemically coated & deposited in the bank leaving no trace of the writer or account number. Not for illegal purposes. See how others do it.

13. Outsmart Lie Detector Tests

Hundreds of thousands of people in this country are wrongfully fired or not hired simply because they did not pass the lie detector test even though they've done nothing wrong! Read drugless methods to help pass whether you are lying or not! A valuable tool for any job seeker. Don't be harassed by your employer ever again. Tested and proven.

14. Lock-picks & Lock-picking

Why buy expensive lock-picks & pay for rip-off mail order locksmith courses? We'll show you how to make your own professional lock-picks. Exact detailed drawings & construction techniques! This is perhaps the easiest to understand course ever published on this hush-hush subject. You won't believe how easy it is to make these tools! We also show you how a basic lock works & how they are picked. This publication is complete with detailed drawings & illustrations.

ALL IN ONE!!! PREVIOUSLY SOLD FOR HUNDREDS!!! ORDER NOW!!!

That's 14 products, all for just $29.95 [shipping & handling included]. CA residents please add sales tax

We accept cash, personal checks, money orders and cashiers checks. You must include a

primary and secondary E-mail address as we will be emailing you all the reports as soon as your payment is received.

Print the following form & mail it to:

Info 4 Edu Only
1300 N. Cahuenga Blvd # 362

Los Angeles, CA 90028

Please Print Clearly

Name: _________________________________________________

Primary Email Address: ___________________________________

Secondary Email Address: _________________________________

Make your check payable to: Info 4 Edu Only

DISCLAIMER: Please note that this information is being provided for educational purposes only. The information itself is legal, while the usage of such information may be illegal. We do not advocate unauthorized use or theft of any services. If in doubt, check your local laws and act accordingly. NOTE: All of the publications are Copyright 2001 by Info 4 Edu Only . We aggressively protect our copyrights and will seek prosecution of any website, web-master, web hosting service or anyone else that is in violation of US & International Copyright Laws.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via Email. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of the new millennium. To be removed please email optmeout@aol.com with the word "remove" in the subject line.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

From martin@m17n.org Tue May 29 03:05:03 2001 Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA29043 for ; Tue, 29 May 2001 03:05:02 -0400 Received: from fs.m17n.org (root@fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.3/3.7W-20010518204228) with ESMTP id f4T75Lp07933; Tue, 29 May 2001 16:05:21 +0900 (JST) (envelope-from martin@m17n.org) Received: from mule.m17n.org (mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id QAA18213; Tue, 29 May 2001 16:05:00 +0900 (JST) Received: (from martin@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id f4T74xK01414; Tue, 29 May 2001 16:04:59 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15123.18971.838708.477834@gargle.gargle.HOWL> Date: Tue, 29 May 2001 16:04:59 +0900 From: Martin Buchholz Sender: martin@xemacs.org To: karlheg@hegbloom.net (Karl M. Hegbloom), XEmacs Beta Test Subject: Re: [21.4,21.5] configure.in (have_dl): Add modules to MAKE_SUBDIR and INSTALL_ARCH_DEP_SUBDIR In-Reply-To: <8766ek4qku.fsf@bittersweet.intra.hegbloom.net> References: <8766ek4qku.fsf@bittersweet.intra.hegbloom.net> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid >>>>> "Karl" == Karl M Hegbloom writes: Karl> By the way, our "configure.in" is broken with autoconf 2.50, but of Karl> course still works with autoconf 2.13. (In Debian "sid" right now is Karl> both autoconf (2.50) and autoconf2.13.) Here is the error: autoconf-2.50 is a major change from 2.13. Upgrading _properly_ will be a lot of work. In particular, a lot of the redefinitions in configure.in are to change the behavior of configure in a way that's no longer necessary in the new autoconf. New macros introduced in autoconf 2.50 should also be used. From Adrian.Aichner@t-online.de Tue May 29 03:13:56 2001 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA30524; Tue, 29 May 2001 03:13:54 -0400 Received: from fwd04.sul.t-online.de by mailout05.sul.t-online.de with smtp id 154dhR-0007JF-09; Tue, 29 May 2001 09:13:53 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[217.80.39.70]) by fwd04.sul.t-online.com with esmtp id 154dhH-1OVFtAC; Tue, 29 May 2001 09:13:43 +0200 To: "Stephen J. Turnbull" Cc: Adrian Aichner , Adrian.Aichner@t-online.de (Adrian Aichner), Steve Youngs , XEmacs Beta Subject: Re: BAD: Handling of package-index by package release and install system References: <15121.42188.311896.838961@turnbull.sk.tsukuba.ac.jp> <15123.1678.718773.185761@turnbull.sk.tsukuba.ac.jp> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Stephen" == Stephen J Turnbull writes: >>>>> "APA" == Adrian Aichner writes: Stephen> No. CVS binary has different semantics from MS-DOS/Mac Stephen> binary. I think this is a dangerous idea. APA> Please explain the danger to me. Stephen> I prefer not to trust that the manual explains completely Stephen> what the differences are. Especially in the case of CVS; Stephen> I know that the manual is very incomplete about topics Stephen> like branches, and I know that the software itself is Stephen> buggy. And I thought you had facts :-) Stephen> I don't like relying on such software to Do The Right Stephen> Thing, when we can (and should; why are we manipulating Stephen> Lisp forms as text?) fix the problem internally. I agree that this is a better approach. Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From didier@lrde.epita.fr Tue May 29 03:22:47 2001 Received: from hermes.epita.fr (hermes.epita.fr [163.5.255.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA31908; Tue, 29 May 2001 03:22:42 -0400 Received: from goa.lrde.epita.fr (mail@goa.lrde.epita.fr [10.223.13.2]) by hermes.epita.fr id JAA24111 Tue, 29 May 2001 09:20:30 GMT Received: from uzeb.lrde.epita.fr ([10.223.13.53] ident=mail) by goa.lrde.epita.fr with esmtp (Exim 3.22 #1 (Debian)) id 154dpP-0002dE-00; Tue, 29 May 2001 09:22:07 +0200 Received: from didier by uzeb.lrde.epita.fr with local (Exim 3.22 #1 (Debian)) id 154dpC-000185-00; Tue, 29 May 2001 09:21:54 +0200 To: Martin Buchholz Cc: karlheg@hegbloom.net (Karl M. Hegbloom), XEmacs Beta Test Subject: Re: [21.4,21.5] configure.in (have_dl): Add modules to MAKE_SUBDIR and INSTALL_ARCH_DEP_SUBDIR References: <8766ek4qku.fsf@bittersweet.intra.hegbloom.net> <15123.18971.838708.477834@gargle.gargle.HOWL> X-Attribution: drv X-Url: http://www.infres.enst.fr/~verna X-Web: http://www.infres.enst.fr/~verna X-Home-Page: http://www.infres.enst.fr/~verna In-Reply-To: <15123.18971.838708.477834@gargle.gargle.HOWL> (Martin Buchholz's message of "Tue, 29 May 2001 16:04:59 +0900") X-Face: |j}\)O|k##MrRz#VK$Jy=0r=3Qc,,a/Tr6*JQbE73dy17]2YcmW$9Z&H21e}#~#pgc>dn(is5Bv1l!{1re+Q9suKIOUmOqZs2>QMxHlR;;}kaGYA@HR3D C6 X-Face: 6o|eiKqaHN.ANh8HXDzntcWUOCg\]RsOd.ctvm~*y}Y^R&*a+Co,\s#=HWsw3x$b_n2kJ#g (7u?J^@^xP)f,jUF|0Z'J:|G/bMA5O12*b,7`-Q`=pKsCRIpso07.Y>YB2H{7`?u&yh;C_ZtLHfj Mail-Copies-To: never Date: 29 May 2001 09:21:53 +0200 Message-ID: Lines: 22 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: Didier Verna Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id DAA31908 Martin Buchholz wrote: > >>>>> "Karl" == Karl M Hegbloom writes: > > Karl> By the way, our "configure.in" is broken with autoconf 2.50, but of > Karl> course still works with autoconf 2.13. (In Debian "sid" right now is > Karl> both autoconf (2.50) and autoconf2.13.) Here is the error: > > autoconf-2.50 is a major change from 2.13. Upgrading _properly_ will > be a lot of work. In particular, a lot of the redefinitions in > configure.in are to change the behavior of configure in a way that's > no longer necessary in the new autoconf. New macros introduced in > autoconf 2.50 should also be used. Martin, I'd panned to upgrade our script long ago but haven't started yet. If you ever do so, please inform me to avoid duplicating the effort. -- Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier@xemacs.org From ben@666.com Tue May 29 03:59:01 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id DAA02102 for ; Tue, 29 May 2001 03:58:59 -0400 Received: (qmail 71082 invoked by alias); 29 May 2001 07:58:57 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 71068 invoked by uid 0); 29 May 2001 07:58:57 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 29 May 2001 07:58:57 -0000 Message-ID: <3B135725.A3C9D802@666.com> Date: Tue, 29 May 2001 01:00:37 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krause CC: "Nick V. Pakoulin" , xemacs-beta@xemacs.org Subject: Re: Build failure (head): unresolved external symbols References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit nick, you need to be more careful when you check in -- you completely clobbered my most recent checkins. this is never supposed to happen -- `cvs update' should always merge in other people's changes. did you copy a file from one workspace to another? instead of doing that, either check in from the first workspace or use `diff' and `patch' to move changes. Paul Krause wrote: > > > From: Ben Wing [mailto:ben@666.com] > > is glyphs-shared mentioned [twice] in xemacs.mak? > > It is not. It appears to have been removed by > > revision 1.69 > date: 2001/05/27 10:50:44; author: nick; state: Exp; lines: +31 -28 > Suppress overwrite confirmation in xemacs.mak > > Index: xemacs.mak > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v > retrieving revision 1.68 > retrieving revision 1.69 > diff -u -c -r1.68 -r1.69 > cvs server: conflicting specifications of output style > *** xemacs.mak 2001/05/26 12:24:51 1.68 > --- xemacs.mak 2001/05/27 10:50:44 1.69 > *************** > *** 48,53 **** > --- 48,58 ---- > # Define a variable for the 'del' command to use > DEL=-del > > + # Define a variable for 'copy' command to use > + # Suppress confirmation for overwriting files > + COPY=xcopy /q /y > + COPYDIR=xcopy /q /y /e > + > # Program name and version > > !include "$(XEMACS)\version.sh" > *************** > *** 325,337 **** > ! if defined(_) > ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; > s/^\\x23e/!e/;" \ > -e > "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ > ! -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2 > $(NT:\=\\\\)\\\\config.inc/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! else > ! if [perl -p -e "s/^\x23if defined(.+)/!if defined$$1/; > s/^\x23e/!e/;" \ > -e "s/([\s=^])([\w\d\.\-^]+\.[ch^])/$$1$(SRC:\=\\)\\$$2/g;" \ > ! -e "s/^(.+)\.o:(.+)/$(OUTDIR:\=\\)\\$$1.obj:$$2 > $(NT:\=\\)\\config.inc/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! endif > --- 330,342 ---- > ! if defined(_) > ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; > s/^\\x23e/!e/;" \ > -e > "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ > ! -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! else > ! if [perl -p -e "s/^\x23if defined(.+)/!if defined$$1/; > s/^\x23e/!e/;" \ > -e "s/([\s=^])([\w\d\.\-^]+\.[ch^])/$$1$(SRC:\=\\)\\$$2/g;" \ > ! -e "s/^(.+)\.o:(.+)/$(OUTDIR:\=\\)\\$$1.obj:$$2/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! endif > *************** > *** 502,514 **** > $(SRC)\paths.h > > $(SRC)\config.h: config.h > ! copy config.h $(SRC) > > $(SRC)\Emacs.ad.h: Emacs.ad.h > ! copy Emacs.ad.h $(SRC) > > $(SRC)\paths.h: paths.h > ! copy paths.h $(SRC) > > > #----------------------------------------------------------------------- > ------- > > --- 507,519 ---- > $(SRC)\paths.h > > $(SRC)\config.h: config.h > ! @$(COPY) config.h $(SRC) > > $(SRC)\Emacs.ad.h: Emacs.ad.h > ! @$(COPY) Emacs.ad.h $(SRC) > > $(SRC)\paths.h: paths.h > ! @$(COPY) paths.h $(SRC) > > > #----------------------------------------------------------------------- > ------- > > *************** > *** 605,611 **** > link.exe -lib -nologo -out:$@ $(LASTFILE_OBJS) > > $(OUTDIR)\lastfile.obj: $(LASTFILE_SRC)\lastfile.c > ! $(CCV) $(LASTFILE_FLAGS) $(LASTFILE_SRC)\$(@B).c > > !endif > > --- 610,616 ---- > link.exe -lib -nologo -out:$@ $(LASTFILE_OBJS) > > $(OUTDIR)\lastfile.obj: $(LASTFILE_SRC)\lastfile.c > ! $(CCV) $(LASTFILE_FLAGS) $** > > !endif > > *************** > *** 632,653 **** > link.exe -lib -nologo -out:$@ $(LWLIB_OBJS) > > $(OUTDIR)\lwlib-utils.obj: $(LWLIB_SRCDIR)\lwlib-utils.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\lwlib-Xaw.obj: $(LWLIB_SRCDIR)\lwlib-Xaw.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\lwlib-Xlw.obj: $(LWLIB_SRCDIR)\lwlib-Xlw.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\lwlib.obj: $(LWLIB_SRCDIR)\lwlib.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\xlwmenu.obj: $(LWLIB_SRCDIR)\xlwmenu.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\xlwscrollbar.obj: $(LWLIB_SRCDIR)\xlwscrollbar.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > !endif > > #----------------------------------------------------------------------- > ------- > --- 637,658 ---- > link.exe -lib -nologo -out:$@ $(LWLIB_OBJS) > > $(OUTDIR)\lwlib-utils.obj: $(LWLIB_SRCDIR)\lwlib-utils.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\lwlib-Xaw.obj: $(LWLIB_SRCDIR)\lwlib-Xaw.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\lwlib-Xlw.obj: $(LWLIB_SRCDIR)\lwlib-Xlw.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\lwlib.obj: $(LWLIB_SRCDIR)\lwlib.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\xlwmenu.obj: $(LWLIB_SRCDIR)\xlwmenu.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\xlwscrollbar.obj: $(LWLIB_SRCDIR)\xlwscrollbar.c > ! $(CCV) $(LWLIB_FLAGS) $** > > !endif > > #----------------------------------------------------------------------- > ------- > *************** > *** 696,702 **** > $(SRC)\getloadavg.c \ > $(SRC)\glyphs.c \ > $(SRC)\glyphs-eimage.c \ > - $(SRC)\glyphs-shared.c \ > $(SRC)\glyphs-widget.c \ > $(SRC)\gui.c \ > $(SRC)\gutter.c \ > --- 701,706 ---- > *************** > *** 988,994 **** > $(OUTDIR)\getloadavg.obj \ > $(OUTDIR)\glyphs.obj \ > $(OUTDIR)\glyphs-eimage.obj \ > - $(OUTDIR)\glyphs-shared.obj \ > $(OUTDIR)\glyphs-widget.obj \ > $(OUTDIR)\gui.obj \ > $(OUTDIR)\gutter.obj \ > --- 992,997 ---- > *************** > *** 1053,1062 **** > $(OUTDIR)\emacs.obj: $(XEMACS)\version.sh > > $(OUTDIR)\TopLevelEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TOP_LEVEL_EMACS_SHELL > $(TEMACS_SRC)\$(@B).c -Fo$@ > > $(OUTDIR)\TransientEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TRANSIENT_EMACS_SHELL > $(TEMACS_SRC)\$(@B).c -Fo$@ > > $(OUTDIR)\alloc.obj: $(TEMACS_SRC)\alloc.c > > --- 1056,1065 ---- > $(OUTDIR)\emacs.obj: $(XEMACS)\version.sh > > $(OUTDIR)\TopLevelEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TOP_LEVEL_EMACS_SHELL $** > -Fo$@ > > $(OUTDIR)\TransientEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TRANSIENT_EMACS_SHELL $** > -Fo$@ > > $(OUTDIR)\alloc.obj: $(TEMACS_SRC)\alloc.c > > *************** > *** 1407,1428 **** > cd $(NT) > @echo Installing in $(INSTALL_DIR) ... > @echo PlaceHolder > PlaceHolder > ! @xcopy /q PROBLEMS "$(INSTALL_DIR)\" > ! @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" > $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" > ! @xcopy /q $(LIB_SRC)\*.exe > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" > ! @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" > ! @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" > ! @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... > ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" > ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" > ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" > $(DEL) PlaceHolder > > --- 1410,1431 ---- > cd $(NT) > @echo Installing in $(INSTALL_DIR) ... > @echo PlaceHolder > PlaceHolder > ! @$(COPY) PROBLEMS "$(INSTALL_DIR)\" > ! @$(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" > $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" > ! @$(COPY) $(LIB_SRC)\*.exe > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" > ! @$(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @$(COPY) $(CONFIG_VALUES) > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @$(COPY) $(SRC)\xemacs.exe > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @$(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" > ! @$(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" > ! @$(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... > ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" > ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" > ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" > $(DEL) PlaceHolder > -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Tue May 29 04:07:01 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id EAA04681 for ; Tue, 29 May 2001 04:06:59 -0400 Received: (qmail 79555 invoked by alias); 29 May 2001 08:06:56 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 79526 invoked by uid 0); 29 May 2001 08:06:54 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 29 May 2001 08:06:54 -0000 Message-ID: <3B135902.1F213B5E@666.com> Date: Tue, 29 May 2001 01:08:34 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krause CC: "Nick V. Pakoulin" , xemacs-beta@xemacs.org Subject: Re: Build failure (head): unresolved external symbols References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ok. i put my changes back in. hopefully you should be able to compile again. Paul Krause wrote: > > > From: Ben Wing [mailto:ben@666.com] > > is glyphs-shared mentioned [twice] in xemacs.mak? > > It is not. It appears to have been removed by > > revision 1.69 > date: 2001/05/27 10:50:44; author: nick; state: Exp; lines: +31 -28 > Suppress overwrite confirmation in xemacs.mak > > Index: xemacs.mak > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/nt/xemacs.mak,v > retrieving revision 1.68 > retrieving revision 1.69 > diff -u -c -r1.68 -r1.69 > cvs server: conflicting specifications of output style > *** xemacs.mak 2001/05/26 12:24:51 1.68 > --- xemacs.mak 2001/05/27 10:50:44 1.69 > *************** > *** 48,53 **** > --- 48,58 ---- > # Define a variable for the 'del' command to use > DEL=-del > > + # Define a variable for 'copy' command to use > + # Suppress confirmation for overwriting files > + COPY=xcopy /q /y > + COPYDIR=xcopy /q /y /e > + > # Program name and version > > !include "$(XEMACS)\version.sh" > *************** > *** 325,337 **** > ! if defined(_) > ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; > s/^\\x23e/!e/;" \ > -e > "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ > ! -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2 > $(NT:\=\\\\)\\\\config.inc/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! else > ! if [perl -p -e "s/^\x23if defined(.+)/!if defined$$1/; > s/^\x23e/!e/;" \ > -e "s/([\s=^])([\w\d\.\-^]+\.[ch^])/$$1$(SRC:\=\\)\\$$2/g;" \ > ! -e "s/^(.+)\.o:(.+)/$(OUTDIR:\=\\)\\$$1.obj:$$2 > $(NT:\=\\)\\config.inc/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! endif > --- 330,342 ---- > ! if defined(_) > ! if [perl -p -e "s/^\\x23if defined(.+)/!if defined$$1/; > s/^\\x23e/!e/;" \ > -e > "s/([\\s=^])([\\w\\d\\.\\-^]+\\.[ch^])/$$1$(SRC:\=\\\\)\\\\$$2/g;" \ > ! -e "s/^(.+)\\.o:(.+)/$(OUTDIR:\=\\\\)\\\\$$1.obj:$$2/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! else > ! if [perl -p -e "s/^\x23if defined(.+)/!if defined$$1/; > s/^\x23e/!e/;" \ > -e "s/([\s=^])([\w\d\.\-^]+\.[ch^])/$$1$(SRC:\=\\)\\$$2/g;" \ > ! -e "s/^(.+)\.o:(.+)/$(OUTDIR:\=\\)\\$$1.obj:$$2/;" \ > < $(SRC)\depend > $(OUTDIR)\depend.tmp] > ! endif > ! endif > *************** > *** 502,514 **** > $(SRC)\paths.h > > $(SRC)\config.h: config.h > ! copy config.h $(SRC) > > $(SRC)\Emacs.ad.h: Emacs.ad.h > ! copy Emacs.ad.h $(SRC) > > $(SRC)\paths.h: paths.h > ! copy paths.h $(SRC) > > > #----------------------------------------------------------------------- > ------- > > --- 507,519 ---- > $(SRC)\paths.h > > $(SRC)\config.h: config.h > ! @$(COPY) config.h $(SRC) > > $(SRC)\Emacs.ad.h: Emacs.ad.h > ! @$(COPY) Emacs.ad.h $(SRC) > > $(SRC)\paths.h: paths.h > ! @$(COPY) paths.h $(SRC) > > > #----------------------------------------------------------------------- > ------- > > *************** > *** 605,611 **** > link.exe -lib -nologo -out:$@ $(LASTFILE_OBJS) > > $(OUTDIR)\lastfile.obj: $(LASTFILE_SRC)\lastfile.c > ! $(CCV) $(LASTFILE_FLAGS) $(LASTFILE_SRC)\$(@B).c > > !endif > > --- 610,616 ---- > link.exe -lib -nologo -out:$@ $(LASTFILE_OBJS) > > $(OUTDIR)\lastfile.obj: $(LASTFILE_SRC)\lastfile.c > ! $(CCV) $(LASTFILE_FLAGS) $** > > !endif > > *************** > *** 632,653 **** > link.exe -lib -nologo -out:$@ $(LWLIB_OBJS) > > $(OUTDIR)\lwlib-utils.obj: $(LWLIB_SRCDIR)\lwlib-utils.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\lwlib-Xaw.obj: $(LWLIB_SRCDIR)\lwlib-Xaw.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\lwlib-Xlw.obj: $(LWLIB_SRCDIR)\lwlib-Xlw.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\lwlib.obj: $(LWLIB_SRCDIR)\lwlib.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\xlwmenu.obj: $(LWLIB_SRCDIR)\xlwmenu.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > $(OUTDIR)\xlwscrollbar.obj: $(LWLIB_SRCDIR)\xlwscrollbar.c > ! $(CCV) $(LWLIB_FLAGS) $(LWLIB_SRCDIR)\$(@B).c > > !endif > > #----------------------------------------------------------------------- > ------- > --- 637,658 ---- > link.exe -lib -nologo -out:$@ $(LWLIB_OBJS) > > $(OUTDIR)\lwlib-utils.obj: $(LWLIB_SRCDIR)\lwlib-utils.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\lwlib-Xaw.obj: $(LWLIB_SRCDIR)\lwlib-Xaw.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\lwlib-Xlw.obj: $(LWLIB_SRCDIR)\lwlib-Xlw.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\lwlib.obj: $(LWLIB_SRCDIR)\lwlib.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\xlwmenu.obj: $(LWLIB_SRCDIR)\xlwmenu.c > ! $(CCV) $(LWLIB_FLAGS) $** > > $(OUTDIR)\xlwscrollbar.obj: $(LWLIB_SRCDIR)\xlwscrollbar.c > ! $(CCV) $(LWLIB_FLAGS) $** > > !endif > > #----------------------------------------------------------------------- > ------- > *************** > *** 696,702 **** > $(SRC)\getloadavg.c \ > $(SRC)\glyphs.c \ > $(SRC)\glyphs-eimage.c \ > - $(SRC)\glyphs-shared.c \ > $(SRC)\glyphs-widget.c \ > $(SRC)\gui.c \ > $(SRC)\gutter.c \ > --- 701,706 ---- > *************** > *** 988,994 **** > $(OUTDIR)\getloadavg.obj \ > $(OUTDIR)\glyphs.obj \ > $(OUTDIR)\glyphs-eimage.obj \ > - $(OUTDIR)\glyphs-shared.obj \ > $(OUTDIR)\glyphs-widget.obj \ > $(OUTDIR)\gui.obj \ > $(OUTDIR)\gutter.obj \ > --- 992,997 ---- > *************** > *** 1053,1062 **** > $(OUTDIR)\emacs.obj: $(XEMACS)\version.sh > > $(OUTDIR)\TopLevelEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TOP_LEVEL_EMACS_SHELL > $(TEMACS_SRC)\$(@B).c -Fo$@ > > $(OUTDIR)\TransientEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TRANSIENT_EMACS_SHELL > $(TEMACS_SRC)\$(@B).c -Fo$@ > > $(OUTDIR)\alloc.obj: $(TEMACS_SRC)\alloc.c > > --- 1056,1065 ---- > $(OUTDIR)\emacs.obj: $(XEMACS)\version.sh > > $(OUTDIR)\TopLevelEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TOP_LEVEL_EMACS_SHELL $** > -Fo$@ > > $(OUTDIR)\TransientEmacsShell.obj: $(TEMACS_SRC)\EmacsShell-sub.c > ! $(CCV) $(TEMACS_CPP_FLAGS) -DDEFINE_TRANSIENT_EMACS_SHELL $** > -Fo$@ > > $(OUTDIR)\alloc.obj: $(TEMACS_SRC)\alloc.c > > *************** > *** 1407,1428 **** > cd $(NT) > @echo Installing in $(INSTALL_DIR) ... > @echo PlaceHolder > PlaceHolder > ! @xcopy /q PROBLEMS "$(INSTALL_DIR)\" > ! @xcopy /q PlaceHolder "$(INSTALL_DIR)\lock\" > $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" > ! @xcopy /q $(LIB_SRC)\*.exe > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" > ! @copy $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @copy $(CONFIG_VALUES) "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @copy $(SRC)\xemacs.exe "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @xcopy /e /q $(XEMACS)\etc "$(INSTALL_DIR)\etc\" > ! @xcopy /e /q $(XEMACS)\info "$(INSTALL_DIR)\info\" > ! @xcopy /e /q $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... > ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" > ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" > ! @xcopy /q PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" > $(DEL) PlaceHolder > > --- 1410,1431 ---- > cd $(NT) > @echo Installing in $(INSTALL_DIR) ... > @echo PlaceHolder > PlaceHolder > ! @$(COPY) PROBLEMS "$(INSTALL_DIR)\" > ! @$(COPY) PlaceHolder "$(INSTALL_DIR)\lock\" > $(DEL) "$(INSTALL_DIR)\lock\PlaceHolder" > ! @$(COPY) $(LIB_SRC)\*.exe > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)\" > ! @$(COPY) $(LIB_SRC)\DOC "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @$(COPY) $(CONFIG_VALUES) > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @$(COPY) $(SRC)\xemacs.exe > "$(INSTALL_DIR)\$(EMACS_CONFIGURATION)" > ! @$(COPYDIR) $(XEMACS)\etc "$(INSTALL_DIR)\etc\" > ! @$(COPYDIR) $(XEMACS)\info "$(INSTALL_DIR)\info\" > ! @$(COPYDIR) $(XEMACS)\lisp "$(INSTALL_DIR)\lisp\" > @echo Making skeleton package tree in $(PACKAGE_PREFIX) ... > ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\site-packages\" > $(DEL) "$(PACKAGE_PREFIX)\site-packages\PlaceHolder" > ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\mule-packages\" > $(DEL) "$(PACKAGE_PREFIX)\mule-packages\PlaceHolder" > ! @$(COPY) PlaceHolder "$(PACKAGE_PREFIX)\xemacs-packages\" > $(DEL) "$(PACKAGE_PREFIX)\xemacs-packages\PlaceHolder" > $(DEL) PlaceHolder > -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From steve@turnbull.sk.tsukuba.ac.jp Tue May 29 05:19:10 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA11336; Tue, 29 May 2001 05:19:09 -0400 Received: by localhost id m154feJ-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Tue, 29 May 2001 18:18:47 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15123.26999.267830.300137@turnbull.sk.tsukuba.ac.jp> Date: Tue, 29 May 2001 18:18:47 +0900 To: Mike Alexander Cc: "08.58016472@telia.com" <08.58016472@telia.com>, "Michael Sperber [Mr. Preprocessor]" , Thomas Nichols , Mats Lidell , "xemacs-beta@xemacs.org" , "xemacs-nt@xemacs.org" Subject: RE: Help test EFS In-Reply-To: <62478608.3200086907@[148.59.233.133]> References: <01C0E439.CE4C2760.08.58016472@telia.com> <62478608.3200086907@[148.59.233.133]> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid It's not (just) Cygwin. I'm observing a similar problem with the pretest EFS 1.25 on NetBSD 1.5.1alpha. (I've reported this already to efs-bugs, if you want me to repeat details, let me know.) I had to add a similar skip for "227 Entering Passive Mode". (lukem ftp tries passive by default, so I don't see a PORT command.) That did the trick. Thanks, Mike! >>>>> "Mike" == Mike Alexander writes: Mike> I did some debugging tonight and it appears that this Mike> problem is being caused by "200 PORT command successful" Mike> messages coming from the cygwin FTP client after the get Mike> command is issued. EFS was thinking that this response Mike> meant the get command was done when in fact it had only just Mike> started. I fixed it by adding this to my custom.el file: '(efs-skip-msgs-alist (quote (("" . "^110 \\|^125 \\|^150 ") ("^ls \\|^put \\|^get \\|^append \\|passive" . "^500 EPSV not understood") ("^ls \\|^put \\|^get \\|^append " . "^200 PORT command successful"))) t) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From npak@ispras.ru Tue May 29 05:51:02 2001 Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id FAA14260 for ; Tue, 29 May 2001 05:50:55 -0400 Received: (qmail 23275 invoked from network); 29 May 2001 09:50:04 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 29 May 2001 09:50:04 -0000 Received: from fog.ispras.ru (fog [194.67.37.129]) by gate.ispras.ru (8.11.2/8.11.1) with SMTP id f4T9oi804668; Tue, 29 May 2001 13:50:44 +0400 (MSK) Received: tid NAA00680; Wed, 29 May 1996 13:50:34 +0300 Received: from HOOKAH.kasbek.ispras.ru (hookah.kazbek.ispras.ru [194.186.94.160]) by sever.kazbek.ispras.ru (8.11.1/8.11.1) with ESMTP id f4T9p5g68690; Tue, 29 May 2001 13:51:06 +0400 (MSD) (envelope-from npak@ispras.ru) To: "Paul Krause" Cc: "Ben Wing" , Subject: Re: Build failure (head): unresolved external symbols References: From: npak@ispras.ru (Nick Pakoulin) Date: 29 May 2001 13:50:53 +0400 In-Reply-To: "Paul Krause"'s message of "Mon, 28 May 2001 22:28:23 -0400" Message-ID: Lines: 14 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii My fault. I applied a patch for 21.4 and didn't checked it's workability. Nick intro: "PK" == Paul Krause writes: >> From: Ben Wing [mailto:ben@666.com] is glyphs-shared mentioned [twice] in >> xemacs.mak? PK> It is not. It appears to have been removed by PK> revision 1.69 date: 2001/05/27 10:50:44; author: nick; state: Exp; lines: PK> +31 -28 Suppress overwrite confirmation in xemacs.mak From hniksic@arsdigita.com Tue May 29 07:15:46 2001 Received: from florida.arsdigita.de ([212.84.246.66]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA21198 for ; Tue, 29 May 2001 07:15:45 -0400 Received: from hniksic by florida.arsdigita.de with local (Exim 3.12 #1 (Debian)) id 154hSq-0006nZ-00; Tue, 29 May 2001 13:15:04 +0200 Sender: hniksic@florida.arsdigita.de To: Ben Wing Cc: XEmacs Beta List Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> <3B12E379.7DAD1FB7@666.com> X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h Date: 29 May 2001 13:15:04 +0200 In-Reply-To: <3B12E379.7DAD1FB7@666.com> (Ben Wing's message of "Mon, 28 May 2001 16:47:05 -0700") Message-ID: Lines: 7 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Ben Wing writes: > never, or only after 15 seconds? what is the specific example? i recently > checked in code that doesn't slow down interrupts during connect except on > Ultrix. C-g should break immediately. I haven't run that code yet, sorry. Will do. From Ron.Isaacson@morganstanley.com Tue May 29 11:53:39 2001 Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA01921 for ; Tue, 29 May 2001 11:53:39 -0400 Received: from pivsbh2-idmz.ms.com (localhost [127.0.0.1]) by pivsbh2.ms.com (Postfix) with SMTP id BA51D1266 for ; Tue, 29 May 2001 11:53:27 -0400 (EDT) Received: from pismh1.ms.com (unknown [144.14.110.221]) by pivsbh2-idmz.ms.com (Postfix) with ESMTP id 9E03212B5 for ; Tue, 29 May 2001 11:53:27 -0400 (EDT) Received: from morganstanley.com (bk12ronisaacpc.morgan.com [144.14.248.46]) by pismh1.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id LAA18755 for ; Tue, 29 May 2001 11:53:27 -0400 (EDT) Message-ID: <3B13C5F8.BCA359B4@morganstanley.com> Date: Tue, 29 May 2001 11:53:28 -0400 From: Ron Isaacson Reply-To: Ron.Isaacson@morganstanley.com Organization: Morgan Stanley X-Mailer: Mozilla 4.75 [en]C-CCK-MCD MS4.75 V20001029.1 (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: xemacs-beta@xemacs.org Subject: pid trouble on irix64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all -- A user recently reported trouble killing shell buffers under xemacs 21.1.14 on irix64 6.5. The problem seems related to irix's use of 32-bit pid's. Here's an illustration: In the shell buffer: % echo $$ 137547967 In a lisp buffer: (get-buffer-process (get-buffer "*shell*")) # (emacs-pid) 130570717 xemacs thinks the shell process has pid -128902941, when its pid is actually 137547967. This doesn't seem to be a simple signed/unsigned or byte ordering issue: 137547967 = 00001000001100101101000010111111 -128902941 = 11111000010100010001100011100011 xemacs seems to understand the 32-bit pid's in general, since the output from (emacs-pid) is valid. At least the logic seems to follow: * from editfns.c, emacs-pid returns "make_int (getpid ())"; * from process.c, create_process uses make_int to store the pid in the Lisp_Process structure, after getting it from PROCMETH (create_process...), which in this case calls unix_create_process; * from process-unix.c, the pid that unix_create_process returns is the exact output from fork(); * both fork() and getpid() return pid_t's, which are 32-bit integers, same as int. So I can't figure out where this bogus pid is getting introduced! I've tested with other xemacs versions, back to 20.4, and the problem is always present. But there's a new twist in 21.1.14: you can't exit xemacs gracefully. In 20.4, even if you kill your shell process by hand, you'll get a warning when you try to exit that it's still running. But if you ignore the warning you can exit cleanly. In 21.1.14 you get the same warning, but if you try to ignore it and exit anyway, you get stuck in a loop that looks like this: really-early-error-handler((error "kill (-101159227, 1) failed: Invalid argument")) and there's no way out except to kill the xemacs process! Has anyone else seen this behavior? If you need more specific diagnostic information, I can try to provide it. Thanks in advance for any help... -- Ron Isaacson Morgan Stanley ron.isaacson@morganstanley.com / (718) 754-2345 From aichner@ecf.teradyne.com Tue May 29 12:01:34 2001 Received: from showboat.teradyne.com (showboat.teradyne.com [198.51.251.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id MAA02364 for ; Tue, 29 May 2001 12:01:34 -0400 Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id MAA02804 for ; Tue, 29 May 2001 12:01:33 -0400 (EDT) Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id MAA09662 for ; Tue, 29 May 2001 12:01:32 -0400 (EDT) Received: from D5DC120J.ecf.teradyne.com (d5dc120j.ecf.teradyne.com [131.101.192.101]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with ESMTP id RAA15554; Tue, 29 May 2001 17:59:12 +0200 (MET DST) To: XEmacs Beta List Subject: assert in src\event-msw.c (line 1515) in 21.5-b1 X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Date: 29 May 2001 18:01:28 +0200 Message-ID: Lines: 46 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I got this today. Adrian Call Stack: NTDLL! 77fa018c() mswindows_need_event(int 0) line 1515 + 52 bytes emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes event_stream_event_pending_p(int 1) line 441 + 21 bytes detect_input_pending() line 895 + 7 bytes run_pre_idle_hook() line 2006 + 18 bytes Fnext_event(long 51415980, long 20508696) line 2182 Fcommand_loop_1() line 574 + 16 bytes command_loop_1(long 20508696) line 495 condition_case_1(long 20503992, long (long)* 0x01051526 command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 cmd_error(long, long), long 20508696) line 1651 + 7 bytes command_loop_3() line 256 + 35 bytes command_loop_2(long 20508696) line 269 internal_catch(long 20322984, long (long)* 0x01051090 command_loop_2(long), long 20508696, int * volatile 0x00000000) line 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char * * 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, char * * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e97d08() Relevant assert in src\event-msw.c (line 1515): /* This will assert if handle being waited for becomes abandoned. Not the case currently tho */ assert ((!badly_p && active == WAIT_TIMEOUT) || (active >= WAIT_OBJECT_0 && ------> active <= WAIT_OBJECT_0 + mswindows_waitable_count)); Variables: active -1 badly_p 0 mswindows_waitable_count 1 + mswindows_waitable_handles 0x011c9c9c mswindows_waitable_handles what_events 255 -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From jpmail@limolink.com Tue May 29 13:23:22 2001 Received: from spider.crnet.com (spider.crnet.com [208.242.241.92]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA06433; Tue, 29 May 2001 13:23:21 -0400 Received: from mondas (inferno.limolink.com [206.24.61.91]) by spider.crnet.com (8.9.3/8.9.3) with SMTP id NAA09040; Tue, 29 May 2001 13:19:13 -0500 Message-ID: <00dc01c0e863$dbb655a0$6501a8c0@mondas> From: "James N. Potts" To: "XEmacs NT List" Cc: "XEmacs Developers" , References: <200104260935.CAA12758@camelot-soft.camelot-soft.com> Subject: Re: Opening large file (PR#1659) Date: Tue, 29 May 2001 12:21:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 "Hrvoje Niksic" writes: > In this case XEmacs doesn't seem to be at fault. The offending code > in fileio.c looks like this: > > /* Supposedly happens on VMS. */ > if (st.st_size < 0) > signal_error (Qfile_error, "File size is negative", Qunbound); > > /* ... code that checks if st.st_size fits into EMACS_INT. */ > > So XEmacs is directly using the system API to check the file size, and > seems to be getting bogus response. The size returned from the API is correct (unsigned). The real problem is that we're using VC's definition of struct stat, which declares st_size as a signed int. from types.h: >typedef long _off_t; from stat.h: >struct stat { > [...] > _off_t st_size; > [...] > }; We already skip using VC's broken stat command, filling the structure with results from API calls. So on win32, we really need to replace VC's struct stat with an unsigned version. It looks like this wouldn't be too hard, but I won't be able to play with it until later today. -Jim ----- Original Message ----- From: "Hrvoje Niksic" To: "Gunnar Evermann" Cc: "XEmacs Developers" ; Sent: Monday, May 28, 2001 4:18 PM Subject: Re: Opening large file (PR#1659) > Gunnar Evermann writes: > > > something for our signed/unsigned experts: > > > > C_Langmann@gmx.de writes: > > > > > Full_Name: Christian Langmann > > > OS: Windows NT 4.0 > > > Version: 21.1 (patch 9) > > > > > > I tried to open a large ascii-file (3,949,747,976 Bytes) and got the message > > > "File size is negative" > > > > Even if xemacs doesn't support files this big it should still give a > > more useful error message. > > In this case XEmacs doesn't seem to be at fault. The offending code > in fileio.c looks like this: > > /* Supposedly happens on VMS. */ > if (st.st_size < 0) > signal_error (Qfile_error, "File size is negative", Qunbound); > > /* ... code that checks if st.st_size fits into EMACS_INT. */ > > So XEmacs is directly using the system API to check the file size, and > seems to be getting bogus response. > > I can imagine that Win32 has a "native" way of checking the file size, > and that stat() has been kludged to accept whatever value, even if it > goes into the negative range of st_size (which is signed). Under > Unix, stat() would fail unless your program were 64-bit enabled. > > >From this conjecture, I can see two solutions: > > 1. Remove/comment out the "VMS" check. To be sure that we'll fail, > integrate it with the "maximum buffer size exceeded check" below, > so that the latter says: > > if (XINT (end) < 0 || XINT (end) != st.st_size) > ... > > 2. Modify the code so that it uses the correct Win32 call that returns > the length of a possibly 2G+-sized file. Then throw "maximum > buffer size exceeded". > > For obvious practical reasons, I think #1 would be the right solution, > along with a "Happens on Windows" comment that explains why we're > checking for negativeness of XINT (end). > From Adrian.Aichner@t-online.de Tue May 29 13:47:47 2001 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id NAA07596 for ; Tue, 29 May 2001 13:47:47 -0400 Received: from fwd06.sul.t-online.de by mailout06.sul.t-online.de with smtp id 154nao-0001LB-04; Tue, 29 May 2001 19:47:42 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.206]) by fwd06.sul.t-online.com with esmtp id 154nak-0RLGVsC; Tue, 29 May 2001 19:47:38 +0200 To: Jeff Mincy Cc: xemacs-beta@xemacs.org Subject: Re: update package index References: <15118.28191.488551.727963@delphioutpost.com> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: <8zjgavyf.fsf@rapier.ecf.teradyne.com> Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Jeff" == Jeff Mincy writes: What version of efs are you using? You could try the one in Pre-Releases. Latest Installed Package name Vers. Vers. Description =============================================================================== efs 1.25 1.25 Treat files on remote systems the same as local files. Adrian Jeff> When I try to update package index Jeff> (running from 21.1.11 solaris) I get: Jeff> (1) (error/warning) Error in process filter: (ftp-error FTP Error: CWD 550 /pub/xemacs/packages/package-index.LATEST.pgp/: Not a directory. failed: ) Jeff> The problem seems to be that efs insists that the package index file Jeff> is a directory instead of a file, and gets an error when it trys to Jeff> download the index. Jeff> (package-get-locate-index-file nil) ==> Jeff> "/anonymous@ftp.sunsite.utk.edu:pub/xemacs/packages/package-index.LATEST.pgp" Jeff> -jeff -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From mta@arbortext.com Tue May 29 15:34:38 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA12989 for ; Tue, 29 May 2001 15:34:37 -0400 Date: Tue, 29 May 2001 15:33:49 -0400 From: Mike Alexander To: Adrian Aichner , XEmacs Beta List Subject: Re: assert in src\event-msw.c (line 1515) in 21.5-b1 Message-ID: <3307951882.991150429@[172.27.6.51]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit This happens to me every now and then, especially when debugging XEmacs. I submitted a fix a few months ago [1] that simply retried the wait ignoring the bad handle but it was vetoed because it masked a problem instead of fixing it. [1] http://list-archive.xemacs.org/xemacs-patches/200006/msg00024.html Mike Alexander mailto:mta@arbortext.com Arbortext, Inc. +1-734-997-0200 --On Tuesday, May 29, 2001 6:01 PM +0200 Adrian Aichner wrote: > > I got this today. > > Adrian > > Call Stack: > > NTDLL! 77fa018c() > mswindows_need_event(int 0) line 1515 + 52 bytes > emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes > event_stream_event_pending_p(int 1) line 441 + 21 bytes > detect_input_pending() line 895 + 7 bytes > run_pre_idle_hook() line 2006 + 18 bytes > Fnext_event(long 51415980, long 20508696) line 2182 > Fcommand_loop_1() line 574 + 16 bytes > command_loop_1(long 20508696) line 495 > condition_case_1(long 20503992, long (long)* 0x01051526 > command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 > cmd_error(long, long), long 20508696) line 1651 + 7 bytes > command_loop_3() line 256 + 35 bytes > command_loop_2(long 20508696) line 269 > internal_catch(long 20322984, long (long)* 0x01051090 > command_loop_2(long), long 20508696, int * volatile 0x00000000) line > 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + 25 bytes > STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char * * > 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, char * > * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes > KERNEL32! 77e97d08() > > Relevant assert in src\event-msw.c (line 1515): > > /* This will assert if handle being waited for becomes > abandoned. Not the case currently tho */ > assert ((!badly_p && active == WAIT_TIMEOUT) || > (active >= WAIT_OBJECT_0 && > ------> active <= WAIT_OBJECT_0 + mswindows_waitable_count)); > > Variables: > > active -1 > badly_p 0 > mswindows_waitable_count 1 > + mswindows_waitable_handles 0x011c9c9c mswindows_waitable_handles > what_events 255 > > -- > Adrian Aichner > mailto:adrian@xemacs.org > http://www.xemacs.org/ > > From alexm@hsys.msk.ru Tue May 29 15:38:52 2001 Received: from mtu.ru (ns.mtu.ru [195.34.32.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id PAA13211 for ; Tue, 29 May 2001 15:38:51 -0400 X-Recipient: xemacs-beta@xemacs.org Received: from hsys.msk.ru (ppp134-155.dialup.mtu-net.ru [62.118.134.155]) by mtu.ru (Postfix) with ESMTP id 30BD87402 for ; Tue, 29 May 2001 23:38:43 +0400 (MSD) (envelope-from alexm@hsys.msk.ru) Received: (qmail 2665 invoked by uid 1000); 29 May 2001 19:36:19 -0000 Date: 29 May 2001 19:36:19 -0000 Message-ID: <20010529193619.2664.qmail@hsys.msk.ru> From: Alexey Mahotkin To: xemacs-patches@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Mule-related corrections to manual X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Salam, Long ago, under subject "some MULE inconsistencies [with patch]" I've already sent half of that patches. I now retry against 21.4.1 with proper Cc: to xemacs-patches, ChangeLog entries, and more fixes. If you need a patch to mule.texi over my patch from [20 Apr 2001], just ask. Probably more "@cindex"es are needed in mule.texi, I'm not sure. 2001-05-29 Alexey Mahotkin * coding.el: Tiny typo fixed * custom.texi: Documented keyboard shortcut. * mule.texi: Updated to match reality; tiny fixes. =================================================================== RCS file: custom.texi,v retrieving revision 1.1 diff -u -r1.1 custom.texi --- custom.texi 2001/05/29 19:24:00 1.1 +++ custom.texi 2001/05/29 19:24:21 @@ -179,7 +179,8 @@ @findex customize @cindex customization buffer A convenient way to find the user option variables that you want to -change, and then change them, is with @kbd{M-x customize}. This command +change, and then change them, is with @kbd{M-x customize} (or use a +keyboard shortcut, @kbd{C-h C}. This command creates a @dfn{customization buffer} with which you can browse through the Emacs user options in a logically organized structure, then edit and set their values. You can also use the customization buffer to save @@ -203,7 +204,7 @@ @dfn{groups} to help you find them. Groups are collected into bigger groups, all the way up to a master group called @code{Emacs}. - @kbd{M-x customize} creates a customization buffer that shows the + @kbd{M-x customize} (or @kbd{C-h C} creates a customization buffer that shows the top-level @code{Emacs} group and the second-level groups immediately under it. It looks like this, in part: =================================================================== RCS file: mule.texi,v retrieving revision 1.1 diff -u -r1.1 mule.texi --- mule.texi 2001/05/29 18:13:14 1.1 +++ mule.texi 2001/05/29 19:17:36 @@ -13,8 +13,9 @@ @cindex IPA @cindex Japanese @cindex Korean +@cindex Cyrillic @cindex Russian - If you compile XEmacs with mule option, it supports a wide variety of + If you compile XEmacs with Mule option, it supports a wide variety of world scripts, including Latin script, as well as Arabic script, Simplified Chinese script (for mainland of China), Traditional Chinese script (for Taiwan and Hong-Kong), Greek script, Hebrew script, IPA @@ -70,7 +71,7 @@ @cindex language environments All supported character sets are supported in XEmacs buffers if it is -compile with mule; there is no need to select a particular language in +compiled with Mule; there is no need to select a particular language in order to display its characters in an XEmacs buffer. However, it is important to select a @dfn{language environment} in order to set various defaults. The language environment really represents a choice of @@ -89,8 +90,10 @@ the XEmacs session. The supported language environments include: @quotation -Chinese-BIG5, Chinese-CNS, Chinese-GB, Cyrillic-ISO, English, Ethiopic, -Greek, Japanese, Korean, Latin-1, Latin-2, Latin-3, Latin-4, Latin-5. +ASCII, Chinese-BIG5, Chinese-GB, Croatian, Cyrillic-ALT, Cyrillic-ISO, +Cyrillic-KOI8, Cyrillic-Win, Czech, English, Ethiopic, French, German, +Greek, Hebrew, IPA, Japanese, Korean, Latin-1, Latin-2, Latin-3, Latin-4, +Latin-5, Norwegian, Polish, Romanian, Slovenian, Thai-XTIS, Vietnamese. @end quotation Some operating systems let you specify the language you are using by @@ -282,11 +285,15 @@ @item M-x list-coding-systems Display a list of all the supported coding systems. + +@item C-u M-x list-coding-systems +Display comprehensive list of specific details of all supported coding +systems. @end table -@kindex C-h C +@kindex C-x @key{RET} C @findex describe-coding-system - The command @kbd{C-h C} (@code{describe-coding-system}) displays + The command @kbd{C-x RET C} (@code{describe-coding-system}) displays information about particular coding systems. You can specify a coding system name as argument; alternatively, with an empty argument, it describes the coding systems currently selected for various purposes, @@ -435,7 +442,8 @@ command. @item C-x @key{RET} k @var{coding} @key{RET} -Use coding system @var{coding} for keyboard input. +Use coding system @var{coding} for keyboard input. (This feature is +non-functional and is temporarily disabled.) @item C-x @key{RET} t @var{coding} @key{RET} Use coding system @var{coding} for terminal output. @@ -517,6 +525,8 @@ the sequences that are translated are typically sequences of ASCII printing characters. Coding systems typically translate sequences of non-graphic characters. + +(This feature is non-functional and is temporarily disabled.) @kindex C-x RET p @findex set-buffer-process-coding-system =================================================================== RCS file: coding.el,v retrieving revision 1.1 diff -u -r1.1 coding.el --- coding.el 2001/05/29 19:31:22 1.1 +++ coding.el 2001/05/29 18:53:38 @@ -50,7 +50,7 @@ TARGET-TYPE specifies which of them to modify. If it is `file', it affects `file-coding-system-alist' (which see). If it is `process', it affects `process-coding-system-alist' (which see). -If it is `network', it affects `network-codign-system-alist' (which see). +If it is `network', it affects `network-coding-system-alist' (which see). REGEXP is a regular expression matching a target of I/O operation. The target is a file name if TARGET-TYPE is `file', a program name if From Adrian.Aichner@t-online.de Tue May 29 16:01:06 2001 Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA14343; Tue, 29 May 2001 16:01:05 -0400 From: Adrian.Aichner@t-online.de Received: from fwd06.sul.t-online.de by mailout06.sul.t-online.de with smtp id 154pfn-00038B-01; Tue, 29 May 2001 22:00:59 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.206]) by fwd06.sul.t-online.com with esmtp id 154pfb-1zKQy0C; Tue, 29 May 2001 22:00:47 +0200 To: XEmacs Beta List Cc: XEmacs NT List Date: Tue, 29 May 2001 22:00:47 +0200 Message-ID: <154pfb-1zKQy0C@fwd06.sul.t-online.com> X-Sender: 520002458184-0001@t-dialin.net "Rafael Marcus" Subject: [(nowhere)] Re: XEMACS freezes during customize in WIN32 (WIN95) X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Organization: The XEmacs Project Date: 29 May 2001 22:00:41 +0200 Message-ID: Lines: 207 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Hello Rafael, please ask for help on xemacs-beta. That's where I am forwarding this message. The problem brings back memories about an old problem. (require 'compile) would fail the first time around. If you require it again it will work, because defcustom will not run the find command again. However, that problem should not show up in 21.4. See http://list-archive.xemacs.org/cgi-bin/wilma_hiliter/xemacs-patches/200006/msg00026.html?line=48#hilite Does anyone here know about the problem Rafael is seeing? Best regards, Adrian --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-From-Line: rafmarc@home.com Tue May 29 11:11:45 2001 Return-Path: Received: from gwyn.tux.org ([207.96.122.8]) by mailin07.sul.t-online.de with esmtp id 154lFR-0kVBnEC; Tue, 29 May 2001 17:17:29 +0200 Received: from femail21.sdc1.sfba.home.com (femail21.sdc1.sfba.home.com [24.0.95.146]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id LAA32478 for ; Tue, 29 May 2001 11:17:27 -0400 Received: from meow ([24.228.11.221]) by femail21.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010529151726.GPYS2167.femail21.sdc1.sfba.home.com@meow> for ; Tue, 29 May 2001 08:17:26 -0700 Message-ID: <024b01c0e851$ad82cf40$dd0be418@meow> From: "Rafael Marcus" To: "Adrian Aichner" References: Subject: Re: XEMACS freezes during customize in WIN32 (WIN95) Date: Tue, 29 May 2001 11:11:45 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Content-Length: 5539 Lines: 149 Xref: D5DC120J xemacs:1284 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello, Thank you for your help. I enclosed the requested outputs. The output from M-x describe-installationis: OS: Windows_NT XEmacs 21.4.3 \"Academic Rigor\" configured for `i586-pc-win32'. Building XEmacs in \"i:\\build\\xemacs\\xemacs\\nt\". Using compiler \"cl -nologo -W3 -O2 -G5 -ML\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4.3\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for TIFF images. Compiling in support for JPEG images. Compiling in support for X-Face message headers. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Using minimal tagbits. Using indexed lrecord implementation. Using portable dumper. The content of the "Backtrace" buffer is: Signaling: (quit) accept-process-output(#" pid -550903 state:run>) byte-code("..." [display stderr errbuf discard inbuf proc set-process-sentinel # process-send-region 1 buffer-size process-send-eof lambda (proc status) write-region-internal (1+ (buffer-size)) (nil (quote major-rms-kludge-city) nil coding-system-for-write) nil throw call-process-done accept-process-output sit-for 0] 10) call-process-internal("find" nil nil nil "NUL" "-print0") apply(call-process-internal "find" nil nil nil ("NUL" "-print0")) call-process("find" nil nil nil "NUL" "-print0") byte-code("..." [grep-null-device call-process "find" nil "-print0" 0 gnu] 7) (defvar grep-find-use-xargs (byte-code "ÃÂɉÄ&Ã…k­ÂƇ" [grep-null-device call-process "find" nil "-print0" 0 gnu] 7) ("d:\\XEmacs\\xemacs-packages\\lisp\\xemacs-base\\compile.elc" . 9930)) load-internal("compile" nil t nil binary) load("compile" nil t nil) require(compile) byte-code("..." [require compile] 2) byte-code("..." [require custom cus-edit widget build-report autoload ring-insert-at-beginning "ring" efs-copy-file "efs" nil (byte-code "ÀÃ!‡" [require compile] 2) ((error)) (byte-code "ÀÃ!‡" [require pcl-cvs] 2) ((error)) provide build] 3) load-internal("build" nil nil nil binary) load("build") load-library("build") byte-code("..." [load "cus-edit" load-library] 2) custom-load-symbol(emacs) custom-load-widget((custom-group :value emacs :tag "Emacs" :custom-state unknown :documentation-shown t)) custom-group-value-create((custom-group :value emacs :tag "Emacs" :custom-state unknown :documentation-shown t)) widget-apply((custom-group :value emacs :tag "Emacs" :custom-state unknown :documentation-shown t) :value-create) widget-default-create((custom-group :value emacs :tag "Emacs" :custom-state unknown :documentation-shown t)) widget-apply((custom-group :value emacs :tag "Emacs" :custom-state unknown :documentation-shown t) :create) widget-create(custom-group :documentation-shown t :custom-state unknown :tag "Emacs" :value emacs) #((emacs custom-group)) mapcar(# ((emacs custom-group))) custom-buffer-create-internal(((emacs custom-group)) " for group Emacs") custom-buffer-create(((emacs custom-group)) "*Customize Group: Emacs*" " for group Emacs") #("") call-interactively(customize) command-execute(customize t) execute-extended-command(nil) call-interactively(execute-extended-command) Thank you again, Rafael. ----- Original Message ----- From: "Adrian Aichner" Newsgroups: comp.emacs.xemacs Sent: Sunday, May 27, 2001 3:59 AM Subject: Re: XEMACS freezes during customize in WIN32 (WIN95) > >>>>> "R" == R M writes: > > R> When in XEMACS in WIN95 I try to use Options->Advanced(Customize)->Emacs the > R> editor presents > R> the message "Loading build" and freezes. The same happens when I use M-x > R> customize press return > R> and again return after "default emacs". > R> All the other options in the "Options" menu work fine. > > R> Any idea why? > > Please send us the output of > M-x describe-installation > > Try this: > M-x toggle-debug-on-quit > or (setq debug-on-quit t) > > Then invoke the command which hangs XEmacs. > > Now, when you think XEmacs is hung, press C-g. > > Hopefully this will interrupt. > > Send us the contents of the buffer called *Backtrace*. > > Best regards, > > Adrian > > R> Thanks, > R> Rafael. > > > > > > > -- > Adrian Aichner > mailto:adrian@xemacs.org > http://www.xemacs.org/ --=-=-= -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ --=-=-=-- From andy@eri.uchsc.edu Tue May 29 17:31:18 2001 Received: from eri.uchsc.edu (eri.UCHSC.EDU [140.226.149.26]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id RAA19993 for ; Tue, 29 May 2001 17:31:18 -0400 Received: from localhost (andy@localhost) by eri.uchsc.edu (8.9.3+Sun/8.9.1) with ESMTP id PAA16138 for ; Tue, 29 May 2001 15:36:17 -0600 (MDT) Date: Tue, 29 May 2001 15:36:17 -0600 (MDT) From: Andy Fortna To: xemacs-beta@xemacs.org Subject: Syntax Highlighting Problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, Please forgive me, I'm rather new at using Xemacs (21.1 on SunOS) so it is most likely that my question has a simple answer. I code primarilly in Perl and for some reason one of my scripts will not fontify and the syntax will not highlight when I open it using Xemacs. What baffels me is that this one script is the only one out of dozens of scripts with problems. Also, this problem has only come up recently. I'm wondering if there is any possible way that a bad keystroke or bad combination of keystrokes in the script could cause problems when Xemacs scans the code? The code is >7000 lines long and I just went through and made some major revisions, so finding something which I don't know what to look for would be tough. I've messed around with the Syntax Highlight options and nothing seems to correct the problem short of rewriting the code. If you have any thoughts on this I'd greatly appreciate as I'm too much of a rookie to know what else to do. Thank you, Andy Fortna Research Assistant Eleanor Roosevelt Institute 1899 Gaylord Street Denver, CO 80206-1299 Email: andy@eri.uchsc.edu Phone: (303) 336-5681 From Adrian.Aichner@t-online.de Tue May 29 18:11:20 2001 Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id SAA22428 for ; Tue, 29 May 2001 18:11:19 -0400 Received: from fwd00.sul.t-online.de by mailout02.sul.t-online.de with smtp id 154rhr-0003uy-07; Wed, 30 May 2001 00:11:15 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.226.148.242]) by fwd00.sul.t-online.com with esmtp id 154rhn-01TZHkC; Wed, 30 May 2001 00:11:11 +0200 To: Andy Fortna Cc: xemacs-beta@xemacs.org Subject: Re: Syntax Highlighting Problem References: X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 83 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Andy" == Andy Fortna writes: Andy> Hello, Andy> Please forgive me, I'm rather new at using Xemacs (21.1 on Andy> SunOS) so it is most likely that my question has a simple Andy> answer. I code primarilly in Perl and for some reason one Andy> of my scripts will not fontify and the syntax will not So it does not fontify at all? Is the file extension the same of your other scripts? Do any of the files contain "file variables" like # -*-CPerl-*- ? See (Info-goto-node "(xemacs)Choosing Modes") Andy> highlight when I open it using Xemacs. What baffels me is Andy> that this one script is the only one out of dozens of Andy> scripts with problems. Also, this problem has only come up That's pretty strong evidence against this one script, I'd say. Andy> recently. I'm wondering if there is any possible way that a Andy> bad keystroke or bad combination of keystrokes in the script Andy> could cause problems when Xemacs scans the code? The code Sure. I would expect some coloring though. What does the modeline say? Does it contain "CPerl"? Andy> is Andy> > 7000 lines long and I just went through and made some Andy> > major revisions, so Andy> finding something which I don't know what to look for would Andy> be tough. I've messed around with the Syntax Highlight That's why revision control is such a wonderful thing. Andy> options and nothing seems to correct the problem short of Andy> rewriting the code. If you have any thoughts on this I'd Andy> greatly appreciate as I'm too much of a rookie to know what Andy> else to do. You should try to reduce the file size until the problem goes away. Then send us the smallest part of the script which still shows the problem. Use binary search to do this: Is the problem in the first half of the script or in the second? Cut down the part with the problem again and see which part shows the problem. This should allow you to come up with a fairly small test-case. Hope this helps, Adrian Andy> Thank you, Andy> Andy Fortna Andy> Research Assistant Andy> Eleanor Roosevelt Institute Andy> 1899 Gaylord Street Andy> Denver, CO 80206-1299 Andy> Email: andy@eri.uchsc.edu Andy> Phone: (303) 336-5681 -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From CraigL@Knology.net Tue May 29 18:31:13 2001 Received: from smtp3.knology.net (user-24-214-63-13.knology.net [24.214.63.13]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id SAA23852 for ; Tue, 29 May 2001 18:31:13 -0400 Received: (qmail 26205 invoked from network); 29 May 2001 22:27:12 -0000 Received: from user-24-214-46-164.knology.net (HELO craigl.knology.net) (24.214.46.164) by user-24-214-63-13.knology.net with SMTP; 29 May 2001 22:27:12 -0000 From: Craig Lanning MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.8799.314535.534432@gargle.gargle.HOWL> Date: Tue, 29 May 2001 18:27:43 -0400 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: Andy Fortna , xemacs-beta@xemacs.org Subject: Re: Syntax Highlighting Problem In-Reply-To: References: X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid Adrian Aichner writes: > >>>>> "Andy" == Andy Fortna writes: > > > Andy> is > Andy> > 7000 lines long and I just went through and made some What is the size of the file in bytes and what is the value of the variable font-lock-maximum-size? I usually include the form (setq font-lock-maximum-size nil) in my .emacs file to make sure that font-lock is applied to all files no matter what the size. Craig From jpmail@limolink.com Tue May 29 19:35:56 2001 Received: from spider.crnet.com (spider.crnet.com [208.242.241.92]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA27338; Tue, 29 May 2001 19:35:53 -0400 Received: from mondas (inferno.limolink.com [206.24.61.91]) by spider.crnet.com (8.9.3/8.9.3) with SMTP id TAA12170; Tue, 29 May 2001 19:31:47 -0500 Message-ID: <012501c0e897$e8726250$6501a8c0@mondas> From: "James N. Potts" To: "XEmacs NT List" Cc: "XEmacs Developers" References: <200104260935.CAA12758@camelot-soft.camelot-soft.com> <00dc01c0e863$dbb655a0$6501a8c0@mondas> Subject: Re: Opening large file (PR#1659) Date: Tue, 29 May 2001 18:34:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Here's a patch that fixes the "negative file size" problem under Win32. I didn't integrate the "negativeness" check into the size check, because there might be meaning to a negative check on some platform. I also added a check for nFileSizeHigh > 0, since as things stood, xemacs would errantly allow the editing a 4-6 gig (8-10, 12-14, etc) file. If no one sees any problems with these, I'll submit to xemacs-patches. -Jim Index: fileio.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/fileio.c,v retrieving revision 1.66 diff -r1.66 fileio.c 2813a2814,2818 > #ifdef WIN32_NATIVE > /* if size is negative, the file is too large to edit. */ > if (st.st_size < 0) > error ("Maximum buffer size exceeded"); > #else 2816a2822 > #endif Index: nt.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/nt.c,v retrieving revision 1.21 diff -r1.21 nt.c 1446c1446,1449 < buf->st_size = info.nFileSizeLow; --- > if (info.nFileSizeHigh > 0) > buf->st_size = -1; > else > buf->st_size = info.nFileSizeLow; ----- Original Message ----- From: "James N. Potts" To: "XEmacs NT List" Cc: "XEmacs Developers" ; Sent: Tuesday, May 29, 2001 12:21 PM Subject: Re: Opening large file (PR#1659) > "Hrvoje Niksic" writes: > > In this case XEmacs doesn't seem to be at fault. The offending code > > in fileio.c looks like this: > > > > /* Supposedly happens on VMS. */ > > if (st.st_size < 0) > > signal_error (Qfile_error, "File size is negative", Qunbound); > > > > /* ... code that checks if st.st_size fits into EMACS_INT. */ > > > > So XEmacs is directly using the system API to check the file size, and > > seems to be getting bogus response. > > The size returned from the API is correct (unsigned). The real problem is > that we're using VC's definition of struct stat, which declares st_size as > a signed int. > > from types.h: > >typedef long _off_t; > > from stat.h: > >struct stat { > > [...] > > _off_t st_size; > > [...] > > }; > > We already skip using VC's broken stat command, filling the structure with > results from API calls. So on win32, we really need to replace VC's > struct stat with an unsigned version. It looks like this wouldn't be too > hard, but I won't be able to play with it until later today. > > -Jim > > ----- Original Message ----- > From: "Hrvoje Niksic" > To: "Gunnar Evermann" > Cc: "XEmacs Developers" ; > > Sent: Monday, May 28, 2001 4:18 PM > Subject: Re: Opening large file (PR#1659) > > > > Gunnar Evermann writes: > > > > > something for our signed/unsigned experts: > > > > > > C_Langmann@gmx.de writes: > > > > > > > Full_Name: Christian Langmann > > > > OS: Windows NT 4.0 > > > > Version: 21.1 (patch 9) > > > > > > > > I tried to open a large ascii-file (3,949,747,976 Bytes) and got the > message > > > > "File size is negative" > > > > > > Even if xemacs doesn't support files this big it should still give a > > > more useful error message. > > > > In this case XEmacs doesn't seem to be at fault. The offending code > > in fileio.c looks like this: > > > > /* Supposedly happens on VMS. */ > > if (st.st_size < 0) > > signal_error (Qfile_error, "File size is negative", Qunbound); > > > > /* ... code that checks if st.st_size fits into EMACS_INT. */ > > > > So XEmacs is directly using the system API to check the file size, and > > seems to be getting bogus response. > > > > I can imagine that Win32 has a "native" way of checking the file size, > > and that stat() has been kludged to accept whatever value, even if it > > goes into the negative range of st_size (which is signed). Under > > Unix, stat() would fail unless your program were 64-bit enabled. > > > > >From this conjecture, I can see two solutions: > > > > 1. Remove/comment out the "VMS" check. To be sure that we'll fail, > > integrate it with the "maximum buffer size exceeded check" below, > > so that the latter says: > > > > if (XINT (end) < 0 || XINT (end) != st.st_size) > > ... > > > > 2. Modify the code so that it uses the correct Win32 call that returns > > the length of a possibly 2G+-sized file. Then throw "maximum > > buffer size exceeded". > > > > For obvious practical reasons, I think #1 would be the right solution, > > along with a "Happens on Windows" comment that explains why we're > > checking for negativeness of XINT (end). > > > > > From steve@turnbull.sk.tsukuba.ac.jp Tue May 29 20:49:26 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA31052 for ; Tue, 29 May 2001 20:49:24 -0400 Received: by localhost id m154u9Y-00013jC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 30 May 2001 09:48:00 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.17208.904617.862890@turnbull.sk.tsukuba.ac.jp> Date: Wed, 30 May 2001 09:47:52 +0900 To: Jeff Mincy Cc: xemacs-beta@xemacs.org Subject: update package index In-Reply-To: <15118.28191.488551.727963@delphioutpost.com> References: <15118.28191.488551.727963@delphioutpost.com> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "Jeff" == Jeff Mincy writes: Jeff> The problem seems to be that efs insists that the package Jeff> index file is a directory instead of a file, and gets an Jeff> error when it trys to download the index. As Adrian says, you may be using an out-of-date EFS. For future reference, EFS is a program that tries to be fool-proof, and the fools always stay ahead of it. It turns out that there are a number of (now older) ftpds that do not give reliable indications about file status. A failed CWD seems to be the most reliable way of finding out that an object is not a directory. OTOH, on some platforms fetching a directory leads to disaster (it tars up the whole directory and sends it to you). So EFS always tries a CWD to an object. On the newer versions of EFS (in particular efs-1.25-pkg, in pretest), you need to watch out for "smart" ftp clients that try various things (in particular passive access) automatically, and return messages that EFS doesn't recognize and takes as fatal errors. Two that I know you need to watch for are PORT and Entering Passive Mode. >>>>> "Mike" == Mike Alexander writes: Mike> I did some debugging tonight and it appears that this Mike> problem is being caused by "200 PORT command successful" Mike> messages coming from the cygwin FTP client after the get Mike> command is issued. EFS was thinking that this response Mike> meant the get command was done when in fact it had only just Mike> started. I fixed it by adding this to my custom.el file: '(efs-skip-msgs-alist (quote (("" . "^110 \\|^125 \\|^150 ") ("^ls \\|^put \\|^get \\|^append \\|passive" . "^500 EPSV not understood") ("^ls \\|^put \\|^get \\|^append " . "^227 Entering Passive Mode") ("^ls \\|^put \\|^get \\|^append " . "^200 PORT command successful"))) t) Alternatively in your init file: (setq efs-skip-msgs-alist (quote (("" . "^110 \\|^125 \\|^150 ") ("^ls \\|^put \\|^get \\|^append \\|passive" . "^500 EPSV not understood") ("^ls \\|^put \\|^get \\|^append " . "^227 Entering Passive Mode") ("^ls \\|^put \\|^get \\|^append " . "^200 PORT command successful")))) (Actually, I recommend not doing this automatically, but that's up to you.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From steve@turnbull.sk.tsukuba.ac.jp Tue May 29 21:15:36 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA32418 for ; Tue, 29 May 2001 21:15:35 -0400 Received: by localhost id m154ua2-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Wed, 30 May 2001 10:15:22 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.18858.747544.863624@turnbull.sk.tsukuba.ac.jp> Date: Wed, 30 May 2001 10:15:22 +0900 To: Andy Fortna Cc: xemacs-beta@xemacs.org Subject: Syntax Highlighting Problem In-Reply-To: References: X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "Andy" == Andy Fortna writes: Andy> I'm wondering if there is any possible way that a bad Andy> keystroke or bad combination of keystrokes in the script Andy> could cause problems when Xemacs scans the code? Yes, this is possible. Several complex kinds of code interact in font-lock. It is occasionally the case with this kind of problem that simply inserting a newline or a comment in the right place will suddenly allow font-lock to proceed. Such problems are much more common with development versions, though. It's unusual in 21.1. As recommended by Adrian and Craig, you can do binary search on the file. You can use M-x font-lock-fontify-region to fontify regions. Also look at the " *Message-Log*" buffer (the quote marks should be omitted, the leading space is significant) to see if there are any interesting messages or (more interesting!) missing ones. Font-lock is normally pretty verbose, telling you about each of several phases. To see what's "normal", font-lock one buffer that "works." -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From ben@666.com Tue May 29 21:28:52 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id VAA00539 for ; Tue, 29 May 2001 21:28:52 -0400 Received: (qmail 50511 invoked by alias); 30 May 2001 01:27:32 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 48509 invoked by uid 0); 30 May 2001 01:26:42 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 30 May 2001 01:26:42 -0000 Message-ID: <3B144CB8.96A3C52@666.com> Date: Tue, 29 May 2001 18:28:24 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Stodghill CC: ding@gnus.org, xemacs-beta@xemacs.org Subject: Re: critical quit Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop References: <3B1076A3.66A6504@666.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Stodghill wrote: > > Ben wrote, > > [3] if you can, please update to the latest xemacs 21.5 cvs on cygwin, > > and check whether C-g works for you by typing (while t) in a scratch > > buffer, hitting C-j, then C-g and/or C-Sh-g. > > Partial success. > > (while t) - C-g and C-Sh-g both work. > > M-q in a "*message* buffer - C-g and C-Sh-g both work. > > (let ((inhibit-quite t)) (while t) - Neither C-g now C-Sh-g work. > > Ben, your changes are certainly an improvement. Thanks. actually, i also found this bug, and i'll soon be posting a patch. [in the meantime, try holding down C-Sh-g, and you might get a break after awhile] -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From ben@666.com Tue May 29 21:29:11 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id VAA00562 for ; Tue, 29 May 2001 21:29:11 -0400 Received: (qmail 52964 invoked by alias); 30 May 2001 01:28:41 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 52843 invoked by uid 0); 30 May 2001 01:28:38 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 30 May 2001 01:28:38 -0000 Message-ID: <3B144D2D.5F0211E8@666.com> Date: Tue, 29 May 2001 18:30:21 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Alexander CC: Adrian Aichner , XEmacs Beta List Subject: Re: assert in src\event-msw.c (line 1515) in 21.5-b1 References: <3307951882.991150429@[172.27.6.51]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit does this tend to occur after you've run some processes, esp. more than one at once? Mike Alexander wrote: > > This happens to me every now and then, especially when debugging > XEmacs. I submitted a fix a few months ago [1] that simply retried the > wait ignoring the bad handle but it was vetoed because it masked a > problem instead of fixing it. > > [1] http://list-archive.xemacs.org/xemacs-patches/200006/msg00024.html > > Mike Alexander mailto:mta@arbortext.com > Arbortext, Inc. +1-734-997-0200 > > --On Tuesday, May 29, 2001 6:01 PM +0200 Adrian Aichner > wrote: > > > > > I got this today. > > > > Adrian > > > > Call Stack: > > > > NTDLL! 77fa018c() > > mswindows_need_event(int 0) line 1515 + 52 bytes > > emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes > > event_stream_event_pending_p(int 1) line 441 + 21 bytes > > detect_input_pending() line 895 + 7 bytes > > run_pre_idle_hook() line 2006 + 18 bytes > > Fnext_event(long 51415980, long 20508696) line 2182 > > Fcommand_loop_1() line 574 + 16 bytes > > command_loop_1(long 20508696) line 495 > > condition_case_1(long 20503992, long (long)* 0x01051526 > > command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 > > cmd_error(long, long), long 20508696) line 1651 + 7 bytes > > command_loop_3() line 256 + 35 bytes > > command_loop_2(long 20508696) line 269 > > internal_catch(long 20322984, long (long)* 0x01051090 > > command_loop_2(long), long 20508696, int * volatile 0x00000000) line > > 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + 25 bytes > > STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char * * > > 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, char * > > * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes > > KERNEL32! 77e97d08() > > > > Relevant assert in src\event-msw.c (line 1515): > > > > /* This will assert if handle being waited for becomes > > abandoned. Not the case currently tho */ > > assert ((!badly_p && active == WAIT_TIMEOUT) || > > (active >= WAIT_OBJECT_0 && > > ------> active <= WAIT_OBJECT_0 + mswindows_waitable_count)); > > > > Variables: > > > > active -1 > > badly_p 0 > > mswindows_waitable_count 1 > > + mswindows_waitable_handles 0x011c9c9c mswindows_waitable_handles > > what_events 255 > > > > -- > > Adrian Aichner > > mailto:adrian@xemacs.org > > http://www.xemacs.org/ > > > > -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From jeff@delphioutpost.com Tue May 29 23:23:53 2001 Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA05112 for ; Tue, 29 May 2001 23:23:53 -0400 Received: from 146-115-66-29.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com ([146.115.66.29] helo=antarres.muniversal.com) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.22 #6) id 154waO-000733-00 ; Tue, 29 May 2001 23:23:52 -0400 From: Jeff Mincy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.26693.40000.96259@antarres.muniversal.com> Date: Tue, 29 May 2001 23:25:57 -0400 To: Adrian.Aichner@t-online.de (Adrian Aichner) Cc: xemacs-beta@xemacs.org Subject: Re: update package index In-Reply-To: <8zjgavyf.fsf@rapier.ecf.teradyne.com> References: <15118.28191.488551.727963@delphioutpost.com> <8zjgavyf.fsf@rapier.ecf.teradyne.com> X-Mailer: VM 6.92 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid From: Adrian.Aichner@t-online.de (Adrian Aichner) Date: 29 May 2001 19:47:36 +0200 >>>>> "Jeff" == Jeff Mincy writes: What version of efs are you using? Ummm. I forget what version of efs I was using (sorry, too many versions of too many things) but upgrading to 1.22 worked better. In the earlier release of efs (solaris 2.1.11) I got the 'Error in process filter' type error. When I upgraded to 1.22 I got the following. --- Opening input file: No such file or directory, /anonymous@ftp.sunsite.utk.edu:/pub/xemacs/packages/package-index.LATEST.pgp Listing /anonymous@ftp.sunsite.utk.edu:/pub/xemacs/packages/...done Listing /anonymous@ftp.sunsite.utk.edu:/pub/xemacs/packages/... CWD'ing to /anonymous@ftp.sunsite.utk.edu:/pub/xemacs/packages/...done CWD'ing to /anonymous@ftp.sunsite.utk.edu:/pub/xemacs/packages/... > ing to /anonymous@ftp.sunsite.utk.edu:/pub/xemacs/packages/package-index.LATEST.pgp/... Logging in as user anonymous...done; MOTD of 22 lines Logging in as user anonymous... Opening FTP connection to ftp.sunsite.utk.edu... --- M-x find-file-at-point (which I think uses the same efs stuff) was able to find the package-index.LATEST.pgp file with no problems. I was able to save the package-index file and go from there. I'll try to upgrade efs to 1.25 soon, I've figured out how to babysit the process. -jeff You could try the one in Pre-Releases. Latest Installed Package name Vers. Vers. Description =============================================================================== efs 1.25 1.25 Treat files on remote systems the same as local files. Jeff> When I try to update package index Jeff> (running from 21.1.11 solaris) I get: Jeff> (1) (error/warning) Error in process filter: (ftp-error FTP Error: CWD 550 /pub/xemacs/packages/package-index.LATEST.pgp/: Not a directory. failed: ) Jeff> The problem seems to be that efs insists that the package index file Jeff> is a directory instead of a file, and gets an error when it trys to Jeff> download the index. Jeff> (package-get-locate-index-file nil) ==> Jeff> "/anonymous@ftp.sunsite.utk.edu:pub/xemacs/packages/package-index.LATEST.pgp" From mta@arbortext.com Wed May 30 01:28:36 2001 Received: from sprouts.arbortext.com ([198.108.59.202]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA12036 for ; Wed, 30 May 2001 01:28:31 -0400 Date: Wed, 30 May 2001 01:28:57 -0400 From: Mike Alexander To: Ben Wing cc: Adrian Aichner , XEmacs Beta List Subject: Re: assert in src\event-msw.c (line 1515) in 21.5-b1 Message-ID: <3343659701.991186137@[172.27.6.51]> In-Reply-To: <3B144D2D.5F0211E8@666.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Yes, it seems to be associated with having run processes in the recent past. It doesn't seem to be related to running more than one at a time, although I don't know for sure since I'm not always aware of when xemacs runs something on my behalf. I actually don't see this all that much since my copy of xemacs has this patch applied. I've run a few times recently without it and have seen the problem then. If I let xemacs sit at a breakpoint for a while it seems to make the problem more likely to occur. This is another reason I think it is a timing problem of some sort. Mike --On Tuesday, May 29, 2001 6:30 PM -0700 Ben Wing wrote: > does this tend to occur after you've run some processes, esp. more > than one at once? > > Mike Alexander wrote: >> >> This happens to me every now and then, especially when debugging >> XEmacs. I submitted a fix a few months ago [1] that simply retried >> the wait ignoring the bad handle but it was vetoed because it masked >> a problem instead of fixing it. >> >> [1] >> http://list-archive.xemacs.org/xemacs-patches/200006/msg00024.html >> >> Mike Alexander mailto:mta@arbortext.com >> Arbortext, Inc. +1-734-997-0200 >> >> --On Tuesday, May 29, 2001 6:01 PM +0200 Adrian Aichner >> wrote: >> >> > >> > I got this today. >> > >> > Adrian >> > >> > Call Stack: >> > >> > NTDLL! 77fa018c() >> > mswindows_need_event(int 0) line 1515 + 52 bytes >> > emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes >> > event_stream_event_pending_p(int 1) line 441 + 21 bytes >> > detect_input_pending() line 895 + 7 bytes >> > run_pre_idle_hook() line 2006 + 18 bytes >> > Fnext_event(long 51415980, long 20508696) line 2182 >> > Fcommand_loop_1() line 574 + 16 bytes >> > command_loop_1(long 20508696) line 495 >> > condition_case_1(long 20503992, long (long)* 0x01051526 >> > command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 >> > cmd_error(long, long), long 20508696) line 1651 + 7 bytes >> > command_loop_3() line 256 + 35 bytes >> > command_loop_2(long 20508696) line 269 >> > internal_catch(long 20322984, long (long)* 0x01051090 >> > command_loop_2(long), long 20508696, int * volatile 0x00000000) >> > line 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + >> > 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char >> > * * 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, >> > char * * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes >> > KERNEL32! 77e97d08() >> > >> > Relevant assert in src\event-msw.c (line 1515): >> > >> > /* This will assert if handle being waited for becomes >> > abandoned. Not the case currently tho */ >> > assert ((!badly_p && active == WAIT_TIMEOUT) || >> > (active >= WAIT_OBJECT_0 && >> > ------> active <= WAIT_OBJECT_0 + >> > mswindows_waitable_count)); >> > >> > Variables: >> > >> > active -1 >> > badly_p 0 >> > mswindows_waitable_count 1 >> > + mswindows_waitable_handles 0x011c9c9c >> > mswindows_waitable_handles what_events 255 >> > >> > -- >> > Adrian Aichner >> > mailto:adrian@xemacs.org >> > http://www.xemacs.org/ >> > >> > > > -- > ben > > I'm sometimes slow in getting around to reading my mail, so if you > want to reach me faster, call 520-661-6661. > > See http://www.666.com/ben/chronic-pain/ for the hell I've been > through. From karlheg@hegbloom.net Wed May 30 01:55:15 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id BAA13012 for ; Wed, 30 May 2001 01:55:14 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4U5t969012947 for ; Tue, 29 May 2001 22:55:09 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4U5t9Yp012942; Tue, 29 May 2001 22:55:09 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: Warning! dired may be following symlinks during recursive rm ! From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 29 May 2001 22:55:09 -0700 Message-ID: <87ae3ve5z6.fsf@bittersweet.intra.hegbloom.net> Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I had a "test-config" directory where I ran configure, and a build failed... then I used `dired' to rm it, said yes to the "recurse" question. Now the contents of /etc/* are gone. This has happened before and I think it's dired doing it. From gshapiro@gshapiro.net Wed May 30 02:08:03 2001 Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA13485 for ; Wed, 30 May 2001 02:08:02 -0400 Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.4/8.11.4) id f4U67rE76307; Tue, 29 May 2001 23:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.36408.863887.305626@horsey.gshapiro.net> Date: Tue, 29 May 2001 23:07:52 -0700 From: Gregory Neil Shapiro To: karlheg@hegbloom.net (Karl M. Hegbloom) Cc: XEmacs Beta Subject: Re: Warning! dired may be following symlinks during recursive rm ! In-Reply-To: <87ae3ve5z6.fsf@bittersweet.intra.hegbloom.net> References: <87ae3ve5z6.fsf@bittersweet.intra.hegbloom.net> X-Mailer: VM 6.92 under 21.5 (beta1) "anise" XEmacs Lucid karlheg> I had a "test-config" directory where I ran configure, and a build karlheg> failed... then I used `dired' to rm it, said yes to the "recurse" karlheg> question. karlheg> Now the contents of /etc/* are gone. This has karlheg> happened before and I think it's dired doing it. Judging by the code, you are correct: (defun dired-recursive-delete-directory (fn) ;; Recursively deletes directory FN, and all of its contents. (let* ((fn (expand-file-name fn)) ... (let ((files (directory-files fn t))) (while files (let ((file (car files))) (if (not (member (file-name-nondirectory file) '("." ".."))) (if (file-directory-p file) (dired-recursive-delete-directory file) (delete-file file))) (setq files (cdr files)))) (delete-directory fn)))))) The test: (if (file-directory-p file) Is broken: > ls -lagd .tcshrc Work x -rw-r--r-- 1 gshapiro gshapiro 599 Jan 17 1999 .tcshrc drwx------ 4 gshapiro gshapiro 512 May 29 17:18 Work lrwxr-xr-x 1 gshapiro gshapiro 4 May 29 23:02 x -> Work ELISP> (file-directory-p (expand-file-name "~/Work")) t ELISP> (file-directory-p (expand-file-name "~/.tcshrc")) nil ELISP> (file-directory-p (expand-file-name "~/x")) t So when it recurses, the: (let ((files (directory-files fn t))) catches the files in the symlinked directory. This should be enough to fix it: --- dired.el~ Thu Apr 5 04:53:37 2001 +++ dired.el Tue May 29 23:06:42 2001 @@ -3608,7 +3608,8 @@ (let ((file (car files))) (if (not (member (file-name-nondirectory file) '("." ".."))) - (if (file-directory-p file) + (if (and (file-directory-p file) + (not (file-symlink-p file))) (dired-recursive-delete-directory file) (delete-file file))) (setq files (cdr files)))) From karlheg@hegbloom.net Wed May 30 02:29:39 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id CAA14170 for ; Wed, 30 May 2001 02:29:38 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4U6Tb69017901 for ; Tue, 29 May 2001 23:29:37 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4U6TblI017898; Tue, 29 May 2001 23:29:37 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: XEmacs Beta Subject: cvs-work-backup : Helper script - run it from crontab. From: karlheg@hegbloom.net (Karl M. Hegbloom) Date: 29 May 2001 23:29:37 -0700 Message-ID: <87wv6zcpta.fsf@bittersweet.intra.hegbloom.net> Lines: 22 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Attached - freshest version (barring disaster) will always be at: CVSROOT=:pserver:anoncvs@cvs.hegbloom.net:/var/cvs/debian cvs checkout cvs-toolkit/cvs-work-backup I run this from my .crontab every few hours, like this: 00 0-23/3 * * * /usr/local/bin/cvs-work-backup --backup-dir /home/karlheg/Backup /usr/local/src/Packages/xemacs/{debian.xemacs,debian.xemacs-packages,xemacs-packages,xemacs-21.4,xemacs-21.5} It helps bulletproof me against command line typos and cleanfreak makefile targets, and perhaps against the `dired' follows symlinks bug. With that one, with a recent archive created by this thing, I can just restore that archive and cvs update to recover. Please let me know how it works for you, etc. I hope that the XEmacs repository has a good backup system! What is used there? I am curious about such things. --=-=-= Content-Type: application/x-perl Content-Disposition: attachment; filename=cvs-work-backup Content-Transfer-Encoding: quoted-printable #! /usr/bin/perl -w # # `cvs-work-backup' # # $Id: cvs-work-backup,v 1.10 2001/05/30 06:10:02 karlheg Exp $ # # Copyright =A9 1998-2001, Karl M. Hegbloom # GPL forever. Long live GNU. # require v5.6; use strict; use Getopt::Mixed; use Fcntl; use Cwd; use File::Find; use Compress::Zlib (); use Archive::Tar; my $n_errors =3D 0; our ($opt_h, $opt_v, $opt_n, $opt_d); Getopt::Mixed::getOptions (qw (h help>h v verbose>v n=3Di number-of-rotations>n d=3Ds backup-dir>d )); $opt_n =3D 3 unless $opt_n; $opt_d =3D getcwd unless $opt_d; $| =3D 1 if $opt_v; if ($opt_h or 0 =3D=3D scalar @ARGV or 0 =3D=3D scalar grep {-d $_} @ARGV) { print STDERR << "EOF"; Usage: cvs-work-backup [] work_checkout_directory ... [-n int | --n-rotations int] (3) [-d dir | --backup-dir dir] (PWD) [-v | --verbose] (no) [-h | --help] \`cvs-work-backup\' will back up the files you have modified since the last \`cvs commit\', as well as any files in your checkout directory that are not under CVS control. It is designed to be called from a developer\'s \`.crontab\'. EOF exit 1; } unless (-d $opt_d and -w _ and -x _) { warn "--backup-dir ($opt_d) must exist, be accessible, and writeable.\n= "; exit 1; } my $orig_cwd =3D getcwd; WORK_DIR: foreach my $work_dir_name (@ARGV) { my $cwd; chdir $orig_cwd; unless (-d $work_dir_name) { warn "Error: '$work_dir_name' does not exist : $! : Skipping.\n"; $n_errors++; next WORK_DIR; } my ($work_dir_uid, $work_dir_gid) =3D (stat (_))[4,5]; unless (-r _) { warn "Error: $work_dir_name is not readable: $! : Skipping.\n"; $n_errors++; next WORK_DIR; } unless (chdir ($work_dir_name) and $cwd =3D getcwd) { warn "Error: chdir failed. ($work_dir_name): $! : Skipping.\n"; $n_errors++; next WORK_DIR; } unless (-d "./CVS/" && -f "./CVS/Entries") { warn "Error: Skipping non CVS-checkout directory: $work_dir_name\n"; $n_errors++; next WORK_DIR; } my $volume_name =3D $work_dir_name; $volume_name =3D~ s,/$,,; $volume_name =3D~ s,^/,,; $volume_name =3D~ s,/,_,g; my $login =3D (getpwuid ($work_dir_uid))[0]; if (! $login) { warn "UID $work_dir_uid does not have a login ID. Using UID.\n"; ++$n_errors; $login =3D $work_dir_uid; } # Archives are named starting with $login so they sort by owner. $volume_name =3D "$opt_d/$login.$volume_name.tar.gz"; my $found_newer =3D undef; if (-e $volume_name) { if (! -f $volume_name ) { warn "Error: $volume_name is not a regular file! Skipping $work_dir_n= ame.\n"; ++$n_errors; next WORK_DIR; } else { print "Looking for files that are have been modified since the last ar= chive was made... " if $opt_v; my ($st_mtime) =3D (stat (_))[9]; eval { find (sub { my ($_st_mtime) =3D (stat ($_))[9]; if ($_st_mtime > $st_mtime) { die 'found_newer'; } else { return 0; } }, $cwd); }; $found_newer++ if $@; print "done.\n" if $opt_v; } unless ($found_newer) { print "Backup archive is up to date. Skipping $work_dir_name.\n" if $= opt_v; next WORK_DIR; } } print "Checking for changed or non-CVS-controlled files in $cwd ... " i= f $opt_v; my ($ra_modified_CVS, $ra_removed_CVS, $ra_non_CVS) =3D eval { cvs_modi= fied ($cwd) }; if ($@) { warn "\n" . $@ . "Skipping $work_dir_name.\n"; ++$n_errors; next WORK_DIR; } print "done.\n" if $opt_v; my $old_cwd =3D getcwd; unless (chdir '..' and $cwd =3D getcwd) { warn "Error: cannot chdir .. : $!\n"; ++$n_errors; next WORK_DIR; } my $len =3D length $cwd; my $prefix =3D substr $old_cwd, ++$len; my @backup =3D map {$prefix . '/' . $_} @$ra_modified_CVS, @$ra_non_CVS; unless (scalar @backup) { print "No files needing archived\n" if $opt_v; next WORK_DIR; } if (-f $volume_name ) { print "Rotating $volume_name\n" if $opt_v; for (my $i =3D $opt_n; $i >=3D 1; $i--) { my $next =3D $volume_name; $next =3D~ s,\.tar\.gz$,,; my $prev =3D $next; $next =3D $next . '.' . $i . '.tar.gz'; $prev =3D $prev . '.' . ($i - 1) . '.tar.gz'; if (-r $prev && -f $prev) { print "$prev to $next\n" if $opt_v; unless (rename ($prev, $next)) { warn "Error: rename failed: ($prev, $next): $!\n"; ++$n_errors; next WORK_DIR; } } } my $dot_zero =3D $volume_name; $dot_zero =3D~ s,\.tar\.gz$,,; $dot_zero =3D $dot_zero . '.0.tar.gz'; print "$volume_name to $dot_zero\n" if $opt_v; unless (rename ($volume_name, $dot_zero)) { warn "Error: rename failed: ($volume_name, $dot_zero): $!\n"; ++$n_errors; next WORK_DIR; } } print "Adding files to $volume_name:\n" if $opt_v; print join "\n", @backup if $opt_v; print "\n" if $opt_v; Archive::Tar->create_archive ($volume_name, 9, @backup); unless (chown ($>, $work_dir_gid, $volume_name)) { warn "Error: chown failed ($>, $work_dir_gid, $volume_name): $!\n"; ++$n_errors; next WORK_DIR; } unless (chmod (0640, $volume_name)) { warn "Error: chmod failed (0640, $volume_name): $!\n"; ++$n_errors; next WORK_DIR; } next WORK_DIR; } exit ($n_errors); sub cvs_modified # Returns: An array of references to 3 arrays: # # \@modified_CVS -- Files under CVS control that are ostensibly # locally-modified; ie, they have an st_mtime newer # than the timestamp recorded in the CVS/Entries # file. # # \@removed_CVS -- Files listed as being under CVS control that are # not present in the filesystem. # # \@non_CVS -- Files extant in the filesystem that are NOT listed as # being under CVS control. # # # Adapted from a script sent to the mailing # list by Martin Buchholz. # { my $dir =3D shift; my @all_found_non_CVS; my %CVS_controlled_files; my @modified_CVS; my @removed_CVS; my @non_CVS; my $popd =3D getcwd(); die "cvs_modified: Cannot chdir($dir)" unless chdir ($dir); my $cwd =3D getcwd(); die "cvs_modified: Cannot stat $cwd/CVS/Entries" unless (-r "$cwd/CVS/E= ntries"); my $wanted =3D sub { my $cwd_relative_name; if ($File::Find::name =3D~ m,/CVS/Entries$,) { die "cvs_modified: Cannot open $File::Find::name" unless open (ENTRIES, $File::Find::name); (my $dotdot =3D $File::Find::dir) =3D~ s{/CVS/?}{}; while () { next unless m{^/}; my ($name, $revision, $timestamp) =3D (split ('/'))[1,2,3]; =09=09 ($cwd_relative_name =3D "$dotdot/$name") =3D~ s{$cwd/}{}; =09=09 $CVS_controlled_files{$cwd_relative_name} =3D 1; =09=09 my ($st_mtime) =3D (stat ("$dotdot/$name"))[9]; unless (defined $st_mtime) { push (@removed_CVS, $cwd_relative_name); next; } =09=09 my $file_timestamp =3D scalar gmtime ($st_mtime); next if $timestamp eq $file_timestamp; =09=09 push (@modified_CVS, $cwd_relative_name); } close (ENTRIES); } elsif (! -d $File::Find::name) { ($cwd_relative_name =3D $File::Find::name) =3D~ s{$cwd/}{}; push (@all_found_non_CVS, $cwd_relative_name); } }; find ( $wanted, $cwd ); @non_CVS =3D grep {! exists $CVS_controlled_files{$_}} @all_found_non_C= VS; die "cvs_modified: Cannot chdir ($popd)" unless chdir ($popd); return (\@modified_CVS, \@removed_CVS, \@non_CVS); } --=-=-=-- From Adrian.Aichner@t-online.de Wed May 30 03:17:20 2001 Received: from mailout02.sul.t-online.de (mailout02.sul.t-online.com [194.25.134.17]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA15813 for ; Wed, 30 May 2001 03:17:19 -0400 Received: from fwd06.sul.t-online.de by mailout02.sul.t-online.de with smtp id 1550EI-00054Z-09; Wed, 30 May 2001 09:17:18 +0200 Received: from D5DC120J.t-online.de (520002458184-0001@[62.155.143.103]) by fwd06.sul.t-online.com with esmtp id 1550EA-1O5PI8C; Wed, 30 May 2001 09:17:10 +0200 To: "Stephen J. Turnbull" Cc: Andy Fortna , xemacs-beta@xemacs.org Subject: Re: Syntax Highlighting Problem References: <15124.18858.747544.863624@turnbull.sk.tsukuba.ac.jp> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520002458184-0001@t-dialin.net >>>>> "Stephen" == Stephen J Turnbull writes: >>>>> "Andy" == Andy Fortna writes: Andy> I'm wondering if there is any possible way that a bad Andy> keystroke or bad combination of keystrokes in the script Andy> could cause problems when Xemacs scans the code? Stephen> Yes, this is possible. Several complex kinds of code Stephen> interact in font-lock. It is occasionally the case with Stephen> this kind of problem that simply inserting a newline or a Stephen> comment in the right place will suddenly allow font-lock Stephen> to proceed. Stephen> Such problems are much more common with development Stephen> versions, though. It's unusual in 21.1. Stephen> As recommended by Adrian and Craig, you can do binary Stephen> search on the file. You can use M-x Stephen> font-lock-fontify-region to fontify regions. Stephen> Also look at the " *Message-Log*" buffer (the quote marks Stephen> should be omitted, the leading space is significant) to Andy, just use M-x show-message-log to access it. Stephen> see if there are any interesting messages or (more Stephen> interesting!) missing ones. Font-lock is normally pretty Stephen> verbose, telling you about each of several phases. Stephen> To see what's "normal", font-lock one buffer that Stephen> "works." Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From ben@666.com Wed May 30 03:44:22 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id DAA16828 for ; Wed, 30 May 2001 03:44:22 -0400 Received: (qmail 87892 invoked by alias); 30 May 2001 07:44:20 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 87858 invoked by uid 0); 30 May 2001 07:44:19 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 30 May 2001 07:44:19 -0000 Message-ID: <3B14A539.48D185E3@666.com> Date: Wed, 30 May 2001 00:46:01 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Alexander CC: Adrian Aichner , XEmacs Beta List Subject: Re: assert in src\event-msw.c (line 1515) in 21.5-b1 References: <3343659701.991186137@[172.27.6.51]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Alexander wrote: > > Yes, it seems to be associated with having run processes in the recent > past. It doesn't seem to be related to running more than one at a > time, although I don't know for sure since I'm not always aware of when > xemacs runs something on my behalf. I actually don't see this all that > much since my copy of xemacs has this patch applied. I've run a few > times recently without it and have seen the problem then. If I let > xemacs sit at a breakpoint for a while it seems to make the problem > more likely to occur. This is another reason I think it is a timing > problem of some sort. i don't doubt it's a timing problem. i have an old workspace sitting around that contains separate stderr support for processes; it also has a fix to properly support reaping the status when multiple processes have been run at once. [unfortunately i don't have time now to get that ws finished up and checked in] i ask about multiple processes because i know this bug exists. > > Mike > > --On Tuesday, May 29, 2001 6:30 PM -0700 Ben Wing wrote: > > > does this tend to occur after you've run some processes, esp. more > > than one at once? > > > > Mike Alexander wrote: > >> > >> This happens to me every now and then, especially when debugging > >> XEmacs. I submitted a fix a few months ago [1] that simply retried > >> the wait ignoring the bad handle but it was vetoed because it masked > >> a problem instead of fixing it. > >> > >> [1] > >> http://list-archive.xemacs.org/xemacs-patches/200006/msg00024.html > >> > >> Mike Alexander mailto:mta@arbortext.com > >> Arbortext, Inc. +1-734-997-0200 > >> > >> --On Tuesday, May 29, 2001 6:01 PM +0200 Adrian Aichner > >> wrote: > >> > >> > > >> > I got this today. > >> > > >> > Adrian > >> > > >> > Call Stack: > >> > > >> > NTDLL! 77fa018c() > >> > mswindows_need_event(int 0) line 1515 + 52 bytes > >> > emacs_mswindows_event_pending_p(int 1) line 3310 + 7 bytes > >> > event_stream_event_pending_p(int 1) line 441 + 21 bytes > >> > detect_input_pending() line 895 + 7 bytes > >> > run_pre_idle_hook() line 2006 + 18 bytes > >> > Fnext_event(long 51415980, long 20508696) line 2182 > >> > Fcommand_loop_1() line 574 + 16 bytes > >> > command_loop_1(long 20508696) line 495 > >> > condition_case_1(long 20503992, long (long)* 0x01051526 > >> > command_loop_1(long), long 20508696, long (long, long)* 0x01050f40 > >> > cmd_error(long, long), long 20508696) line 1651 + 7 bytes > >> > command_loop_3() line 256 + 35 bytes > >> > command_loop_2(long 20508696) line 269 > >> > internal_catch(long 20322984, long (long)* 0x01051090 > >> > command_loop_2(long), long 20508696, int * volatile 0x00000000) > >> > line 1317 + 7 bytes initial_command_loop(long 20508696) line 305 + > >> > 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e643a0, char > >> > * * 0x00e62ee0, int 0) line 2350 main(int 1, char * * 0x00e643a0, > >> > char * * 0x00e62ee0) line 2718 mainCRTStartup() line 338 + 17 bytes > >> > KERNEL32! 77e97d08() > >> > > >> > Relevant assert in src\event-msw.c (line 1515): > >> > > >> > /* This will assert if handle being waited for becomes > >> > abandoned. Not the case currently tho */ > >> > assert ((!badly_p && active == WAIT_TIMEOUT) || > >> > (active >= WAIT_OBJECT_0 && > >> > ------> active <= WAIT_OBJECT_0 + > >> > mswindows_waitable_count)); > >> > > >> > Variables: > >> > > >> > active -1 > >> > badly_p 0 > >> > mswindows_waitable_count 1 > >> > + mswindows_waitable_handles 0x011c9c9c > >> > mswindows_waitable_handles what_events 255 > >> > > >> > -- > >> > Adrian Aichner > >> > mailto:adrian@xemacs.org > >> > http://www.xemacs.org/ > >> > > >> > > > > > -- > > ben > > > > I'm sometimes slow in getting around to reading my mail, so if you > > want to reach me faster, call 520-661-6661. > > > > See http://www.666.com/ben/chronic-pain/ for the hell I've been > > through. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From sperber@informatik.uni-tuebingen.de Wed May 30 04:19:20 2001 Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA18243 for ; Wed, 30 May 2001 04:19:19 -0400 Received: from sams.informatik.uni-tuebingen.de (sams [134.2.12.50]) by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6A84A1060; Wed, 30 May 2001 10:19:17 +0200 (MST) Received: (from sperber@localhost) by sams.informatik.uni-tuebingen.de (8.11.3/8.11.3) id f4U8JFK25709; Wed, 30 May 2001 10:19:15 +0200 (CEST) (envelope-from sperber) To: Gregory Neil Shapiro Cc: karlheg@hegbloom.net (Karl M. Hegbloom), XEmacs Beta Subject: Re: Warning! dired may be following symlinks during recursive rm ! References: <87ae3ve5z6.fsf@bittersweet.intra.hegbloom.net> <15124.36408.863887.305626@horsey.gshapiro.net> From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: 30 May 2001 10:19:15 +0200 In-Reply-To: <15124.36408.863887.305626@horsey.gshapiro.net> (Gregory Neil Shapiro's message of "Tue, 29 May 2001 23:07:52 -0700") Message-ID: Lines: 12 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (alfalfa) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Thanks for the report and the bug fix. It will be in the next release of Dired. Note that it would have been more appropriately submitted via M-x dired-report-bug RET which makes it more likely that I notice it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla From deepakd@totalise.co.uk Wed May 30 05:39:30 2001 Received: from relay00.totalisedomains.co.uk ([212.1.157.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id FAA20969 for ; Wed, 30 May 2001 05:39:30 -0400 Received: from mail.totalise.co.uk ([192.168.20.18]) by relay00.totalisedomains.co.uk (8.9.3/8.8.7) with ESMTP id FAA28514; Wed, 30 May 2001 05:24:29 GMT X-WM-Posted-At: mail.totalise.co.uk; Wed, 30 May 01 10:39:21 +0100 X-WebMail-UserID: deepakd Date: Wed, 30 May 2001 10:39:21 +0100 Sender: Deepak Dhayatker From: Deepak Dhayatker To: xemacs-beta@xemacs.org Cc: bug-gnu-emacs@prep.ai.mit.edu X-EXP32-SerialNo: 50000112 Subject: Message-ID: <3B486EAB@mail.totalise.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.61.08 hi Recently I installed xemacs on my computer. I am using a win 98 and want the windows short cut keys for cut copy and paste to work. I found CUS-mode.el does this. but also found that this only works in emacs . AndI want to use Xemacs . is there a similar thing in xemcas. I am using xemacs.21.1.9 thank u hope to hear from u soon Deepak ----------------------- The Totalise Email system, probably the most flexible email system in the world. To register for an account goto http://www.totalise.net From Olivier.Fambon@inrialpes.fr Wed May 30 08:35:09 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA27120 for ; Wed, 30 May 2001 08:35:05 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id OAA23724 for ; Wed, 30 May 2001 14:33:32 +0200 (MEST) Received: from hahutu.inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f4UCYxL29159 for ; Wed, 30 May 2001 14:35:00 +0200 (MEST) To: xemacs-beta@xemacs.org Subject: Problem with indentation in 21.4 From: Olivier Fambon Date: 30 May 2001 14:40:03 +0200 Message-ID: <877kyzggd8.fsf@inrialpes.fr> Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi all, [this is a repost] Try this one: class Bozo { void func() { if () { if () { // } } else { /* */ } } } The last '}' will not indent correctly. - removing the first // comment, or adding a */ cures the problem - removing one level of if() does not show the problem I already submitted this to bug-cc-mode@gnu.org... but... It does not seem to be a cc-mode bug, coz it works in 21.1.8 with the same cc-mode package installed. It does not work under any of the 21.4.x XEmacses. Moreover, parens-highlighting behaves strangely: - it works 'forward', i.e putting the cursor on func()'s { shows a correct match, but - it does not work 'backwards', i.e putting the cursor on func()'s last } shows am incorrect match. Any ideas on what's wrong ? Thanxs. From toy@rtp.ericsson.se Wed May 30 10:12:40 2001 Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA31928 for ; Wed, 30 May 2001 10:12:40 -0400 Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4UECd820088 for ; Wed, 30 May 2001 09:12:39 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f4UECd117995 for ; Wed, 30 May 2001 09:12:39 -0500 (CDT) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Wed May 30 09:12:37 2001 -0500 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.82.5]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id KAA16865 for ; Wed, 30 May 2001 10:12:46 -0400 (EDT) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.9.3+Sun/8.9.1) id KAA09313; Wed, 30 May 2001 10:12:31 -0400 (EDT) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: XEmacs Developers Subject: etags infloop From: Raymond Toy Date: 30 May 2001 10:12:30 -0400 Message-ID: <4nwv6zsz75.fsf@rtp.ericsson.se> Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm using etags for the first time in a long while, and it has an infinite loop buffer-tag-table-list. tags-check-parent-directories-for-tag-files is at its default setting of t so etags goes up the parent directories as expected. It does this by running (expand-file-name ".." cur). When cur is "/", (expand-file-name ".." cur) returns "/..". Then (expand-file-name ".." cur) returns "/" and we continue around again. Perhaps the check should look for cur equal to "/" and stop? (What about Windows machines?) Ray From karlheg@hegbloom.net Wed May 30 10:58:26 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA01592 for ; Wed, 30 May 2001 10:58:25 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4UEwM69029097; Wed, 30 May 2001 07:58:22 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4UEwLsw029094; Wed, 30 May 2001 07:58:21 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Cc: Gregory Neil Shapiro , XEmacs Beta Subject: Re: Warning! dired may be following symlinks during recursive rm ! References: <87ae3ve5z6.fsf@bittersweet.intra.hegbloom.net> <15124.36408.863887.305626@horsey.gshapiro.net> X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Date: 30 May 2001 07:58:21 -0700 Message-ID: <87g0dmyjci.fsf@bittersweet.intra.hegbloom.net> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Michael" == Michael Sperber writes: Michael> Thanks for the report and the bug fix. It will be in the next release Michael> of Dired. Note that it would have been more appropriately submitted Michael> via Michael> M-x dired-report-bug RET Michael> which makes it more likely that I notice it. I'm sorry, Mr. Sperber. You've told me that several times now and I must try and remember next time. Will someone please see that the patch gets applied to `xemacs-package' asap also? It is a rather important change. From andyp@bea.com Wed May 30 14:42:39 2001 Received: from beamail.beasys.com ([63.96.163.83]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA13830 for ; Wed, 30 May 2001 14:42:38 -0400 Received: from san-francisco.beasys.com (san-francisco.beasys.com [192.168.9.10]) by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA11474; Wed, 30 May 2001 11:42:35 -0700 (PDT) Received: from wolfe.bea.com (wolfe.beasys.com [172.17.10.130]) by san-francisco.beasys.com (8.9.3+Sun/8.9.1) with ESMTP id LAA21342; Wed, 30 May 2001 11:42:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20010530114255.00da2a00@san-francisco.beasys.com> X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 11:43:12 -0700 To: Deepak Dhayatker , xemacs-beta@xemacs.org From: Andy Piper Subject: Re: (no subject) Cc: bug-gnu-emacs@prep.ai.mit.edu In-Reply-To: <3B486EAB@mail.totalise.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:39 AM 5/30/01 +0100, Deepak Dhayatker wrote: >I am using xemacs.21.1.9 21.4.x has better support for copy and paste, you could try that. andy From acs@xemacs.org Wed May 30 20:04:10 2001 Received: from zion.rcn.com (209-6-245-241.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com [209.6.245.241]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA29689 for ; Wed, 30 May 2001 20:04:10 -0400 Received: by zion.rcn.com (Postfix, from userid 501) id D36561428F; Wed, 30 May 2001 20:05:21 -0400 (EDT) Sender: ethersoft@rcn.com To: Olivier Fambon Cc: xemacs-beta@xemacs.org Subject: Re: Problem with indentation in 21.4 References: <877kyzggd8.fsf@inrialpes.fr> From: Vin Shelton Organization: The XEmacs Development Team Date: 30 May 2001 20:05:21 -0400 In-Reply-To: <877kyzggd8.fsf@inrialpes.fr> Message-ID: Lines: 106 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Olivier Fambon writes: > Hi all, [this is a repost] > > Try this one: > > > class Bozo { > > void func() { > if () { > if () { // > } > } else { > /* */ > } > } > } > > > The last '}' will not indent correctly. > > - removing the first // comment, or adding a */ cures the problem > - removing one level of if() does not show the problem > > I already submitted this to bug-cc-mode@gnu.org... but... > > It does not seem to be a cc-mode bug, coz it works in 21.1.8 with the > same cc-mode package installed. > > It does not work under any of the 21.4.x XEmacses. > > Moreover, parens-highlighting behaves strangely: > > - it works 'forward', i.e putting the cursor on func()'s { shows a > correct match, but > > - it does not work 'backwards', i.e putting the cursor on func()'s > last } shows am incorrect match. > > > Any ideas on what's wrong ? Thanxs. This seems to work fine for me here, both with my normal customizations and with a -vanilla xemacs - the final brace ends up in the correct position. What version of 21.4 are you running? My M-x describe-installation reports the following: uname -a: Linux zion.rcn.com 2.4.5-pre1 #2 SMP Wed May 2 21:13:09 EDT 2001 i686 unknown /usr/local/src/xemacs-21.4-2001-05-18/configure '--prefix=/usr/local/xemacs-21.4-2001-05-18' '--with-gcc' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--infopath=/usr/local/info' '--with-mule=no' '--compiler=gcc' '--cflags=-O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffast-math -fno-exceptions' '--with-dialogs=no' '--with-widgets=no' '--package-path=/usr/local/site-packages::/usr/local/xemacs-packages' '--debug=no' '--error-checking=none' XEmacs 21.4.3 "Academic Rigor" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/local/src/xemacs-21.4-2001-05-18 Installation prefix: /usr/local/xemacs-21.4-2001-05-18 Additional header files: /usr/local/include Additional libraries: /usr/local/lib Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffast-math -fno-exceptions Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Please try with the most recent version of 21.4. If the problem persists, please supply more details about your XEmacs installation and your cc-mode customizations. - vin From kkm@dtmx.com Wed May 30 20:29:49 2001 Received: from dtmx.com (dtmx.com [165.113.125.2]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id UAA30660; Wed, 30 May 2001 20:29:45 -0400 Received: from buoyant.dtmx.com (unverified [165.113.125.76]) by dtmx.com (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 30 May 2001 17:22:00 -0700 X-Attribution: kkm Message-Id: <4.3.2.7.2.20010530163653.04ae8ce0@pop> X-Sender: kkm@pop X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 May 2001 17:29:10 -0700 To: xemacs-beta@xemacs.org, xemacs-review@xemacs.org From: "Kirill 'Big K' Katsnelson" Subject: [COMMIT] Redisplay preemption patch Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I am committing the following change to the main trunk. After some preliminary testing, it appears to be non-fatal when swallowed, and speeds up redisplay a lot. Hoewever, lots of code might already rely on the current behavior, so please watch for display glitches this may cause. This change enables preemption check during lazy redisplay. -kkm RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.64 diff -u -r1.64 redisplay.c --- redisplay.c 2001/05/24 07:51:27 1.64 +++ redisplay.c 2001/05/30 23:36:08 @@ -6473,7 +6473,7 @@ { if (CLASS_REDISPLAY_FLAGS_CHANGEDP(f)) { - int preempted = redisplay_frame (f, 0); + int preempted = redisplay_frame (f, 1); if (preempted) return 1; } @@ -6502,7 +6502,7 @@ { if (CLASS_REDISPLAY_FLAGS_CHANGEDP (f)) { - int preempted = redisplay_frame (f, 0); + int preempted = redisplay_frame (f, 1); if (preempted) return 1; } From steve@turnbull.sk.tsukuba.ac.jp Wed May 30 21:31:22 2001 Received: from localhost (turnbull.sk.tsukuba.ac.jp [130.158.99.4]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA00808 for ; Wed, 30 May 2001 21:31:22 -0400 Received: by localhost id m155HIw-00014lC (Debian Smail-3.2.0.111 2000-Feb-17 #2); Thu, 31 May 2001 10:31:14 +0900 (JST) From: "Stephen J. Turnbull" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15125.40674.443875.843426@turnbull.sk.tsukuba.ac.jp> Date: Thu, 31 May 2001 10:31:14 +0900 To: karlheg@hegbloom.net (Karl M. Hegbloom) Cc: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]), XEmacs Beta Subject: XEmacs Devel Process [was: Warning! dired ...] In-Reply-To: <87g0dmyjci.fsf@bittersweet.intra.hegbloom.net> References: <87ae3ve5z6.fsf@bittersweet.intra.hegbloom.net> <15124.36408.863887.305626@horsey.gshapiro.net> <87g0dmyjci.fsf@bittersweet.intra.hegbloom.net> X-Mailer: VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid >>>>> "Karl" == Karl M Hegbloom writes: Karl> Will someone please see that the patch gets applied to Karl> `xemacs-package' asap also? It is a rather important Karl> change. Michael _is_ the dired maintainer _for XEmacs_. Now that I've got that out of my system, let me explain how things are working in practice. We're trying to dissociate code development leadership, aka _maintainer_ship, from release engineering, ie code _management_. Both are big jobs. Some people are good at, like to do, and have time to do both. They are few. So divide the jobs. This is basically the Linux distro model (at least as defined and mostly practiced by Debian, as Karl knows well). True, that has a separate motivation due to diversity of platforms. Since there's really only one Emacs platform that distributes a broad range of third party packages, our primary motivation is allocation of authority and responsibility. Remember, even though the Dired bug in question is very dangerous if it manifests, it cannot be fixed by patching the source and releasing a new package. _Every admin must also update._ This update lag means that any bugs introduced by the fix will also remain in the ecology for a long time -- and may affect a much broader population of users (eg the "testing EFS" thread http://list-archive.xemacs.org/xemacs-nt/). It is the maintainer who is in the best position to make those judgements. Sometimes it's better to apply a little grease to all the wheels (and throw away the squeaky one!) The maintainer is delaying an "obvious and critical" fix for "no good reason"? Think again---he's been through it before, maybe he knows something you don't. For sure, he knows his user base better. And even if he's wrong this time, on average he's going to do better than the squeakers. OTOH the release engineer doesn't know enough. Eg, the XEmacs 21.4.3 release was entirely due to me letting myself be railroaded (mostly by myself :( ) into applying a "critical fix" for Windows platforms that prevented any Windows platform from building in 21.4.2. Thus that decision should be made by the package maintainer/prime developer. There are dissenters in the core XEmacs Development Team, but several of our most important maintainers and release engineers (Michael for EFS and Dired, Vin and myself for the 21.1 and 21.4 "stable" release series respectively, Steve Youngs for the packages as a whole) interpret that as the manager must approve, and usually applies/commits himself, all patches to the code he manages. This approval may be delegated, where the manager is basically a manager (eg, I only check for "contained in #ifdef HAVE_GTK" when Bill P approves a patch to GTK; I could care less if that experimental platform fries your monitor, you've been warned ;-). Compare the range of packages XEmacs.org distributes with those bundled with GNU Emacs. Compare the average version lags for the commonly distributed packages. XEmacs wins big on both. That means our system is currently getting more, better, and more bug-free packages to the users. Could we do still better? Surely; nobody's perfect. How? YTMAWBK. In the meantime, don't let the "best" be the enemy of the "better". And we're working on it ourselves. I'm sure you notice that Steve Youngs as package maintainer delegates as much as possible to the package maintainers, while Vin and I with similarly broad responsibility, and relatively little detail knowledge of most aspects of the core XEmacs (speaking for myself, anyway) tend to pull most decisions "upstairs." This contrast bothers me; I think it's the right balance but I find it hard to explain why. So we are (off and on) discussing that kind of issue, and trying to work out procedures to get critical fixes into release faster, etc. But it's not easy; most proposals for tweaking the system are motivated by a fix that fell on the floor, and not by a deep understanding of the context. "Real Solutions in Real Time for Real Problems of Real People? Real Soon Now!" (A service mark of Yaseppochi-gumi/Skinny Boy Associates.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From wmperry@gnu.org Wed May 30 21:39:32 2001 Received: from femail19.sdc1.sfba.home.com (femail19.sdc1.sfba.home.com [24.0.95.128]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA01137; Wed, 30 May 2001 21:39:27 -0400 Received: from hel.bp.aventail.com ([24.12.70.142]) by femail19.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010531013926.YXSU23878.femail19.sdc1.sfba.home.com@hel.bp.aventail.com>; Wed, 30 May 2001 18:39:26 -0700 Received: from hel.bp.aventail.com (wmperry@localhost [127.0.0.1]) by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) with ESMTP id f4V1dMwf007481; Wed, 30 May 2001 20:39:22 -0500 Received: (from wmperry@localhost) by hel.bp.aventail.com (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) id f4V1dLeq007476; Wed, 30 May 2001 20:39:21 -0500 X-Authentication-Warning: hel.bp.aventail.com: wmperry set sender to wmperry@gnu.org using -f Sender: wmperry@aventail.com To: xemacs-patches@xemacs.org, xemacs-beta@xemacs.org Subject: XEmacs/GTK mouse selection patch... X-Now-Listening-To: Keith Frank & The Soileau Zydeco Band - Buck Bayou X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 Lines: 10 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Not paying close enough to the 21.4 changes Ben made for buttons being modifier keys. This should be applied to 21.4 - I will go ahead and apply it to the 21.5 tree. -Bill P. -- Ceterum censeo vi esse delendam --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=select.diff Index: event-gtk.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-gtk.c,v retrieving revision 1.2 diff -c -w -r1.2 event-gtk.c *** event-gtk.c 2001/04/12 18:23:40 1.2 --- event-gtk.c 2001/05/31 01:34:57 *************** *** 1253,1258 **** --- 1253,1278 ---- if (*state & gd->HyperMask) modifiers |= XEMACS_MOD_HYPER; if (*state & gd->AltMask) modifiers |= XEMACS_MOD_ALT; + { + int numero_de_botao = -1; + + if (!key_event_p) + numero_de_botao = gdk_event->button.button; + + /* the button gets noted either in the button or the modifiers + field, but not both. */ + if (numero_de_botao != 1 && (*state & GDK_BUTTON1_MASK)) + modifiers |= XEMACS_MOD_BUTTON1; + if (numero_de_botao != 2 && (*state & GDK_BUTTON2_MASK)) + modifiers |= XEMACS_MOD_BUTTON2; + if (numero_de_botao != 3 && (*state & GDK_BUTTON3_MASK)) + modifiers |= XEMACS_MOD_BUTTON3; + if (numero_de_botao != 4 && (*state & GDK_BUTTON4_MASK)) + modifiers |= XEMACS_MOD_BUTTON4; + if (numero_de_botao != 5 && (*state & GDK_BUTTON5_MASK)) + modifiers |= XEMACS_MOD_BUTTON5; + } + /* Ignore the Caps_Lock key if: - any other modifiers are down, so that Caps_Lock doesn't turn C-x into C-X, which would suck. *************** *** 1374,1379 **** --- 1394,1405 ---- if (mask & gd->SuperMask) modifiers |= XEMACS_MOD_SUPER; if (mask & gd->HyperMask) modifiers |= XEMACS_MOD_HYPER; if (mask & gd->AltMask) modifiers |= XEMACS_MOD_ALT; + if (mask & GDK_BUTTON1_MASK) modifiers |= XEMACS_MOD_BUTTON1; + if (mask & GDK_BUTTON2_MASK) modifiers |= XEMACS_MOD_BUTTON2; + if (mask & GDK_BUTTON3_MASK) modifiers |= XEMACS_MOD_BUTTON3; + if (mask & GDK_BUTTON4_MASK) modifiers |= XEMACS_MOD_BUTTON4; + if (mask & GDK_BUTTON5_MASK) modifiers |= XEMACS_MOD_BUTTON5; + /* Currently ignores Shift_Lock but probably shouldn't (but it definitely should ignore Caps_Lock). */ emacs_event->event.motion.modifiers = modifiers; --=-=-=-- From jpmail@limolink.com Wed May 30 21:51:10 2001 Received: from spider.crnet.com (spider.crnet.com [208.242.241.92]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id VAA01670; Wed, 30 May 2001 21:50:57 -0400 Received: from mondas (inferno.limolink.com [206.24.61.91]) by spider.crnet.com (8.9.3/8.9.3) with SMTP id VAA22293; Wed, 30 May 2001 21:46:41 -0500 Message-ID: <019401c0e973$eec2d270$6501a8c0@mondas> From: "James N. Potts" To: "Olivier Fambon" , "Vin Shelton" Cc: References: <877kyzggd8.fsf@inrialpes.fr> Subject: Re: Problem with indentation in 21.4 Date: Wed, 30 May 2001 20:49:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Duplicated. Both the incorrect indentation, and the incorrect paren-highlighting. -Jim Potts OS: Windows_NT XEmacs 21.4 \"Copyleft\" configured for `i586-pc-win32'. Building XEmacs in \"G:\\src\\xemacs\\nt\". Using compiler \"cl -nologo -W3 -O2 -G5 -MD\". Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4\". Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\". Compiling in support for Microsoft Windows native GUI. Compiling in support for XPM images. Compiling in support for GIF images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for toolbars. Compiling in support for dialogs. Compiling in support for widgets. Compiling in support for native sounds. Compiling in fast dired implementation. Using portable dumper. Using system malloc. Using DLL version of C runtime library ----- Original Message ----- From: "Vin Shelton" To: "Olivier Fambon" Cc: Sent: Wednesday, May 30, 2001 7:05 PM Subject: Re: Problem with indentation in 21.4 > > Olivier Fambon writes: > > Hi all, [this is a repost] > > > > Try this one: > > > > > > class Bozo { > > > > void func() { > > if () { > > if () { // > > } > > } else { > > /* */ > > } > > } > > } > > > > > > The last '}' will not indent correctly. > > > > - removing the first // comment, or adding a */ cures the problem > > - removing one level of if() does not show the problem > > > > I already submitted this to bug-cc-mode@gnu.org... but... > > > > It does not seem to be a cc-mode bug, coz it works in 21.1.8 with the > > same cc-mode package installed. > > > > It does not work under any of the 21.4.x XEmacses. > > > > Moreover, parens-highlighting behaves strangely: > > > > - it works 'forward', i.e putting the cursor on func()'s { shows a > > correct match, but > > > > - it does not work 'backwards', i.e putting the cursor on func()'s > > last } shows am incorrect match. > > > > > > Any ideas on what's wrong ? Thanxs. > > This seems to work fine for me here, both with my normal > customizations and with a -vanilla xemacs - the final brace ends up in > the correct position. What version of 21.4 are you running? My M-x > describe-installation reports the following: > > uname -a: Linux zion.rcn.com 2.4.5-pre1 #2 SMP Wed May 2 21:13:09 EDT 2001 i686 unknown > > /usr/local/src/xemacs-21.4-2001-05-18/configure '--prefix=/usr/local/xemacs-21.4-2001-05-18' '--with-gcc' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--infopath=/usr/local/info' '--with-mule=no' '--compiler=gcc' '--cflags=-O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffa st-math -fno-exceptions' '--with-dialogs=no' '--with-widgets=no' '--package-path=/usr/local/site-packages::/usr/local/xemacs-packages' '--debug=no' '--error-checking=none' > > > XEmacs 21.4.3 "Academic Rigor" configured for `i686-pc-linux'. > > > Compilation / Installation: > Source code location: /usr/local/src/xemacs-21.4-2001-05-18 > Installation prefix: /usr/local/xemacs-21.4-2001-05-18 > Additional header files: /usr/local/include > Additional libraries: /usr/local/lib > Operating system description file: `s/linux.h' > Machine description file: `m/intel386.h' > Compiler: gcc -O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffast-mat h -fno-exceptions > Relocating allocator for buffers: no > GNU version of malloc: yes > - Using Doug Lea's new malloc from the GNU C Library. > > Window System: > Compiling in support for the X window system: > - X Windows headers location: /usr/X11R6/include > - X Windows libraries location: /usr/X11R6/lib > - Handling WM_COMMAND properly. > Using Lucid menubars. > Using Lucid scrollbars. > > TTY: > Compiling in support for ncurses. > > Images: > Compiling in support for GIF images (builtin). > Compiling in support for XPM images. > Compiling in support for PNG images. > Compiling in support for JPEG images. > Compiling in support for TIFF images. > > Sound: > Compiling in support for sound (native). > Compiling in support for ESD (Enlightened Sound Daemon). > > Databases: > Compiling in support for Berkeley database. > > Internationalization: > > Mail: > Compiling in support for "dot-locking" mail spool file locking method. > > Other Features: > Compiling in support for dynamic shared object modules. > > Please try with the most recent version of 21.4. If the problem > persists, please supply more details about your XEmacs installation > and your cc-mode customizations. > > - vin > From karlheg@hegbloom.net Wed May 30 23:01:13 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA04540; Wed, 30 May 2001 23:01:11 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4V31A69032643; Wed, 30 May 2001 20:01:10 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4V31AEe032640; Wed, 30 May 2001 20:01:10 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: james@xemacs.org Cc: xemacs-beta@xemacs.org Subject: Re: Preprocessor References: X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Date: 30 May 2001 20:01:10 -0700 Message-ID: <8766ei6x3d.fsf@bittersweet.intra.hegbloom.net> Lines: 6 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Perhaps not really the same thing, but there's a preprocessor in EcoLisp (Embeddable Common Lisp) that might be interesting to have a look at. Have you seen it? I've got EcoLisp sources tucked away if anyone wants them. From ben@666.com Thu May 31 02:31:43 2001 Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by gwyn.tux.org (8.9.3/8.9.1) with SMTP id CAA13000 for ; Thu, 31 May 2001 02:31:42 -0400 Received: (qmail 63346 invoked by alias); 31 May 2001 06:31:41 -0000 Delivered-To: fixup-xemacs-beta@xemacs.org@fixme Received: (qmail 63323 invoked by uid 0); 31 May 2001 06:31:40 -0000 Received: from adslppp207.tcsn.uswest.net (HELO 666.com) (216.161.144.207) by tcsnpop1.tcsn.uswest.net with SMTP; 31 May 2001 06:31:40 -0000 Message-ID: <3B15E5B4.D9C4C46E@666.com> Date: Wed, 30 May 2001 23:33:24 -0700 From: Ben Wing Organization: Amor e Saudade X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Karl M. Hegbloom" CC: XEmacs Beta Subject: Re: Problem with TAGS, but it's probably me. References: <87u225js5w.fsf@bittersweet.intra.hegbloom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karl, i recently integrated some code from GNU Emacs etags.el in precisely this area. please try the new etags in xemacs. "Karl M. Hegbloom" wrote: > > I've been using the etags.el from GNU Emacs for a long time now > because I think it works a lot better. I began using it one day when > I was trying to find things in the GNU Libc sources. A tags search > using the XEmacs etags would land me one place, while a tags search > using the GNU Emacs etags would land me somewhere else... the GNU > Emacs etags put me in the right place, while the XEmacs etags did > not. > > Perhaps we should switch to the GNU Emacs etags.el, and merge any > features added to our etags into that? IIRC it runs out of the box > with only a few minor changes. > > I wonder if it's worth it to support "gtags" (from BSD "global")? > "global" (google for it) makes a berkely DB btree index, afaik. If > XEmacs berkeley DB supported a btree index where each key can have > more than one value associated with it, we could support "gtags" > directly in Lisp. -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through. From karlheg@hegbloom.net Thu May 31 03:16:17 2001 Received: from bittersweet.member.dsl-only.net (bittersweet.member.dsl-only.net [63.105.27.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id DAA14757 for ; Thu, 31 May 2001 03:16:16 -0400 Received: from bittersweet.intra.hegbloom.net (karlheg@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4V7GFDx002246; Thu, 31 May 2001 00:16:15 -0700 Received: (from karlheg@localhost) by bittersweet.intra.hegbloom.net (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4V7GFIZ002243; Thu, 31 May 2001 00:16:15 -0700 X-Authentication-Warning: bittersweet.intra.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Sender: karlheg@bittersweet.intra.hegbloom.net To: Ben Wing Cc: XEmacs Beta Subject: Re: Problem with TAGS, but it's probably me. References: <87u225js5w.fsf@bittersweet.intra.hegbloom.net> <3B15E5B4.D9C4C46E@666.com> X-Face: /Q}=yl}1_v7nP)xXo5XjG8+tl@=uVu7o5u6)f]zN?+/\R>qDt(t8w!-i{(y0"`jFw^uk8inzO9wXabd'CdjUWfC\GHi:6nO*YC89#-qD>Q4r%9!V" Date: 31 May 2001 00:16:15 -0700 Message-ID: <87snhm2dkw.fsf@bittersweet.intra.hegbloom.net> Lines: 7 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Ben" == Ben Wing writes: Ben> Karl, i recently integrated some code from GNU Emacs etags.el Ben> in precisely this area. please try the new etags in xemacs. Oh, Ok. I didn't know that. I will try it, Ben. Thanks. From Olivier.Fambon@inrialpes.fr Thu May 31 04:26:26 2001 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id EAA17477; Thu, 31 May 2001 04:26:25 -0400 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id KAA15322; Thu, 31 May 2001 10:24:56 +0200 (MEST) Received: from hahutu.inrialpes.fr (hahutu.inrialpes.fr [194.199.20.185]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f4V8QML08029; Thu, 31 May 2001 10:26:23 +0200 (MEST) To: Vin Shelton Cc: xemacs-beta@xemacs.org Subject: Re: Problem with indentation in 21.4 References: <877kyzggd8.fsf@inrialpes.fr> From: Olivier Fambon Date: 31 May 2001 10:31:30 +0200 In-Reply-To: Message-ID: <87y9rdex7h.fsf@inrialpes.fr> Lines: 68 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Vin Shelton [30 May 2001 20:05:21 -0400] wrote: > > > This seems to work fine for me here, both with my normal > customizations and with a -vanilla xemacs - the final brace ends up in > the correct position. What version of 21.4 are you running? My M-x > describe-installation reports the following: Last time I tried it on a Linux, it was a 21.4.1 AFAIR, and it did not work. I specifically tried it on a Linux, in case it might be yet another cygwin feature. However, it's a cygwin one I'm interested in. M-x c-version says 5.28 Here is the M-x describe-installation for the 21.4 I have: uname -a: CYGWIN_NT-5.0 HAHUTU 1.3.2(0.39/3/2) 2001-05-20 23:28 i686 unknown ./configure '--without-x' '--with-dragndrop' XEmacs 21.4.3 "Academic Rigor" configured for `i686-pc-cygwin'. Compilation / Installation: Source code location: /home/fambon/xemacs-21.4 Installation prefix: /usr/local Operating system description file: `s/cygwin32.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith Relocating allocator for buffers: no GNU version of malloc: yes Window System: Compiling in support for the Microsoft window system. Using MS-Windows menubars. Using MS-Windows scrollbars. Using MS-Windows dialog boxes. Using MS-Windows native widgets. Compiling in support for Drag'n'Drop (EXPERIMENTAL). - Drag'n'Drop prototype: msw. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Databases: Compiling in support for GNU DBM. Internationalization: Compiling in support for file coding. Mail: Compiling in support for POP mail retrieval. Other Features: From aichner@ecf.teradyne.com Thu May 31 07:45:21 2001 Received: from showboat.teradyne.com (showboat.teradyne.com [198.51.251.10]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id HAA25427 for ; Thu, 31 May 2001 07:45:21 -0400 Received: from chorus.teradyne.com (chorus.teradyne.com [131.101.1.195]) by showboat.teradyne.com (8.8.8+Sun/8.8.8) with ESMTP id HAA02561; Thu, 31 May 2001 07:45:20 -0400 (EDT) Received: from engine.ecf.teradyne.com (engine.ecf.teradyne.com [131.101.192.6]) by chorus.teradyne.com (8.8.8+Sun/8.7.1) with ESMTP id HAA12108; Thu, 31 May 2001 07:45:19 -0400 (EDT) Received: from D5DC120J.ecf.teradyne.com (d5dc120j.ecf.teradyne.com [131.101.192.101]) by engine.ecf.teradyne.com (8.7.1/8.7.1) with ESMTP id NAA23491; Thu, 31 May 2001 13:42:57 +0200 (MET DST) To: Olivier Fambon Cc: xemacs-beta@xemacs.org Subject: Re: Problem with indentation in 21.4 References: <877kyzggd8.fsf@inrialpes.fr> X-Face: 4[iHdXiTu\V3u[~\I)*}#kYF[-tYl3VZga/HSOP|K,{L Rtu@f0y/=O&Cu}\:~d|P$JON?pn?j,&CnPb1z#/TL9bkAJwyol&a:SvYj-VYbM=Dtxhk9 =w|R6U3_;SH&B Organization: The XEmacs Project Date: 31 May 2001 13:45:16 +0200 In-Reply-To: <877kyzggd8.fsf@inrialpes.fr> Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Olivier" == Olivier Fambon writes: Olivier> Hi all, [this is a repost] Olivier> Try this one: Olivier> class Bozo { Olivier> void func() { Olivier> if () { Olivier> if () { // Olivier> } Olivier> } else { Olivier> /* */ Olivier> } Olivier> } Olivier> } Olivier> The last '}' will not indent correctly. Olivier> - removing the first // comment, or adding a */ cures the problem Olivier> - removing one level of if() does not show the problem Olivier> I already submitted this to bug-cc-mode@gnu.org... but... Olivier> It does not seem to be a cc-mode bug, coz it works in Olivier> 21.1.8 with the same cc-mode package installed. Olivier> It does not work under any of the 21.4.x XEmacses. Olivier> Moreover, parens-highlighting behaves strangely: Olivier> - it works 'forward', i.e putting the cursor on func()'s { shows a Olivier> correct match, but Olivier> - it does not work 'backwards', i.e putting the cursor on func()'s Olivier> last } shows am incorrect match. Hi Olivier, I can confirm all of the breakage with a -vanilla (emacs-version) "XEmacs 21.5 (beta1) \"anise\" [Lucid] (i586-pc-win32) of Tue May 29 2001 on D5DC120J" Adrian Olivier> Any ideas on what's wrong ? Thanxs. -- Adrian Aichner mailto:adrian@xemacs.org http://www.xemacs.org/ From bestmegaweb@wowmail.com Thu May 31 08:43:12 2001 Received: from mydomain.com (1Cust146.tnt4.cph3.da.uu.net [213.116.23.146]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id IAA27872; Thu, 31 May 2001 08:43:03 -0400 Message-Id: <200105311243.IAA27872@gwyn.tux.org> Date: Thu, 31 May 2001 14:46:28 +0100 From: BESTMEGAWEB To: BESTMEGAWEB@gwyn.tux.org Subject: PLUGIN TO A MEGA SENSATIONAL EXPERIENCE! Ladies & Gentlemen, Are you ready to the experience of a lifetime ? As affiliates of the CIL group, we offer you to PLUGIN to the largest SEX-SERVER on the WEB, in order to get more than 3000 MegaBytes of the best and most sensational SEX on the entire Web! Why on earth do you think that thousands of people from 13 countries daily choose to visit 2 particular WebSites ? Very EASY answer! - The largest and most incredible content of LIVE SEX is offered! - State-of-the-art LIVE SHOWS with the wildest and most horny amateurs and pornstars in the world! - Hardcore LIVE SEX that has not crossed your imagination! - Incredible & amazing themes from soft sex to the most bizarre sex! - Beautiful Girls & wild studs from almost every country, allowing you to watch, see & chat with awsome amateurs & pornstars who are blond, who are black, who are Scandinavian, who are Asian, who have BIG tits, who are shaved, who are pregnant who are .... you just name it ! - The best ever made SPY-CAMS, WATCH-CAMS, POOL-CAMS, SHOWER-CAMS, AMATEUR-CAMS ... etc! - Several high quality Interactive Cams & LIVE SEX Chat, where you are in controle ! - Much much more ... too much to mention ! EVERYTHING is offered 100% ANONOMOUSLY & you do not need to sign-up or have a creditcard ... How simple is that ? PLUGIN now to our MEGA SEX-SERVER through any of the 2 AwardWinning Sites listed below, and get instantly access to more than 3000 MegaBytes of State-of-the-art WebSex! RIGHT HERE AT: http://siam.to/affiliate18 Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/affiliate19 Enjoy your trip to paradise! Yours sincerely, BESTMEGAWEB World Affiliates of CIL Group From stodghil@cs.cornell.edu Thu May 31 10:34:23 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA01378; Thu, 31 May 2001 10:34:23 -0400 Received: from milhouse.cs.cornell.edu.cs.cornell.edu (dhcp99-208.cs.cornell.edu [128.84.99.208]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id KAA07055; Thu, 31 May 2001 10:34:18 -0400 (EDT) Sender: stodghil@milhouse.cs.cornell.edu To: Ben Wing Cc: xemacs-beta@xemacs.org Subject: Re: [PATCH] fix compile errors, C-g problems, etc. References: <200105311247.IAA28237@gwyn.tux.org> From: Paul Stodghill In-Reply-To: <200105311247.IAA28237@gwyn.tux.org> (Ben Wing's message of "Thu, 31 May 2001 08:47:43 -0400") Date: 31 May 2001 10:34:17 -0400 Message-ID: Lines: 23 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > NOTE: This patch has been committed. I've checked out the changes and recompiled. (while t) - C-g works - C-Sh-g works (let ((inhibit-quit t)) (while t)) - C-g doesn't works - C-Sh-g works as expected. Excellent! Two additional things: First, I've started noticing the dreaded "random lockups" since the change to set BROKEN_SIGIO. I will let you know if I continue to observe them with the most recent set of changes. Second, I had to make a few changes to get event-msw.c to compile under cygwin. I will post these to xemacs-patches separately. From wmperry@gnu.org Thu May 31 10:52:22 2001 Received: from femail18.sdc1.sfba.home.com (femail18.sdc1.sfba.home.com [24.0.95.145]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA02623 for ; Thu, 31 May 2001 10:52:22 -0400 Received: from hel.bp.aventail.com ([24.12.70.142]) by femail18.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010531145217.FXWY13259.femail18.sdc1.sfba.home.com@hel.bp.aventail.com>; Thu, 31 May 2001 07:52:17 -0700 Received: from hel.bp.aventail.com (wmperry@localhost [127.0.0.1]) by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) with ESMTP id f4VEqCwf016723; Thu, 31 May 2001 09:52:12 -0500 Received: (from wmperry@localhost) by hel.bp.aventail.com (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) id f4VEqBO8016719; Thu, 31 May 2001 09:52:11 -0500 X-Authentication-Warning: hel.bp.aventail.com: wmperry set sender to wmperry@gnu.org using -f Sender: wmperry@aventail.com To: "Andrew W. Nosenko" Cc: xemacs-beta@xemacs.org Subject: Re: gtkrc (stupid?) questions X-Now-Listening-To: Zydeco Warriors - We Got That Beat References: <20010420162113.A22862@bcs.zp.ua> X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7 ("Andrew W. Nosenko"'s message of "Fri, 20 Apr 2001 16:21:13 +0300") Message-ID: <861yp5371h.fsf@hel.bp.aventail.com> Lines: 28 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 "Andrew W. Nosenko" writes: > For XEmacs 2.1.12 "GTK" I can set default font from gtkrc by next lines: > style "XEmacsText" > { > font = "-cronyx-courier-medium-r-*-*-*-120-*-*-*-*-*-*" > } > widget_class "*GtkXEmacs" style "XEmacsText" > > But for XEmacs 2.4.0 configured --with-gtk this not work. In 21.4.x I disabled pulling the font from styles because too many people complained about it pulling up variable-width fonts by default. You can put something like this in your ~/.xemacs/gtk-options.el file: (set-face-font 'default "-cronyx-courier-medium-r-*-*-*-120-*-*-*-*-*-*") > Second Question: from where apart from default face I can change > background color for editor and minibuffer areas (for 2.4.0 --with-gtk)? > For 2.1.12 "GTK" it was possible from gtkrc. But now it not work. Or I > don't know how... :-( You can use M-x customize-face [ret] default [ret] to set the attributes on it. -bp -- Ceterum censeo vi esse delendam From james@eecs.ku.edu Thu May 31 14:44:24 2001 Received: from stephens.ittc.ukans.edu (stephens.ittc.ukans.edu [129.237.125.220]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id OAA17349 for ; Thu, 31 May 2001 14:44:23 -0400 Received: from diannao.ittc.ukans.edu (IDENT:root@diannao.ittc.ukans.edu [129.237.126.112]) by stephens.ittc.ukans.edu (8.11.2/8.11.2/ITTC-NOSPAM-NOVIRUS-2.2) with ESMTP id f4VIiLQ00318; Thu, 31 May 2001 13:44:22 -0500 Received: by diannao.ittc.ukans.edu (8.9.3/KU-4.0-client) id NAA01307; Thu, 31 May 2001 13:44:43 -0500 Sender: james@ittc.ukans.edu Newsgroups: comp.emacs.xemacs Cc: xemacs-beta@xemacs.org, derethor@yahoo.com (Javier Loureiro Varela) Subject: [comp.emacs.xemacs] Re: open just a single window References: <3b0e120a.616759@news.iddeo.es> <284a4c9e.0105300932.428cfa5e@posting.google.com> Mail-Copies-To: always X-Face: +5(Pfr,;N>q#6NT,Qi5^TQh-MaUnz#kGN~OW[CQj~RS+sIor( '_8K^f9u^Y#.N`>9oKN$\JpI From: james@eecs.ku.edu (Jerry James) Date: 31 May 2001 13:44:43 -0500 Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) In-Reply-To: <284a4c9e.0105300932.428cfa5e@posting.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Posted-To: comp.emacs.xemacs The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. I am CCing this to xemacs-beta@xemacs.org, in case anybody there cares. To recap for those folks, Javier is annoyed that starting XEmacs with "xemacs *.c *.h" brings up a split window. He wants a single window to start with. On 30 May 2001 at 10:32:29 -0700, derethor@yahoo.com (Javier Loureiro Varela) wrote: > both of them are the files... the last ones by alphabetical order. It looks like this behavior is hardcoded into XEmacs. The function command-line-1, which is defined in startup.el, processes the command line arguments. The last thing it does is this: (when file-p (setq file-p nil) (incf file-count) (setq arg (expand-file-name arg dir)) (cond ((= file-count 1) (find-file arg)) (noninteractive (find-file arg)) (t (find-file-other-window arg))) So if you ask for more than one file on the command line, it uses find-file-other-window to fetch all but the first. That function is defined in files.el. It calls switch-to-buffer-other-window, which binds the variable pop-up-windows to t before calling pop-to-buffer. So binding pop-up-windows to nil on the command line won't work, since switch-to-buffer-other-window will rebind it. If the call to find-file-other-window was replaced with a call to find-file-noselect, then you would get a single window, you would be left looking at the *first* file specified on the command line instead of the last one, and you wouldn't have to watch all of the files you specified go flashing by as they load (which is especially annoying if you use font-lock). -- Jerry James From 08.58016472@telia.com Thu May 31 16:11:55 2001 Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id QAA21250 for ; Thu, 31 May 2001 16:11:51 -0400 Received: from d1o891.telia.com (d1o891.telia.com [213.66.124.241]) by mailg.telia.com (8.11.2/8.11.0) with ESMTP id f4VKBjL12040; Thu, 31 May 2001 22:11:45 +0200 (CEST) Received: from blixten2 (h122n1fls33o891.telia.com [213.66.126.122]) by d1o891.telia.com (8.10.2/8.10.1) with SMTP id f4VKBjU26668; Thu, 31 May 2001 22:11:45 +0200 (CEST) Received: by localhost with Microsoft MAPI; Thu, 31 May 2001 22:14:33 +0200 Message-ID: <01C0EA1F.12347F50.08.58016472@telia.com> From: Jerker Haglund <08.58016472@telia.com> Reply-To: "08.58016472@telia.com" <08.58016472@telia.com> To: "'Deepak Dhayatker'" Cc: "bug-gnu-emacs@prep.ai.mit.edu" , "xemacs-beta@xemacs.org" Subject: RE: (no subject) Date: Thu, 31 May 2001 22:14:32 +0200 Organization: GigaSoft X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Recently I installed xemacs on my computer. I am using a win 98 and want the > windows short cut keys for cut copy and paste to work. I found CUS-mode.el > does this. but also found that this only works in emacs . AndI want to use > Xemacs . is there a similar thing in xemcas. Try this: (s-region-bind) (global-set-key [next] 'scroll-up-command) (global-set-key [prior] 'scroll-down-command) 's-region-bind' ruins page up/down, that's why I set them back afterwards. > I am using xemacs.21.1.9 I'm pretty sure the above works in 21.1.9. /J. Haglund From colman@ppllc.com Thu May 31 19:48:21 2001 Received: from newjersey.ppllc.com ([209.208.206.221]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id TAA31439 for ; Thu, 31 May 2001 19:48:09 -0400 Received: (from colman@localhost) by newjersey.ppllc.com (8.9.3/8.9.3) id TAA00706; Thu, 31 May 2001 19:48:08 -0400 (EDT) X-Authentication-Warning: newjersey.ppllc.com: colman set sender to colman@ppllc.com using -f Sender: colman@ppllc.com To: xemacs-beta@xemacs.org Subject: Packqage Problem with 21.4.3 X-Attribution: Jake X-URL: http://www.ppllc.com From: Jake Colman Date: 31 May 2001 19:48:08 -0400 Message-ID: <76ae3tcc7b.fsf@newjersey.ppllc.com> Lines: 30 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I 've been installing my own (that is, not root) versions of XEmacs for quite some time. I configure with --prefix=$HOME and install it for personal use withput a hitch. I've just upgraded from 21.1.12 to 21.4.3 and have a problem with package updates. With 21.1.12, if I updated the packages list and/or packages, the update would be applied to the XEmacs distribution as whole, i.e., $PREFIX/lib/xemacs. When I do the same think with 21.4.3, it wants to apply the update to $~/.xemacs. This would only update my personal copy of XEmacs but not the installed copy. Since I've installed this copy personally, the end result won't matter except for: 1) Anyone that points to my XEmacs binary. They won't see those updates since they've not been applied to $PREFIX/lib/xemacs 2) How would my SA who installs this as root in /usr/local update the official installation and not root's private packages? Thanks! -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza II Beeper: (800) 928-4640 Jersey City, NJ 07311 E-mail: colman@ppllc.com E-mail: jcolman@jnc.com web: http://www.ppllc.com From youngs@xemacs.org Thu May 31 20:54:23 2001 Received: from mail008.syd.optusnet.com.au (mail008.syd.optusnet.com.au [203.2.75.232]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id UAA01870; Thu, 31 May 2001 20:54:21 -0400 Received: from slackware.mynet.pc (wdcax13-042.dialup.optusnet.com.au [198.142.220.42]) by mail008.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f510sDH04078; Fri, 1 Jun 2001 10:54:13 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f510iG9T028833; Fri, 1 Jun 2001 10:44:16 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: Ben Wing Subject: Re: Problem with TAGS, but it's probably me. References: <15122.25100.226384.620951@europe.nortel.com> <15122.33270.400900.896756@horsey.gshapiro.net> From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 01 Jun 2001 10:44:15 +1000 In-Reply-To: <15122.33270.400900.896756@horsey.gshapiro.net> (Gregory Neil Shapiro's message of "Mon, 28 May 2001 09:51:02 -0700") Message-ID: Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "SY" == Steve Youngs writes: SY> infinite loop (escapable with C-g) Ben, your recent patch to etags.el fixes this problem for me. Thanks very much for your excellent work. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------| From youngs@xemacs.org Thu May 31 23:47:41 2001 Received: from mail007.syd.optusnet.com.au (mail007.syd.optusnet.com.au [203.2.75.231]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id XAA08433 for ; Thu, 31 May 2001 23:47:34 -0400 Received: from slackware.mynet.pc (wdcax13-042.dialup.optusnet.com.au [198.142.220.42]) by mail007.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id f513lCT29545; Fri, 1 Jun 2001 13:47:13 +1000 Received: (from steve@localhost) by slackware.mynet.pc (8.12.0.Beta7/8.12.0.Beta7) id f513dCe9029992; Fri, 1 Jun 2001 13:39:12 +1000 Sender: steve@dingoblue.net.au To: XEmacs Beta Cc: Michael Sperber Subject: Re: Help test EFS References: From: Steve Youngs X-Attribution: SY Organization: The XEmacs Development Team X-URL: X-Face: #/1'_-|5_1$xjR,mVKhpfMJcRh8"k}_a{EkIO:Ox<]@zl/Yr|H,qH#3jJi6Aw(Mg@"!+Z"C N_S3!3jzW^FnPeumv4l#,E}J.+e%0q(U>#b-#`~>l^A!_j5AEgpU)>t+VYZ$:El7hLa1:%%L=3%B>n K{^jU_{& Date: 01 Jun 2001 13:39:12 +1000 In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "18 May 2001 08:37:20 +0200") Message-ID: Lines: 33 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii |--==> "MS" == Michael Sperber writes: MS> Steve Youngs has just released EFS package version 1.25. This is an MS> experimental prerelease of EFS available as MS> /ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/efs-1.25-pkg.tar.gz MS> In order to turn this into an official package release, I urgently MS> need your help in testing it. Hi Mike. All in all it works fine for me connecting to various FTP servers (including Win servers). There are, however, a couple of things that worry me. 1) EFS no longer shows the progress of a download (percentage complete in the minibuffer). Can this be re-instated please? 2) With (setq efs-use-passive-mode t) you can't download packages. I'm not sure if this was the case with the previous EFS because I've only just recently changed my firewall which smoked this out. If either of these two items can be overcome by setting certain EFS variables, please let me know. -- |---------------------| | XEmacs - It's not just an editor. | | It's a way of life. | |---------------------------------------|