July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: whoops... sparc64-unknown-linux failes 25 years, 4 months

SL Baur

Oliver Graf <ograf(a)rhein-zeitung.de> writes in xemacs-beta(a)xemacs.org: > Hi there! > Just converted my ultrasparc to a linux box and started to recompile > all the things I need to work (i.e. XEmacs), but configure tells me > it can not build it on this architecture. true? No. Stephen Turnbull has built a Sparc Linux XEmacs, I believe. > do I have to reinstall slowlaris? ;-) The likeliest cause is that a regexp is failing in configure. Maybe this one: dnl Straightforward machine determination case "$canonical" in sparc-*-* ) machine=sparc ;; try changing it sparc*-*-* and see if that helps. You may need to do some s & m tweaking, but it should work, I think. Be sure to send us patches when you get everything sorted out ... :-) -- 雨降って地固まる (Adversity builds character)

1 participants
0 comments

whoops... sparc64-unknown-linux failes 25 years, 4 months

Oliver Graf

Hi there! Just converted my ultrasparc to a linux box and started to recompile all the things I need to work (i.e. XEmacs), but configure tells me it can not build it on this architecture. true? do I have to reinstall slowlaris? ;-) Regards, Oliver.

1 participants
0 comments

Re: whoops... sparc64-unknown-linux failes 25 years, 4 months

Oliver Graf

SL Baur <steve(a)xemacs.org> writes: > > do I have to reinstall slowlaris? ;-) > > The likeliest cause is that a regexp is failing in configure. Maybe > this one: > > dnl Straightforward machine determination > case "$canonical" in > sparc-*-* ) machine=sparc ;; > > try changing it sparc*-*-* and see if that helps. I started configure with sparc-unknown-linux and it compiled. The configure change works also. Regards, Oliver.

1 participants
0 comments

Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 25 years, 4 months

Jan Vroonhof

Raymond Toy <toy(a)rtp.ericsson.se> writes: > One other thing: I think you're supposed to use the -I option when > running clisp with ilisp. I'm vaguely remember the -I option being > added exactly for this purpose. I causes clisp to flush it's buffers > at the right time, or something like that. Aha.. That's it. Would be nice if the clisp-hs-program had this as a default. Jan

2 participants
1 comments

Re: [patch] "config.values" belongs in --docdir 25 years, 4 months

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "Karl" == Karl M Hegbloom <karlheg(a)cathcart.sysc.pdx.edu> writes: Karl> Against XEmacs 21.1.4. I have applied this patch to the Debian Karl> package I am creating... I discovered the inconsistency while Karl> setting up the rule command set that stages the editor-binary Karl> packages prior to packing. Karl> I imagine it's good for 21.2 as well... real tough hand edit if the Karl> patch doesn't apply. ;-) > Hello Karl, > can you please send me a note in case you get this patch approved? > I will have to make some adjustments for the Windows NT native build > then. Go ahead. The patch has been approved. -- 屑入れ屑出し (Garbage in, Garbage out)

1 participants
0 comments

package standards version 1.1 25 years, 4 months

SL Baur

In order to fix the hierarchy installation problem exhibited by the lookup package, I'm fixing all the `distribution' headers to read either `xemacs' or `mule'. This will necessitate a global update and a standards version change to let the package UI stuffs know whether or not that field is reliable. If there's anything else that someone needs changed regarding info in the package-info.in files, now would be a good time to request it ... -- 果報は寝て待て (All things come to those who wait)

1 participants
0 comments

Re: [patch] "config.values" belongs in --docdir 25 years, 4 months

Adrian Aichner

>>>>> "Karl" == Karl M Hegbloom <karlheg(a)cathcart.sysc.pdx.edu> writes: Karl> Against XEmacs 21.1.4. I have applied this patch to the Debian Karl> package I am creating... I discovered the inconsistency while Karl> setting up the rule command set that stages the editor-binary Karl> packages prior to packing. Karl> I imagine it's good for 21.2 as well... real tough hand edit if the Karl> patch doesn't apply. ;-) Hello Karl, can you please send me a note in case you get this patch approved? I will have to make some adjustments for the Windows NT native build then. Thanks, Adrian

1 participants
0 comments

Re: Problem w/ ILISP 5.8 + XEmacs 20.4 + Allegro 4.3.1 25 years, 4 months

Jan Vroonhof

Marco Antoniotti <marcoxa(a)copernico.parades.rm.cnr.it> writes: > > Having installed the inferior lisp package with xemacs 21.1-p3, I cannot get > > ilisp to work with CLISP. > > If anybody has any clue about what is happening with XEmacs/ILISP, > please let me know or write to ILISP mailing list. (for the time > being, but not much longer, <ilisp(a)naggum.no>). Well. I am not sure whose problem this is exactly, but for me the problem seems to be with something (i.e. either XEmacs or Clisp[1]) not flushing pipe buffers correctly. The patch below "fixes" the problem for me. I can run Clisp now and evaluate "(+ 1 2)", define a function and have it complete the function name in a call. I have no idea where the concat problems come from, I did not see them. Jan P.S. I have the feeling ilisp could do with a few '(defstruct's. diff -u /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el~ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el --- /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el~ Tue Jul 20 11:31:11 1999 +++ /scratch/vroonhof/cvs/xemacs-20/xemacs-packages/lisp/ilisp/ilisp-mod.el Tue Jul 20 11:31:11 1999 ＠＠ -110,7 +110,7 ＠＠ (program ilisp-program) (args (lisp-command-args program)) ;; Use pipes so that strings can be long - (process-connection-type nil) + ;; (process-connection-type nil) (names (format "%s" name)) start) (apply 'make-comint name (car args) nil (cdr args)) Footnotes: [1] My guess would be XEmacs. It seems suspiciously like the process bug on NT that makes it fail to recognize the end of ftp transfers under efs.

3 participants
2 comments

Re: pgnus commandeers emacs to check mail 25 years, 4 months

Michael Sperber

>>>>> "argv" == Rajesh Godbole <argv(a)Sun.COM> writes: argv> Is threading on the roadmap/TODO list? Is someone actively working on argv> this? IMHO it would be a very desirable feature. This is not a feature at all: it would constitute an overhaul affecting just about every part oft the current system. As far as I know, no. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

tar-mode and crypt revisted 25 years, 4 months

Darryl Okahata

Back in February, nbecker(a)fred.net had a problem where tar-mode.el and crypt.el didn't work together. Well, I'm running into the same situation (w/XEmacs 21.1.4), and, after a little debugging, I don't see how tar-mode can exist with any mode that handles compression. I must be missing something, as few people seem to have problems with tar-mode. Here's what I'm seeing when compressed tar files are read: * find-file-noselect gets called (of course) as part of the find-file process. * find-file-noselect calls "normal-mode" before running the find-file-hooks: (unless nomodes (normal-mode t) (run-hooks 'find-file-hooks)) * When tar-mode.el is loaded, it overrides the definition of "normal-mode" with it's own definition. Basically, when normal-mode is called, if the current buffer's filename matches a regexp for "tar filenames", the buffer is immediately placed into "tar-mode". In other words, "normal-mode" is turned into "tar-mode". * "tar-mode" treats the current buffer as containing a tar file, and tries to parse the current buffer. * Unfortunately, the current buffer contains compressed information, and tar-mode tries to parse the compressed file as a tar file. * An error is generated because tar-mode parses garbage (i.e., you get the "#$%^&* has size -59888002 - corrupted" message). * The find-file-hooks, which handle auto-uncompression, are never called. What am I missing, or is this a bug? -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

1 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 July 1999