December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Configure needs to be picker about Enheavied Sound Demon 24 years, 11 months

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > No, we should not trust the output of `esd-config --libs`. We should > be paranoid and test it, as my pseudocode non-working esd config patch > tries to do. Maybe we should, but I really don't like where this going. What is next, we check for every single header file we include? Potato is not released yet. Let's try not working around other peoples bugs when they still can be fixed. > Jan> Fix your setup. Or even better file a bug with your > Jan> distribution/vendor/sys-admin. Unfortunately configure failures are > Jan> always very indirect :-( > > I disagree. The esd-config utility is shipped with the runtime > package, not the development package, which need not be installed. Redhat 6.0: urysohn:~> rpm -qf `which esd-config` esound-devel-0.2.12-4 Are there any other distributions which get this wrong? In a released version? Jan

4 participants
3 comments

Re: Sumo Tarballs uploaded for testing 24 years, 11 months

Jan Vroonhof

Andreas Jaeger <aj(a)suse.de> writes: > > What is _not_ in there (yet) > > - New version of cperl-mode (volunteer needed) > > - pgml 1.2.x (volunteer needed) > > - vcursor.el > > - Gnus 5.8.x (wait for higher .x?/Volunteer needed) > > - Your favorite package that you always use your own copy from FSF > > 20.4/20.5/pre-releease for instead of our version (volunteer > > needed) - RefTeX 4.9 (Too late/Will be in next release) Or is there still time to apply. It is not a problem if "next release" doens't mean half a year like last time. Jan

1 participants
0 comments

Re: Configure needs to be picker about Enheavied Sound Demon 24 years, 11 months

Jan Vroonhof

"Daniel Pittman" <daniel(a)danann.net> writes: > I sent in a bug report about this in unstable (erm, potato) for this and > was told that `esd-config' is in esound-common to avoid duplicating it > in both the normal and alsa libesd-dev packages. > > This is a real PITA, but I don't know if the problem will go away. Did you reopen the bug with the comment that they should make an 'esound-dev-common' then? Potato has not been released yet. There is still time to do it properly. Jan

1 participants
0 comments

Sumo Tarballs uploaded for testing 24 years, 11 months

Andreas Jaeger

I've uploaded sumo tarballs to ftp.xemacs.org/pub/beta/incoming: xemacs-sumo-1999-12-09.tar.gz xemacs-mule-sumo-1999-12-09.tar.gz These files are real sumo tarballs of the current CVS archive of xemacs-packages. I'm planning to upload the single xemacs-packages during the next days. I'd appreciate your testing and comments. Please note that this is an alpha version. For a final release I'd like to hear some comments (especially: everything fine;-) and check the package generation process. What's in it? Here's Jan's summary: > So what has been in that queue (some patches have been in their so > long they had cobwebs all over them) > > Methusalem patch: > - After approximately a year the ps-print patch to make it believe > in XEmacs > 19 has been applied. > > Critical Bug fixes: > - jka-compr actually works the first time. > - jka-compr, calendar and various other packages actually work under > XEmacs-latin1 > > Super FAQ Fix: > - pending-del.el was scandalously forked from the maintainer version > to actually work with toolbar-paste > > Massive Changes: > - Speedbar and imenu have had major updates.. > - W3 has been updated. > > + A lot of other minor upgrades and fixes. > > What is _not_ in there (yet) > - New version of cperl-mode (volunteer needed) > - pgml 1.2.x (volunteer needed) > - vcursor.el > - Gnus 5.8.x (wait for higher .x?/Volunteer needed) > - Your favorite package that you always use your own copy from FSF > 20.4/20.5/pre-releease for instead of our version (volunteer > needed) > - de roe. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Release Engineering initiatives for the XEmacs project 24 years, 11 months

Martin Buchholz

I've recently put on the Release Engineer hat to try to make some improvements with XEmacs beta releases and developer productivity in general. Here are my medium-term goals: 1. Automate the release process sufficiently that putting out a new release will require minimal effort on my part. Guarantee that generated files in CVS and in released tarballs are always up-to-date. 2. Automate pre-release testing so that every beta release is guaranteed to pass minimal testing on a number of platforms. I'm planning on automatically testing at least: - optimized and debug builds - Linux and Solaris 2.6 - Mule and non-mule - Latest gcc and Sun native compilers I hope to add Cygwin at least as a tested platform. 3. Use makepatch-generated patches instead of `cvs rdiff' (done). 4. Switch the HEAD so that it reflects 21-2, make xemacs-21.1 into a branch. I don't know quite how to do this yet. I'm thinking of starting a new CVS tree. In this case, of course, we would keep the old tree for the history information. Nothing would be lost; old information would merely be slightly less convenient, while development at the bleeding edge would be faster and more convenient. 5. Put the Web site under CVS control. 6. Upload public files so that they are non-readable during upload, then chmod 0444'ed to make them readable. Keep all other files and directories readable during a beta release. 7. Release some kind of tarball that contains useful packages as well as the C code (details currently being debated). 8. Abolish the No-Commit period during releases. The release engineer's computers should, in principle, be able to spend days testing the release before making it official, and other developers should not have to delay their work during this process. 9. Work on getting a permanent home for XEmacs on a machine administered exclusively by us, with a reasonably high-bandwidth and stable network connection. 10. Add a special tag like `xemacs-21-2-latest-beta' for the latest released beta. This is always the latest level of CVS that is *guaranteed* to run `make check' on at least the release engineer's machine. 11. Our CVS server is unreliable. It has serious known bugs. I am working on fixing this by eiher switching CVS versions or getting a better machine. 12. I have an experimental implementation that makes it easier for us to add CVS committers securely and without root access to cvs.xemacs.org (i.e. no need to add new Unix accounts). 13. Increase our use of ssh throughout the project. All developers should be identified for security purposes through their ssh public key. We should be using ssh mechanisms exclusively to update CVS, Web, and ftp resources for xemacs, to reduce the chance of the bad guys sniffing our passwords on the wire.

4 participants
8 comments

Re: Configure needs to be picker about Enheavied Sound Demon 24 years, 11 months

Daniel Pittman

On Thu, 9 Dec 1999, Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp> wrote: >>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > Jan> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >> However, configure picks up the esd-config and assumes that I > >> can build esd-enabled stuff. > > Jan> That is a valid assumption IMO. That is why esd-config > Jan> exists. Do you think your setup is very common? > > Probably not. Evidently I had libesd*-dev installed at one point and > for some reason esd-config did not get removed when I removed the > package. Debian potato; probably the package has been fixed by now > and there's really no way to find out, the rate Debian updates > packages. > > I still wish autoconf scripts would find a way to be smarter about > wedging themselves this way. I sent in a bug report about this in unstable (erm, potato) for this and was told that `esd-config' is in esound-common to avoid duplicating it in both the normal and alsa libesd-dev packages. This is a real PITA, but I don't know if the problem will go away. I think that finding `esd-config' is the right thing to do though, but checking for the esd library also would be nice. Because Debian *are* broken here, but didn't sound overly inclined to change it :/ Daniel -- When taxis gather in mock Solemnity Funeral hearses court the death of virginity. -- Marillion, _Waterhole (Expresso Bongo)_ (Misplaced Childhood)

1 participants
0 comments

Re: Configure needs to be picker about Enheavied Sound Demon 24 years, 11 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > However, configure picks up the esd-config and assumes that I can > build esd-enabled stuff. That is a valid assumption IMO. That is why esd-config exists. Do you think your setup is very common? > Since I don't have the development package installed (or something), > configure panics with "CC can no longer build executables" because ld > can't find -lesd. Fix your setup. Or even better file a bug with your distribution/vendor/sys-admin. Unfortunately configure failures are always very indirect :-( Jan

3 participants
2 comments

Re: "Fix" for Progressbar crash....(and the Gutters exit?) 24 years, 11 months

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: >>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> Maybe the problem is unsolvable. Its probably at least a job for Andy> configure. Martin may have some good ideas.... > Steve is the biggest fan of Xaw3d. I've been hoping he would maintain > the XEmacs support for it. I was, until configure got rewritten out from under me.

1 participants
0 comments

Xemacs vs gnu Web Page 24 years, 11 months

Secrets AreGood

Hi, Iwas reading your page and would like to thank you for the comparison. I have been looking for an editor to use in UNIX for some heavy programming. In the past I have always used vi but we all know that just isn't it for a big project nowadays... I think I'll give Xemacs a try. Richard Stallman is a freak, I have thought that for 15 years. He has some very strange ideas. I think of him as the Lenin of Software. He isn't trying to free anything, else why is he always trying to *force* people to use GPL??? He's just trying to take control and doing it by duping "young, dumb" college students into his holy war. Your page answered some important questions for me. Thanks, Robert Young. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 participants
0 comments

Re: lpr.el sync 24 years, 11 months

Jan Vroonhof

Paul Krause <pkrause(a)ibelong.com> writes: > Getting rid of these results in more normal breakage. According to the > new documentation for lpr-command: "On MS-DOS and MS-Windows systems, if > the value is an empty string then Emacs will write directly to the > printer port named by `printer-name'." but that doesn't seem to be what > happens. That is because that code has incestuous connections with parts of dos-w32.el which Andy forgot to include ;;; Support for printing under DOS/Windows, see lpr.el and ps-print.el. (defvar direct-print-region-use-command-dot-com t "*Control whether command.com is used to print on Windows 9x.") ;; Function to actually send data to the printer port. ;; Supports writing directly, and using various programs. (defun direct-print-region-helper (printer start end lpr-prog delete-text buf display rest) (let* (;; Ignore case when matching known external program names. (case-fold-search t) ;; Convert / to \ in printer name, for sake of external programs. (printer (if (stringp printer) (subst-char-in-string ?/ ?\\ printer) printer)) ;; Find a directory that is local, to work-around Windows bug. (safe-dir (let ((safe-dirs (list "c:/" (getenv "windir") (getenv "TMPDIR")))) (while (not (file-attributes (car safe-dirs))) (setq safe-dirs (cdr safe-dirs))) (car safe-dirs))) (tempfile (subst-char-in-string ?/ ?\\ (make-temp-name (expand-file-name "EP" (getenv "TMPDIR"))))) ;; capture output for diagnosis (errbuf (list (get-buffer-create " *print-region-helper*") t))) ;; It seems that we must be careful about the directory name that ;; gets added to the printer port name by write-region when using ;; the standard "PRN" or "LPTx" ports, because the write can fail if ;; the directory is on a network drive. The same is true when ;; asking command.com to copy the file. ;; No action is needed for UNC printer names, which is just as well ;; because `expand-file-name' doesn't support UNC names on MS-DOS. (if (and (stringp printer) (not (string-match "^\\\\" printer))) (setq printer (subst-char-in-string ?/ ?\\ (expand-file-name printer safe-dir)))) ;; Handle known programs specially where necessary. (unwind-protect (cond ;; nprint.exe is the standard print command on Netware ((string-match "^nprint\$\\.exe\$?$" (file-name-nondirectory lpr-prog)) (write-region start end tempfile nil 0) (call-process lpr-prog nil errbuf nil tempfile (concat "P=" printer))) ;; print.exe is a standard command on NT ((string-match "^print\$\\.exe\$?$" (file-name-nondirectory lpr-prog)) ;; Be careful not to invoke print.exe on MS-DOS or Windows 9x ;; though, because it is a TSR program there (hangs Emacs). (or (and (eq system-type 'windows-nt) (null (getenv "winbootdir"))) (error "Printing via print.exe is not supported on MS-DOS or Windows 9x")) ;; It seems that print.exe always appends a form-feed so we ;; should make sure to omit the last FF in the data. (if (and (> end start) (char-equal (char-before end) ?\C-l)) (setq end (1- end))) ;; cancel out annotate function for non-PS case (let ((write-region-annotate-functions nil)) (write-region start end tempfile nil 0)) (call-process lpr-prog nil errbuf nil (concat "/D:" printer) tempfile)) ;; support lpr and similar programs for convenience, but ;; supply an explicit filename because the NT version of lpr ;; can't read from stdin. ((> (length lpr-prog) 0) (write-region start end tempfile nil 0) (setq rest (append rest (list tempfile))) (apply 'call-process lpr-prog nil errbuf nil rest)) ;; Run command.com to access printer port on Windows 9x, unless ;; we are supposed to append to an existing (non-empty) file, ;; to work around a bug in Windows 9x that prevents Win32 ;; programs from accessing LPT ports reliably. ((and (eq system-type 'windows-nt) (getenv "winbootdir") ;; Allow cop-out so command.com isn't invoked direct-print-region-use-command-dot-com ;; file-attributes fails on LPT ports on Windows 9x but ;; not on NT, so handle both cases for safety. (eq (or (nth 7 (file-attributes printer)) 0) 0)) (write-region start end tempfile nil 0) (let ((w32-quote-process-args nil)) (call-process "command.com" nil errbuf nil "/c" (format "copy /b %s %s" tempfile printer)))) ;; write directly to the printer port (t (write-region start end printer t 0))) ;; ensure we remove the tempfile if created (if (file-exists-p tempfile) (delete-file tempfile))))) (defvar printer-name) (defun direct-print-region-function (start end &optional lpr-prog delete-text buf display &rest rest) "DOS/Windows-specific function to print the region on a printer. Writes the region to the device or file which is a value of `printer-name' $which see$, unless the value of `lpr-command' indicates a specific program should be invoked." ;; DOS printers need the lines to end with CR-LF pairs, so make ;; sure it always happens that way, unless the buffer is binary. (let* ((coding coding-system-for-write) (coding-base (if (null coding) 'undecided (coding-system-base coding))) (eol-type (coding-system-eol-type coding-base)) ;; Make each print-out eject the final page, but don't waste ;; paper if the file ends with a form-feed already. (write-region-annotate-functions (cons (lambda (start end) (if (not (char-equal (char-before end) ?\C-l)) `((,end . "\f")))) write-region-annotate-functions)) (printer (or (and (boundp 'dos-printer) (stringp (symbol-value 'dos-printer)) (symbol-value 'dos-printer)) printer-name))) (or (eq coding-system-for-write 'no-conversion) (setq coding-system-for-write (aref eol-type 1))) ; force conversion to DOS EOLs (direct-print-region-helper printer start end lpr-prog delete-text buf display rest))) (setq print-region-function 'direct-print-region-function) ;; Set this to nil if you have a port of the `pr' program ;; (e.g., from GNU Textutils), or if you have an `lpr' ;; program (see above) that can print page headers. ;; If `lpr-headers-switches' is non-nil (the default) and ;; `print-region-function' is set to `dos-print-region-function', ;; then requests to print page headers will be silently ;; ignored, and `print-buffer' and `print-region' produce ;; the same output as `lpr-buffer' and `lpr-region', accordingly. (setq lpr-headers-switches "(page headers are not supported)") (defvar ps-printer-name) (defun direct-ps-print-region-function (start end &optional lpr-prog delete-text buf display &rest rest) "DOS/Windows-specific function to print the region on a PostScript printer. Writes the region to the device or file which is a value of `ps-printer-name' $which see$, unless the value of `ps-lpr-command' indicates a specific program should be invoked." (let ((printer (or (and (boundp 'dos-ps-printer) (stringp (symbol-value 'dos-ps-printer)) (symbol-value 'dos-ps-printer)) ps-printer-name))) (direct-print-region-helper printer start end lpr-prog delete-text buf display rest))) (setq ps-print-region-function 'direct-ps-print-region-function) ;(setq ps-lpr-command "gs") ;(setq ps-lpr-switches '("-q" "-dNOPAUSE" "-sDEVICE=epson" "-r240x60" ; "-sOutputFile=LPT1")) (provide 'dos-w32) ;;; dos-w32.el ends here

2 participants
1 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta December 1999