June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

Hrvoje Niksic

karlheg(a)cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes: > >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: > > sb> Or maybe no one cares and we can drop XEmacs/no-Mule entirely > sb> ... > > Is Mule really that much slower than nomule, or with coding system > only? I think a lot of non-mule users would like to keep using it > without the mule support if it's faster enough to matter. Random access to internal text representation is O(n) due to Charcount<->Bufbyte conversions. Thus simple iteration through a string is in fact an O(n^2) operation[1]. Buffers have a small cache of calculated byte positions, but the caches are not very efficient, either. Also, Mule does wonders with its guessing and file coding code. Look at lread.c for an example of what streams can do to you. [1] This is in Lisp. In C, most code has been rewritten to use INC_CHARPTR and DEC_CHARTPR macros to avoid the slowdown. See the Mule coding guide in the Internals manual for more details.

1 participants
0 comments

Re: ps-print-nomule test package 24 years, 10 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > E Deweese and is only for use with Non-Mule XEmacsen. As soon as we > get multiply-versioned-incompatible-packages working, it should be > renamed to ps-print. I still think it is overkill to handle it in the package system. Christoph Wedler's x-symbol package also can handle difference like this. If I recall correctly his solution is to have a simple wrapper that actually loads the right file. I think the number of elisp files that needs such treatment will be fairly small. In fact I agree if it isn't then keeping up Mule vs Non-Mule will be very hard. Jan

1 participants
0 comments

Re: Making docdir configurable 24 years, 10 months

Michael Sperber

>>>>> "Karl" == Karl M Hegbloom <karlheg(a)cathcart.sysc.pdx.edu> writes: >>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: Michael> For XEmacs, what's needed is something which works at the Michael> package level in a quite different way. Karl> Tell me if I'm way off base. I feel like I barely know what I'm Karl> talking about. Not at all. Karl> It would have to run an `install-xemacs-package' utility that Karl> updated that database. I think that the question of whether or not to have a database with package information around should be orthogonal to the design of the package layout itself. I think the package layout should provide all relevant information purely by and of itself in a manner as non-redundant as possible. The package system should be able to function without *any* auxiliary databases. Once the package information is sufficiently reified within XEmacs, it should be very easy to add optional and completely transparent database support to speed up access. I personally have been hurt time and again by software which keeps redudandant databases of auxiliary files, which is why I'm (and my users) are very willing to pay a price in startup speed for guaranteed system consistency. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

mule on Irix 5.3 (motif XIM) 24 years, 10 months

Gunnar Evermann

