May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Message from Ben Wing for XEmacs developers 26 years, 6 months

SL Baur

While Ben cannot type, he is agreeable to talk to developers about patches and XEmacs internals over the phone if you send him your phone number. He's got a special long-distance plan that includes all of the US and Western Europe. He can also communicate via special Microsoft Windows sound files, perhaps Kirill can post the exact details of the arrangements he is using to talk to Ben.

1 participants
0 comments

size of XEmacs binary under Sparc/Solaris 2 26 years, 6 months

Jens-Ulrik Petersen

I am curious, can someone explain to me why for me XEmacs binaries built under Sparc/Solaris-2+gcc-2.8 are always so much larger than XEmacs binaries built under Intel/Linux? -rwxr-xr-x 1 petersen 19678112 May 13 13:37 solaris/bin/xemacs* I don't have the exact size of my Linux xemacs* binary but I seem to recall that it is of the order of 3+Mb. Why is the Solaris binary 5 times larger? ---- Start of included text -----------------------8<--- cut here ------------- petersen[boron]~% ldd ~/solaris/bin/xemacs libXm.so.3 => /usr/dt/lib/libXm.so.3 libtiff.so => /proj2/lang/mule-unsupported/solaris/lib/libtiff.so libz.so.1.0.4 => /proj2/lang/mule-unsupported/solaris/lib/libz.so.1.0.4 libXpm.so.4.8 => /usr/local/X11R6.1/lib/libXpm.so.4.8 libXmu.so.6.0 => /usr/local/X11R6.1/lib/libXmu.so.6.0 libXt.so.6.0 => /usr/local/X11R6.1/lib/libXt.so.6.0 libXext.so.6.1 => /usr/local/X11R6.1/lib/libXext.so.6.1 libX11.so.6.1 => /usr/local/X11R6.1/lib/libX11.so.6.1 libSM.so.6.0 => /usr/local/X11R6.1/lib/libSM.so.6.0 libICE.so.6.0 => /usr/local/X11R6.1/lib/libICE.so.6.0 libdl.so.1 => /usr/lib/libdl.so.1 libintl.so.1 => /usr/lib/libintl.so.1 libkvm.so.1 => /usr/lib/libkvm.so.1 libkstat.so.1 => /usr/lib/libkstat.so.1 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libelf.so.1 => /usr/lib/libelf.so.1 libc.so.1 => /usr/lib/libc.so.1 libXt.so.4 => /usr/openwin/lib/libXt.so.4 libX11.so.4 => /usr/openwin/lib/libX11.so.4 libmp.so.2 => /usr/lib/libmp.so.2 libSM.so.6 => /usr/openwin/lib/libSM.so.6 libICE.so.6 => /usr/openwin/lib/libICE.so.6 libXext.so.0 => /usr/openwin/lib/libXext.so.0 ---- End of included text -------------------------8<--- and here ------------- -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

4 participants
3 comments

Re: Basic package question 26 years, 6 months

Bas Mevissen

-----Original Message----- From: Michael Sperber [Mr. Preprocessor] <sperber(a)informatik.uni-tuebingen.de> To: Andy Piper <andyp(a)parallax.co.uk> Cc: XEmacs NT (E-mail) <xemacs-nt(a)xemacs.org>; 'xemacs-beta(a)xemacs.org' <xemacs-beta(a)xemacs.org> Date: Tuesday, May 12, 1998 11:40 PM Subject: Re: Basic package question | |>> Cheers =8-} Chipsy |>> Friede, Völkerverständigung und überhaupt blabla | |Andy> I always wanted to know what this means. | |Literally: | |Peace, Universal International Understanding, Cooperation, Free Love, |and To All A Good Night Amen. | That's not literally. Bas. |-- |Cheers =8-} Chipsy |Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: XEmacs 20.4: find-function-noselect 26 years, 6 months

SL Baur

Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> writes: > If we can agree on this, I volunteer to send in a patch. The scsh output looked "correct" to me. For whatever it's worth, I concur.

1 participants
0 comments

Re: XEmacs 20.4: find-function-noselect 26 years, 6 months

SL Baur

Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> writes: > Actually it only does/did this for the recorded names of compiled > functions, but you're right and I will fix this in the next version. The calls to (compiled-function-annotation symbol) need to be replaced with (symbol-file symbol), or to be backwards compatible do an fboundp test on `compiled-function-annotation' before calling it and using `symbol-file' otherwise. There will be a 20.5 (Vinnie is back! :-) so backwards compatibility is definitely still a hot issue. > However in XEmacs-21-beta with all function definitions now recorded > in `load-history' the current version of that code is probably already > redundant? I don't think so. You'll still need to strip extensions. ME> (The real problem is that evaluating a defadvice form (via ME> eval-expression or similar) for a compiled file changes the ME> return value of (compiled-function-annotation def) to ME> "loadup.el".) > It does? Yes. As well anything evaluated in *scratch*, etc. > I am aware of problems of using `find-function' with adviced > functions. It is mentioned in the to-do list: however I don't > have a good solution for this. Again maybe this problem has also > been solved in XEmacs-21-beta by `load-history'? Unfortunately, no. I advise `save-buffers-kill-emacs' in .emacs: (symbol-file 'save-buffers-kill-emacs) => "~/.emacs"

1 participants
0 comments

Re: size of XEmacs binary under Sparc/Solaris 2 26 years, 6 months

SL Baur

Olivier Galibert <galibert(a)pobox.com> writes: > You may want to look at your link phase if they are used or not for > you. Another thing to compare is whether or not you have exceptions compiled in. Some versions of newer Gcc have had them enabled by default and they have a huge effect on binary size.

1 participants
0 comments

[problem] generating autoloads for mule-base/ethio-util.el 26 years, 6 months

Jens-Ulrik Petersen

I can't build the mule-base/ of the current cvs xemacs-packages: ---- Start of included text -----------------------8<--- cut here ------------- make[1]: Entering directory `src/xemacs-packages/mule/mule-base' xemacs -vanilla -batch \ -eval "(setq autoload-package-name \"mule-base\")" \ -l autoload -f batch-update-directory . Updating autoloads in directory src/xemacs-packages/mule/mule-base... Generating autoloads for mule-base/_pkg.el... Generating autoloads for mule-base/ethio-util.el... Unbalanced parentheses xemacs exiting. make[1]: *** [auto-autoloads.el] Error 255 make[1]: Leaving directory `src/xemacs-packages/mule/mule-base' ---- End of included text -------------------------8<--- and here ------------- It looks like "mule-base/ethio-util.el" has been corrupted? After renaming the file in question, I could build mule-base. -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

