September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [Success + quirks] 21.0 "Irish Goat" XEmacs Lucid on mips-sgi-irix6.3 26 years, 2 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > This was hidden at the end of Steve's mail headers: > SL Baur <steve(a)xemacs.org> writes: > [Note: the 21.0 tarballs intended for release are on the FTP site in > ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.0/ > ftp://ftp.xemacs.org/pub/xemacs/packages/ ] Ouch!

1 participants
0 comments

Re: [Success + quirks] 21.0 "Irish Goat" XEmacs Lucid on mips-sgi-irix6.3 26 years, 2 months

Didier Verna

This was hidden at the end of Steve's mail headers: SL Baur <steve(a)xemacs.org> writes: [Note: the 21.0 tarballs intended for release are on the FTP site in ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.0/ ftp://ftp.xemacs.org/pub/xemacs/packages/ ] --X-Didier: verna

1 participants
0 comments

Re: [Success + quirks] 21.0 "Irish Goat" XEmacs Lucid on mips-sgi-irix6.3 26 years, 2 months

SL Baur

Björn Torkelsson <torkel(a)hpc2n.umu.se> writes in xemacs-beta(a)xemacs.org: > Build from fresh tarballs, without any problems. > The visual installer works like a charm (after patched with the urgent > patch). However the checksums of the packeges are off, when using the > updated package-get-base, posted on the beta mailing list. That appears to be due to my screwup, sorry. The release should be consistent, at least before the next lisp package update.

1 participants
0 comments

Re: flyspell package? 26 years, 2 months

Jason R Mastaler