In my continuing struggle to build XEmacs on Irix5.3 I encountered the following: Program received signal SIGSEGV, Segmentation fault. #0 XmImRegister () at XmIm.c:317 #1 0x4fa6f4 in XIM_init_frame (f=0x0) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/input-method-motif.c:144 #2 0x6360d4 in x_popup_frame (f=0x10286600) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/frame-x.c:2079 #3 0x637b30 in x_init_frame_3 (f=0x0) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/frame-x.c:2196 #4 0x561764 in Fmake_frame (props=-1609195516, device=539447552) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/frame.c:465 #5 0x4b5df4 in funcall_recording_as (recorded_as=0, nargs=2, args=0x7fff9e28) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3197 #6 0x4b6320 in Ffuncall (nargs=0, args=0x1) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3238 #7 0x46b628 in Fbyte_code (bytestr=1610911412, vector=-2147184884, maxdepth=1076491692) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/bytecode.c:416 #8 0x4b7a30 in funcall_lambda (fun=537169752, nargs=0, arg_vector=0x7fffa17c) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3597 #9 0x4b60c0 in funcall_recording_as (recorded_as=0, nargs=0, args=0x7fffa178) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3214 #10 0x4b6320 in Ffuncall (nargs=0, args=0x1) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3238 #11 0x46b628 in Fbyte_code (bytestr=1611036556, vector=-2147059664, maxdepth=-1609044764) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/bytecode.c:416 #12 0x4b7a30 in funcall_lambda (fun=537295092, nargs=0, arg_vector=0x7fffa5dc) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3597 #13 0x4b60c0 in funcall_recording_as (recorded_as=0, nargs=0, args=0x7fffa5d8) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3214 #14 0x4b6320 in Ffuncall (nargs=0, args=0x1) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3238 #15 0x46b628 in Fbyte_code (bytestr=1611034388, vector=-2147061740, maxdepth=-1608848612) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/bytecode.c:416 #16 0x4b7a30 in funcall_lambda (fun=537293300, nargs=0, arg_vector=0x7fffa6f0) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3597 #17 0x4b70fc in apply_lambda (fun=537293300, numargs=0, unevalled_args=-1609195516) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3501 #18 0x4b52f8 in Feval (form=1075772844) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:3085 #19 0x4b0340 in condition_case_1 (handlers=0, bfun=0x1 <__dso_displacement+1>, barg=272061248, hfun=0x1035b740 <_end+2139712>, harg=-1609195516) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:1653 #20 0x47c998 in top_level_1 (dummy=0) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/cmdloop.c:206 #21 0x4aff34 in internal_catch (tag=0, func=0x1 <__dso_displacement+1>, arg=272061248, threw=0x0) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/eval.c:1328 #22 0x47b85c in initial_command_loop (load_me=1) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/cmdloop.c:285 #23 0x4a9c68 in xemacs_21_1_p3_mips_sgi_irix5_3 (argc=2, argv=0x7fffaee4, envp=0x10375340, restart=0) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/emacs.c:1714 #24 0x4aa960 in main (argc=0, argv=0x1, envp=0x10375340) at /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3/src/emacs.c:2131 uname -a: IRIX delta 5.3 11091812 IP22 mips ../xemacs-21.1.3/configure '--with-pop' '--x-includes=/usr/local/X11R6.4/include' '--x-libraries=/usr/local/X11R6.4/lib' '--site-prefixes=/usr/local /home/tigger3/ge204/local-irix' '--prefix=/tools/emacs' '--with-gnu-make' '--with-mule' XEmacs 21.1-p3 "Acadia" configured for `mips-sgi-irix5.3'. Where should the build process find the source code? /tmp_mnt/home/tigger3/ge204/src/xemacs-21.1.3 What installation prefix should install use? /tools/emacs What operating system and machine description files should XEmacs use? `s/irix5-3.h' and `m/iris4d.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/local/X11R6.4/include Where do we find X Windows libraries? /usr/local/X11R6.4/lib Additional prefixes: /usr/local /home/tigger3/ge204/local-irix Runtime library search path: /usr/local/lib:/usr/local/X11R6.4/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access ge204＠chicago$ gcc -v Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.3/specs gcc version 2.7.2.3 I'll try building with xlib XIM next, but that has to wait until tomorrow, as I finally need some food. I already missed lunch due to XEmacs hacking... :-) Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

2 participants
1 comments

Re: X selection bug in 21.1 24 years, 10 months

SL Baur

Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > At 02:16 PM 6/28/99 +0900, SL Baur wrote: >> Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes in xemacs-beta(a)xemacs.org: >> >>> can somebody reproduce (or even fix) this? >> >> I cannot duplicate this in 21.2. Andy Piper has changed the selection >> code fairly heavily and perhaps he has fixed this bug. > In theory I didn't change the X code at all. I just moved the general bits > into a general place. So I'm unhappy about taking the credit for this... Hmm, that's bad. Fortunately, I think, I cannot duplicate the problem in 21.1.3 either. -- 落花枝に帰らず破鏡再び照らさず

1 participants
0 comments

The crash bug from earlier... 24 years, 10 months

Karl M. Hegbloom

I cannot reproduce it. I don't know why it fell down before. If I catch it again, I'll mail yous the postmortem.

