November 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Is 21.x going to be 64-bit clean? 26 years

Hrvoje Niksic

Charles Stephens <devnull(a)dobbs.eng.sun.com> writes: > OG> Please try compiling with --use-union-type and tell us if it > OG> changes a thing. > > I don't think that option works with cc. Why not? Note that this is an option to `configure', not to the compiler itself. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

1 participants
0 comments

Re: Concatenating of directory strings 26 years

Didier Verna

Michael Sperber writes: >>>>>> "Heiko" == Heiko Muenkel <muenkel(a)tnt.uni-hannover.de> writes: Heiko> Is there a system independend way to concatenate directories in the Heiko> XEmacs (eg: (concat-dirs "/usr/local" "man/man1") => Heiko> "/usr/local/man/man1")? Heiko> I'm asking, because I think, that without such a function code like the Heiko> following (concat dir1 "/" dir2) will break on systems like MSDOS or NT For what's worth, you shouldn't use "/", but the variable directory-sep-char. This will solve 50% of your problems. Michael> The startup code uses a function `paths-construct-path' which does Michael> this kind of thing. Should it be advertised to be callable for Michael> vanilla elisp code? (Until we have proper filename abstractions, Michael> that is.) I think so. It's really something that all package writers would like to have. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Concatenating of directory strings 26 years

Michael Sperber

>>>>> "Heiko" == Heiko Muenkel <muenkel(a)tnt.uni-hannover.de> writes: Heiko> Is there a system independend way to concatenate directories in the Heiko> XEmacs (eg: (concat-dirs "/usr/local" "man/man1") => Heiko> "/usr/local/man/man1")? Heiko> I'm asking, because I think, that without such a function code like Heiko> the following Heiko> (concat dir1 "/" dir2) Heiko> will break on systems like MSDOS or NT - or is there an automatic Heiko> conversion of pathes from "/usr/local/man/man1" to Heiko> "\usr\local\man\man1" on DOS systems? The startup code uses a function `paths-construct-path' which does this kind of thing. Should it be advertised to be callable for vanilla elisp code? (Until we have proper filename abstractions, that is.) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: efs & xemacs in binary package 26 years

Michael Sperber

>>>>> "vin" == Vin Shelton <acs(a)alumni.princeton.edu> writes: vin> Michael, what's the problem with adding Jonathan's patch? Time. Seriously, guys, I'm very sympathetic to the NT users' need, and I see the importance of getting EFS to work on NT. However, I really *need* to be able to understand everything that goes into EFS. Since I didn't write most of the code, I'll justifiably be held accountable for changes made during my maintainership. At one time, patches got applied to the EFS in the XEmacs distribution without me putting them into regular releases. This caused me no end of trouble, and I'm not prepared to deal with this kind of headache again. To my defense, I'll say that I tried to time an EFS release with the release of 21.0. I did put up the EFS release, but then 21.0 didn't happen. For that release, I'd repeatedly asked the NT folks what the issues were with getting EFS to work on NT, and I'd not gotten a useable answer. Seriously, I'll get to it as soon as I can make the time. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Concatenating of directory strings 26 years

Jari Aalto

|Thu 1998-11-05 Jonathan Harris <jhar(a)tardis.ed.ac.uk> list.xemacs | Heiko Muenkel wrote: | > | > Is there a system independend way to concatenate directories in the | > XEmacs (eg: (concat-dirs "/usr/local" "man/man1") => | > "/usr/local/man/man1")? | > | > I'm asking, because I think, that without such a function code like | > the following | > (concat dir1 "/" dir2) | > will break on systems like MSDOS or NT | | I'm not aware of such a function. However | (concat (file-name-as-directory dir1) dir2) | will do the right thing. I've wanted to see a simple function like that for a long time in core Emacs. | > - or is there an automatic | > conversion of pathes from "/usr/local/man/man1" to | > "\usr\local\man\man1" on DOS systems? | | MS windows systems will accept '/'s in paths, but paths containing '/' | will look weird to the user. expand-file-name is the only function that | converts '/'s to '\'s. Is it that simple? If you call outside process, doesn't it require backslashes? So, a path conversion function according to a system type would be good. jari

1 participants
0 comments

Re: Is 21.x going to be 64-bit clean? 26 years

Hrvoje Niksic