2 participants
1 comments

Re: XEmacs 20.4: find-function-noselect 26 years, 6 months

Jens-Ulrik Petersen

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> Hrvoje> writes: >> >> `file-name-sans-extension' looks like a good thing. Except: >> >> (file-name-sans-extension ".emacs") => "" >> >> which looks like a bug to me? Hrvoje> It's not a bug in `file-name-sans-extension' (IMHO), but I Hrvoje> see what you mean... I beg to differ: I think scsh gets this right ---- from the Scsh manual -----------------------8<--- cut here ------------- (file-name-extension {fname}) -> string Procedure Return the file-name's extension. (file-name-extension "main.c") => ".c" (file-name-extension "main.c.old") => ".old" (file-name-extension "/usr/shivers") => "" Weird cases: (file-name-extension "foo.") => "." (file-name-extension "foo..") => "." Dot files are not extensions: (file-name-extension "/usr/shivers/.login") => "" (file-name-sans-extension {fname}) -> string Procedure Return everything but the extension. (file-name-sans-extension "main.c") => "main" (file-name-sans-extension "main.c.old") => "main.c" (file-name-sans-extension "/usr/shivers") => "/usr/shivers" Weird cases: (file-name-sans-extension "foo.") => "foo" (file-name-sans-extension "foo..") => "foo." Dot files are not extensions: (file-name-sans-extension "/usr/shivers/.login") => "/usr/shivers/.login" Note that appending the results of `file-name-extension' and `file-name-sans-extension' in all cases produces the original file-name. ---- End of included text -------------------------8<--- and here ------------- A leading dot should never be considered to be an extension separator. I can't think of any example where (file-name-sans-extension ".file") => "" would be useful. If we can agree on this, I volunteer to send in a patch. -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

3 participants
3 comments

Re: Packaging -- yet another confused person 26 years, 6 months

Michael Sperber

>>>>> "David" == David Bush <david.bush(a)adn.alcatel.com> writes: David> I thought that I understood where to put packages, but I just updated David> to b40-pre2 using CVS and was disabused of this conceit. David> I had downloaded several of the package tarballs from binary-packages David> and untar'd them into /usr/local/lib/xemacs/packages. Under b38, David> the installed xemacs found them. I just rebuilt after updating from David> CVS and now the new executable does not find the .el's when run David> out of the build directory. Where have I turned wrong this time. Beats me. David> This is cygwin/W95 if it matters. None of the relevant code has changed in the slightest since b38. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
2 comments

Re: INLINE: wtf? 26 years, 6 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > Hrvoje> How do I turn that junk off and simply say that I want this function > Hrvoje> to be inlined, in a portable way (portable as in "ignore it on > Hrvoje> compilers that don't support the `inline' keyword)? > > Currently all explicitly inline functions exist only in header > files, where they are defined via INLINE, which takes care of the > thorny issues of multiple definitions of the function in gcc via > inline.c. I know that, but I don't *want* to do this. > For functions only used in a .c file, you could do (untested) > > static inline int > digit_to_number (int character, int base) Will this not choke on compilers that don't support the inline keyword? Does config.h.in #define inline to naught when inline is not available? > One reason this has never been done is that it should be unnecessary > with most modern compilers at sufficient levels of optimizations. It *is* necessary. Some people don't want to use -O3 because it generates much more code. On the other hand, -O2 will produce a funcall for each mention of digit_to_number(), which I decidedly don't want. Using the inline keyword sparingly has the advantage of specifying exactly which functions you want inlined, regardless of the optimization level. > Both gcc -O3 and Sun cc -xO4 do inlining of static functions > automatically. I know, but see above. > In fact, inline, like register, is merely a hint to the compiler. There is a difference. > Are you sure you know better than the compiler whether inlining > digit_to_number is worth it? Actually, in this case, both you and > the compiler should be able to figure it out, since it's trivial. Again, see above. -O3 makes the compiler inline many other functions, which I may or may not want. > # pgcc optimized build: > $ nm data.o | g digit_to_number > $ > # pgcc debug build: > $ nm data.o | g digit_to_number > 00003ea0 t digit_to_number > $ > > We should make -O3 the default optimization flag for gcc. In fact, > I submitted a patch that did this, but Steve REJECTED it. I agree with Steve. -O3 generates much more code. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Your lucky number today is 29842924728. Look for it everywhere.

2 participants
2 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 May 1998