1 participants
0 comments

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: ... Jan> Or we will just make the requirement that each set of lisp files Jan> with data files needs to be in its own package? >> >> I don't understand what you're saying here. Don't we currently >> fulfill that requirement? Yes. > I think so. But it is more or less by accident. It is no accident. -- 弱り目に祟り目

1 participants
0 comments

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: sb> Packages typically want to know two specific things about the external sb> environment. > There is also the > 4. Package needs to have specific code eval'ed at startup time, i.e. > the autoloads. Right. ... >> I think especially this last bit will have to change: I would want a >> package to identify itself (implicitly or explicitly) when asking for >> the location of its associated files. > Hmm.. isn't the problem here that a particular lisp file might not > even know which package it is in? Or care. These kinds of lisp files are currently packaged together in thematic bundles. > Or we will just make the requirement that each set of lisp files > with data files needs to be in its own package? This is current practice. In addition to data files, add manuals and helper scripts/executables. -- 能ある鷹は爪を隠す

1 participants
0 comments

Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable) 24 years, 10 months

A.J. Rossini

>>>>> "KMH" == Karl M Hegbloom <karlheg(a)cathcart.sysc.pdx.edu> writes: >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Or maybe no one cares and we can drop XEmacs/no-Mule entirely sb> ... KMH> Is Mule really that much slower than nomule, or with coding KMH> system only? I think a lot of non-mule users would like to KMH> keep using it without the mule support if it's faster enough KMH> to matter. Data point: I just moved over from non-mule (21.1.p2) to mule (21.1.p3) and yes, on my dual P2-350, there is a difference. I notice about .1--.25 second slower speed for a few intensive elisp programs (gnus with every concievable option, ESS (a stat interface I need to xemacs-package up, sigh), bbdb on my 500K .bbdb file :-). If I'm not compiling (which happens with ESS, which I'm developing), it's worse. But, not worse enough to worry about :-). (add another 0.5sec to the response). I'm not seeing much slowdown (any? I can't tell) with Java/Python programming using Speedbar/CC/JDE/Python modes, I recently had the pleasure of running on a 486/66. Now that's slow. But not XEmacs/mule on "modern" hardware :-). I guess it depends on the comparison... best, -tony -- A.J. Rossini Research Assistant Professor of Biostatistics Center for AIDS Research UW Biostatistics 206-720-4282 (4209=fax) 206-543-1044 (xxxx=fax) rossini(a)u.washington.edu rossini(a)biostat.washington.edu http://www.biostat.washington.edu/~rossini/

1 participants
0 comments

~/.xemacs/ or ~/xemacs/? (Was: Re: [XEmacs] New Maintainer, soonish.) 24 years, 10 months

Karl M. Hegbloom

[ Bcc: xemacs-beta mailing list ] Let's move this thread over to `debian-emacsen' please. >>>>> "Michael" == Michael Stone <mstone(a)debian.org> writes: Michael> [1 <text/plain; us-ascii (quoted-printable)>] On Fri, Jun Michael> 25, 1999 at 06:47:45PM -0700, Karl M. Hegbloom wrote: >> - I changed the startups so that the init file is no longer >> called >> "~/.emacs", it's in "~/.xemacs/init.el". The options saved by >> the Options menus won't go into "~/.emacs" either, they'll go >> into "~/.xemacs/.options.el". It will create the "~/.xemacs/" >> directory I'm doing this so it will be possible to install both GNU Emacs and XEmacs on the same machine, without user config file clash hassles. This way, nobody has to write conditionals into ~/.emacs to make it work with both XEmacs and GNU Emacs. Michael> If it's in a "hidden" directory, is there a point in Michael> hiding the file? (ISTMT ~/.xemacs/options.el would be Michael> more noticable.) Should it be "~/.xemacs/", or "~/xemacs/"? What's the consensus?

1 participants
0 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 June 1999