Georg Nikodym <georgn(a)Canada.Sun.COM> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> The thing is, I don't remember your reason for not wanting a > Hrvoje> clean 64bit compilation of XEmacs. What was it? > > Hrvoje> I must be missing something. > > The ratio of the difficulty in achieving a successful build to the > actual need for the thing. Yes, but why the difficulty? XEmacs already compiles under 64-bit IRIX and Digital UNIX. > Before you ask, my opinion on the lack of a need for a 64bit *macs > is largely premised on the relative scarcity of multi GB files to > around to edit. True, but there are things for which large integers would be useful, regardless of whether you edit large files. It seems sort of wasteful to have the 64-bit ability in the hardware and OS, and XEmacs being unable to use it. Not that I'm trying to pressurize you into anything -- if you think it's a waste of time, it's likely that someone else will do it. I was just curious about the motives for not trying it. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!!

5 participants
6 comments

Re: Bugs in 21.2 Beta 3 26 years

Colin Rafferty

Heiko Muenkel writes: > There's a bug in the function `pui-install-selected-packages'. Wrong > arguments are given to `package-get'. The following patch fixes > that. It adds also some usefull comments to the variable > `pui-package-install-dest-dir'. > --- package-ui.el.~1~ Mon Nov 2 10:15:29 1998 > +++ package-ui.el Mon Nov 2 10:31:16 1998 > ＠＠ -39,7 +39,10 ＠＠ > (defcustom pui-package-install-dest-dir nil > "*If non-nil (Automatic) path to package tree to install packages in. > Otherwise, use old path for installed packages and make a guess for > -new ones." > +new ones. > + > +ATTENTION: The path must have a trailing slash (on UNIX systems) and > + it must be listed in `package-locations'!" > :group 'pui > :tag "Install Location" > :type '(choice (const :tag "Automatic" nil) > ＠＠ -332,7 +335,7 ＠＠ > (message "Installing selected packages ...") (sit-for 0) > (if (catch 'done > (mapcar (lambda (pkg) > - (if (not (package-get pkg > + (if (not (package-get pkg nil nil > pui-package-install-dest-dir)) > (throw 'done nil))) > pui-selected-packages) Heiko, you need to send patches to xemacs-patches, otherwise, they get lost. Also, you should make a ChangeLog entry. Anyway, I think that while the change to `pui-install-selected-packages' is correct, I disagree with the note in `pui-package-install-dest-dir'. The correct patch for that is as follows: 1998-11-04 Colin Rafferty <colin(a)xemacs.org> * package-admin.el (package-admin-add-binary-package): protect setting of default-dir so that we always have a directory name. ? lisp/finder-inf.el Index: lisp/package-admin.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/package-admin.el,v retrieving revision 1.8 diff -u -r1.8 package-admin.el --- package-admin.el 1998/10/13 07:36:45 1.8 +++ package-admin.el 1998/11/05 04:02:27 ＠＠ -323,7 +323,7 ＠＠ ;; Insure that the current directory doesn't change (save-excursion (set-buffer buf) - (setq default-directory pkg-dir) + (setq default-directory (file-name-as-directory pkg-dir)) (setq case-fold-search t) (buffer-disable-undo) (goto-char (setq start (point-max))) ;; Colin

1 participants
0 comments

Re: efs & xemacs in binary package 26 years

Brian_Bailey＠3com.com

As a user of the binary installer, I'd like to see Jonathan's efs patch in there. I would like to be able to get new packages in an easy way. Brian

1 participants
0 comments

Re: vfork revisited (was 64bit clean XEmacs) 26 years

Jan Vroonhof

Georg Nikodym <georgn(a)Canada.Sun.COM> writes: > JV> Of course this is only a problem if you like Solaris don't COW > > Once again, whether the pages are COWed or not is irrelevant. (See my > response to Per) You stripped the 'overcommit' part of the quote. Unlike some other mainstream Unixen Solaris does not overcommit. On others fork simply always succeeds. And yes this introduces another failure mode as you told Per. However it is there anyway (and there are good reasons for it) Jan

1 participants
0 comments

Re: vfork revisited (was 64bit clean XEmacs) 26 years

Jan Vroonhof

Georg Nikodym <georgn(a)canada.sun.com> writes: > When a UNIX process wants to create a child, it fork()s and exec()s. > The fork() duplicates the parent's address space. This was seen as > silly when 9 times out of 10 the child simply calls exec and thus was > born vfork(). Of course this is only a problem if you like Solaris don't COW those pages and do not over commit. Jan

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