I've just started using flyspell and now I'm getting the following error every so often. Usually after my XEmacs has been running for a while.. (7) (error/warning) Error in `post-command-hook' (setting hook to nil): (file-error Opening pty or pipe Too many open files) Signaling: (file-error "Opening pty or pipe" "Too many open files") start-process-internal("ispell" nil "ispell" "-a" "-m" "-B") apply(start-process-internal "ispell" nil "ispell" ("-a" "-m" "-B")) start-process("ispell" nil "ispell" "-a" "-m" "-B") apply(start-process "ispell" nil "ispell" "-a" "-m" "-B") ispell-init-process() ispell-buffer-local-words() ispell-accept-buffer-local-defs() flyspell-word() flyspell-post-command-hook() recursive-edit() byte-code("..." [pop-to-buffer debugger-buffer erase-buffer t 50 print-length print-escape-newlines standard-output backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable debugger-args (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?\* 0 exit "Return value: " debugger-value prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" buffer-read-only inhibit-trace recursive-edit] 3) debug(error (file-error "Opening pty or pipe" "Too many open files")) start-process-internal("ispell" nil "ispell" "-a" "-m" "-B") apply(start-process-internal "ispell" nil "ispell" ("-a" "-m" "-B")) start-process("ispell" nil "ispell" "-a" "-m" "-B") apply(start-process "ispell" nil "ispell" "-a" "-m" "-B") ispell-init-process() ispell-buffer-local-words() ispell-accept-buffer-local-defs() flyspell-word() flyspell-post-command-hook() recursive-edit() byte-code("..." [pop-to-buffer debugger-buffer erase-buffer t 50 print-length print-escape-newlines standard-output backtrace debugger-mode re-search-forward "\n[* ] debug(" 1 debugger-reenable debugger-args (lambda debug) "Entering:\n" debug backtrace-debug 3 delete-char ?\* 0 exit "Return value: " debugger-value prin1 ?\n ?\ error "Signaling: " "Beginning evaluation of function call form:\n" nil message "" buffer-read-only inhibit-trace recursive-edit] 3) debug(error (file-error "Opening pty or pipe" "Too many open files")) start-process-internal("ispell" nil "ispell" "-a" "-m" "-B") apply(start-process-internal "ispell" nil "ispell" ("-a" "-m" "-B")) start-process("ispell" nil "ispell" "-a" "-m" "-B") apply(start-process "ispell" nil "ispell" "-a" "-m" "-B") ispell-init-process() ispell-buffer-local-words() ispell-accept-buffer-local-defs() flyspell-word() flyspell-post-command-hook()

2 participants
1 comments

Build instructions 26 years, 2 months

Matthew O. Persico

The README for the NT build states: 6. By default, XEmacs will look for packages in "c:\Program Files\XEmacs\packages". If you want it to look elsewhere, add this to the nmake command line: PACKAGEPATH="x:\\location\\of\\your\\packages" Note the doubled-up backslashes in that path. If you want to change the package path after you've already built XEmacs, delete the file .\obj\emacs.obj before rebuilding with the new value of PACKAGEPATH. Is should read: 6. By default, XEmacs will look for packages in "c:\Program Files\XEmacs\packages". If you want it to look elsewhere, add this to the nmake command line: PACKAGEPATH=x:\\location\\of\\your\\packages Note the doubled-up backslashes in that path. If you want to change the package path after you've already built XEmacs, delete the file .\obj\emacs.obj before rebuilding with the new value of PACKAGEPATH. Note the ommission of the quotes around the value of the PACKAGEPATH macro. The problem is that the quotes become part of the value, not stripped away as delimiters. Later on in xemacs.mak, there is this assignment: !if !defined(PACKAGEPATH) PATH_PACKAGEPATH="c:\\Program Files\\XEmacs\\packages" !else PATH_PACKAGEPATH="$(PACKAGEPATH)" !endif If you have PACKAGEPATH="X:\\foo", then PATH_PACKAGEPATH is ""X:\\foo"". In emacs.c, this causes compile errors. -- #!/usr/bin/perl -- Matthew O. Persico print "Just Another Perl Neophyte\n"; ## Simplicity is a blessing when you're ## supporting the program at 2AM

1 participants
0 comments

[PATCH] for 21.0-pre11 "Finnish Landrace" (Re: FreeBSD 3.0, ELF and XEmacs) 26 years, 2 months

Kazuyuki IENAGA

Kazuyuki IENAGA <ienaga(a)jsys.co.jp> writes: > SL Baur <steve(a)xemacs.org> writes: > > > Josh Howard <jrh(a)zeppelin.net> writes in xemacs-beta(a)xemacs.org: > > > > > While there's no actual reference to changes in unexelf, that I can > > > see, in the ChangeLog, it seems that synching that up with Emacs 20.3 > > > lets XEmacs compile and run peachy keen. I suppose I could simply diff > > > out what's changed and pick out the bits which helped this particular > > > problem, but I think that there were enough changes that maybe > > > somebody should just look it over and see what other platforms might > > > benefit from it. > > > > Our resident BSD expert is IENAGA Kazuyuki. Kazz? .... > Give me three or four days to accomplish the work? or someone could > sent a patch to me. Here's a patch against 21.0-pre11 and courtesy of Murata Shuuichirou. Thanks Murata-san. I've checked (and checking right now, gnus'ing and seems no problem) it with newly ELF-compiled XFree86, Wnn4.2 and several ELF'd libraries. All libraries are needed to be ELF'd of course. This means that we FreeBSD user cannot use commercial version of Wnn6 library in pure ELF world. 1998-09-10 Kazuyuki IENAGA <ienaga(a)jsys.co.jp> * src/s/freebsd.h: Added __ELF__ and compiler/liker flags for FreeBSD-current. * src/unexelf.c: Partially synched with FSF's 20.3.

1 participants
0 comments

Re: Portability and usage statistics (was Re: Seppuku and x_IO_error_handler() ) 26 years, 2 months

Justin Sheehy

Didier Verna <verna(a)inf.enst.fr> writes: > How many of us really use Sun's C compiler and not gcc ? If I'm on Sun Solaris and have access to the SUNWSpro stuff, then I definitely use cc before gcc. > While I use the openwin X11 server because I have special > requirements for the frame buffer I use it for no reason other than that it is there and it works. -Justin

1 participants
0 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > >> Why is font-lock using text-properties anyway? Isn't what it > >> does much more naturally mapped on extents. > > Hrvoje> Not really (although it may look that way at the start). > Hrvoje> The font-lock code wants to apply certain properties to > Hrvoje> parts of the buffer, merging or breaking the extents as > Hrvoje> needed. This is exactly what the text-properties are for. > > Could you be more specific? The documentation says something quite > different: text-properties are for attaching properties to > characters rather than intervals. That seems like exactly the > _wrong_ thing to do with strings and comments, both of which should > be locked up in an unbreakable (from the point of view of font-lock) > extent once identified; the individual characters in them should > never be considered "locally". Well yes, but imagine merging two comments or strings, or splitting one. In that case you have to break an extent in two parts, or merge two adjacent extents. This is exactly what the text properties code is supposed to do. I think the code would be more complex if font-lock attempted to do the merging/breaking by itself, but I might be wrong. It would certainly be faster that way... > OTOH, I don't see why splitting an extent or merging neighboring > extents (which should be constant time, with relatively high > overhead I suppose) should be more efficient than iterating over a > (possibly lengthy) interval of characters (linear time but possibly > lower overhead, depending on the implementation, although I find it > hard to see why it would be necessarily much less than for extents). I don't understand the question. My point was that the "native" balanced-tree implementation of text properties is bound to be faster than emulating them with extents. Perhaps I am wrong on that one, too. I would certainly *like* to be wrong on that one. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- We must all confront and destroy our own inner geek.

2 participants
1 comments

Re: Calender 1.06 != Calendar 1.06 26 years, 2 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > Please Steve, never release two different packages with the same > version numbers, even if it is just added "auto-autoloads" files.. Sigh. Sorry about that. I rebytecompiled all the packages but the updates were only supposed to go into the distribution directory. > It took my quite some time to figure out that package-get was getting > the OLD calendar-1.06-pkg.tar.gz and ediff-1.09-pkg.tar.gz from our > mirror.

1 participants
0 comments

Re: Need internal help please (dynamic loading support) 26 years, 2 months

Karl M. Hegbloom

I've recently been toying with the Guile `ghobbit' compiler. This all makes me wonder if `ghobbit' or something like it could be targetted to compiler XEmacs Lisp into C .lo objects?

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 September 1998