September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Andy Piper

Darryl Okahata <darrylo(a)sr.hp.com> writes: > I just realized that I'm still using B55, and just submitted a patch > relative to it, whereas B56 has been out for a while. Where is B56? Is > it in beta/xemacs-21.0-preliminary? Yes, I believe so. andy

1 participants
0 comments

Re: fix for redisplay! 25 years, 8 months

Hrvoje Niksic

Ben, I'm sorry for my overreaction. It's just that I have such an intense dislike for the "use Mozilla 'coz it's cool" attitude of Netscape people that I'm unable to express it with words. But that's another matter. I agree with you about the XEmacs project being understaffed. However, you are missing one important point about this "fix for redisplay" thread, which is: This is not only about W3. Whenever one tries to use the "advanced" features of XEmacs, such as images, toolbars, flashy colors, various complex interactions, etc., XEmacs has a very good chance of becoming either abysmally slow or unacceptably unstable. Packages such as W3, VM and SparcWorks are only examples of this. Any fix to XEmacs redisplay that would make W3 run fast would also make faster many other XEmacs components. The goal is not to have an XEmacs with a built-in web browser that works, but to have an XEmacs so powerful and so flexible that it is possible to implement a web browser that works within it. Do you see the difference? You also say: Currently, we try to act as if we support all sorts of extensions to XEmacs, and sometimes their priorities get shifted above the priorities of much more basic things, such as getting the web site completed. One of the banes of volunteer-based projects is that there is no way to force people to do what they don't like to do. Doing interesting stuff is the main reason we're here, after all. Otherwise, they might as well do some more work for our employers and get more money. Because of the "understaffed", the result is that XEmacs does a lot of things, but doesn't do any of them very well at all... In a state like this, its user-base is never going to be very high. I disagree with this. Most of what XEmacs does, it does fairly well, and I fail to see the problems that would scare away the users and the hackers. The reasons why XEmacs does not gain a larger user-base are rooted elsewhere; some of the hackers simply dislike its interface; some dislike the sheer size of the product; and yet others find it too slow. Some people simply favor FSF Emacs because of the name "FSF". These things are IMHO much more important than the up-to-datedness of the web site, and they won't go away any time soon. ...[if we make XEmacs just work] we can probably get done all of those add-on features, like making a better web-browser, and so on, that we might be not able to get done at all if we try to concentrate on those features first. Please note, again, the difference between speed/robustness issues and the mere presence of features. I am arguing for the former, and you are arguing against pushing the latter. However, even when applied to speed/robustness, your argument relies on the assumption that "making XEmacs just work" will attract a horde of new users and developers. I am not convinced that this is the case. I am also not convinced that it is really possible to fully respect priorities in a volunteer project, unless you really have a bunch of people to work with (this is the case with Linux.) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "A Real Programmer's code can awe with its fiendish brilliance, even as its crockishness appalls."

5 participants
5 comments

[patch] regex crash in complicated expressions 25 years, 8 months

Jareth Hein

This is a tentative patch that I'd really like people to beat on. There is a bug in the regexp engine that goes way back, and it's particularly tickled by the regexps in the java/jde fontlock code. An easy way to check (this will crater XEmacs!) it is to create a test java file (C-x f /tmp/test.java) , and do the following: I C-u 68 <space> I C-a C-f C-f X <boom!> The problem is that if the pattern jumps out of a nested group, the lowest active register is not being properly reset. This results in lowest being greater than highest, and a lot of pointer arithmetic gets fubared (the 68 spaces above makes sure that the pointer will jump way past the potential reg and failure heaps and into other memory to cause the crash). This might explain why the bug hasn't been found until now: unless you're applying a rather deeply nested match against a whole line the memory stomping will probably be in areas that aren't used. I'm running my version of Norwegian with this, and so far have had no problems. (in fact, in some cases it feels a little faster... wonder why?) but I'd really like everyone to pound on this before I say stick it into 21.0. Granted it fixes a bug that we've receieved several bug reports on, and I'm 80% sure it's the proper solution, but I don't want to cause more problems than I fix... -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "It's a sad sign of the times when 'political machine' is redefined to include 'main-line battle tank'" - Ambassador Grossblunder

1 participants
0 comments

Where is B56? 25 years, 8 months

Darryl Okahata

I just realized that I'm still using B55, and just submitted a patch relative to it, whereas B56 has been out for a while. Where is B56? Is it in beta/xemacs-21.0-preliminary? -- 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
0 comments

[PATCH][for 21.0] Basic package deletion & maintenance 25 years, 8 months

Darryl Okahata

SL Baur <steve(a)xemacs.org> wrote: > We need a delete function for XEmacs packages. I can make binary OK, here are some patches that provide a BASIC package delete capability. Note that these are relative to B55 *plus* my "[URGENT PATCH] Visual package installer" patch. A ChangeLog is appended. Comments: * There's no nice user interface to the package deletion functions. The user has to manually do a `M-x package-get-delete-package'. * Deleting a package will use any exiting pkginfo/MANIFEST.<package> file. Installing a package file will also create a MANIFEST.<package> file, but only if one is not included with the package. * There's no dependency checking (to be added later). The user can currently delete a package that is required by other packages. Lisp ChangeLog: =============================================================================== 1998-09-20 Darryl Okahata <darrylo(a)sr.hp.com> * packages.el: Added new function, `package-delete-name', to delete existing packages from the installed package database (`packages-package-list'). Also added the "pkginfo" directory to `packages-special-base-regexp', so that the pkginfo directory would not get added to `late-packages'. * package-admin.el: Added ability to delete an installed package (added low-level function, `package-admin-delete-package'). Understands how to use the pkginfo/MANIFEST.<package> file to delete the package. When installing a package, will also create a MANIFEST.* file if one is not provided by the package. If the MANIFEST.* doesn't exist when deleting a package, the functions will fall back to attempting to delete any package-specific lisp directory. * package-get.el: Moved some functions to package-admin.el. Added interactive function `package-get-delete-package', for use by users for deleting a package. Also modified to not require the prescence of efs. =============================================================================== [ Am I the only one uncomfortable with these last-minute changes to 21.0? Yes, these features are nice-to-have, but are they really required? I've got a lot of package installation enhancements that I'd like to make (Greg Klanderman made a lot of great suggestions), but we'd never release 21.0 if we keep on dribbling in these changes. ] -- 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
0 comments

Re: [Success] XEmacs 21.0 "Norwegian", sparc-sun-solaris2.7 25 years, 8 months

Matt Simmons

Norwegian worked under 2.7 (ahem) for me. describe-installation is below: uname -a: SunOS auckland 5.7 Beta_Update i86pc i386 i86pc ./configure '--prefix=/p/local/xemacs-21.0' '--site-prefixes=/usr/local' '--site-includes=/usr/local/include/compface /usr/local/include/jpeg /usr/local/include/tiff /usr/local/include/png /usr/local/include/zlib /usr/local/include/gifreader' '--site-runtime-libraries=/usr/dt/lib /usr/openwin/lib /usr/local/lib' '--package-path=/p/local/elisp/packages-21.0' '--infodir=/p/local/xemacs-21.0/info' '--error-checking=none' '--with-x11' '--with-menubars=lucid' '--with-dialogs=athena3d' '--with-mule' '--gung-ho' '--cflags=-fomit-frame-pointer' XEmacs 21.0 "Norwegian" configured for `i386-pc-solaris2.7'. Where should the build process find the source code? /home/simmonmt/xemacs/xemacs-20 What installation prefix should install use? /p/local/xemacs-21.0 What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -fomit-frame-pointer 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/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional header files: /usr/local/include/compface /usr/local/include/jpeg /usr/local/include/tiff /usr/local/include/png /usr/local/include/zlib /usr/local/include/gifreader Additional prefixes: /usr/local Runtime library search path: /usr/dt/lib:/usr/openwin/lib:/usr/local/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 GNU 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 CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. -- Matt Simmons - simmonmt(a)acm.org - http://www.netcom.com/~simmonmt Man does not live by words alone, despite the fact that sometimes he has to eat them. --Adlai Stevenson

1 participants
0 comments

Re: XEmacs packages poll 25 years, 8 months

Matt Simmons

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> pkginfo/MANIFEST.gnats sb> pkginfo/MANIFEST.gnus sb> pkginfo/MANIFEST.mailcrypt Is it too late to request pkginfo/$PACKAGE/MANIFEST? It keeps ls output more manageable, especially if you have lots of packages installed. Matt -- Matt Simmons - simmonmt(a)acm.org - http://www.netcom.com/~simmonmt Originality is the fine art of remembering what you hear but forgetting where you heard it. --Laurence Peter. Canadian writer

1 participants
0 comments

Re: XEmacs packages poll 25 years, 8 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > > SL Baur <steve(a)xemacs.org> writes: > >> Is there a volunteer to create such a Makefile? You can assume that > >> the template will be passed the names of the manual(s), that there > >> is no need to worry about dependencies of source files (they're > >> really handled in the canonical-for-XEmacs sources), and you can > >> assume GNU Make is being used. > > > Is GNU make really needed? Not all of us are running under Linux. > > GNU make is very much needed for package building the same as it is > required to build XEmacs with the --srcdir flag. Since when has GNU make been required to build with --srcdir? I am getting very worried by this. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Old numerical analysts never die, they just get disarrayed.

2 participants
1 comments

Re: XEmacs packages poll 25 years, 8 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > SL Baur <steve(a)xemacs.org> writes: > > > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > > > > SL Baur <steve(a)xemacs.org> writes: > > >> Is there a volunteer to create such a Makefile? You can assume that > > >> the template will be passed the names of the manual(s), that there > > >> is no need to worry about dependencies of source files (they're > > >> really handled in the canonical-for-XEmacs sources), and you can > > >> assume GNU Make is being used. > > > > > Is GNU make really needed? Not all of us are running under Linux. > > > > GNU make is very much needed for package building the same as it is > > required to build XEmacs with the --srcdir flag. > > Since when has GNU make been required to build with --srcdir? I am > getting very worried by this. GNU make is only required to build if you try to use a directory that already has a configured system in it as your --srcdir. Otherwise it should work ok. I think this is a valid case to require it. Or, what I do in my autoconf stuff here at work - just bitch and refuse to do it. :) If it doesn't then it's a heinous bug and needs to be fixed. _I_ can require GNU make for our build process at aventail because we have a limited # of source licensees and I can make them dance as much as I want, but to force this requirement on everyone that wants to compile XEmacs is unacceptable. -Bill P.

1 participants
0 comments

Re: [PATCH] 21.2-b1 redisplay-echo-area bug 25 years, 8 months

Hrvoje Niksic

Louis-Dominique Dubeau <ldd(a)step.polymtl.ca> writes: > I hypothesized that the problem was garbage collection so I decided > to protect "window". I rebuilt and ran xemacs again: the error was > gone. Since this function doesn't create window, I don't think it should GCPRO it. As Kyle said, the bug is due to bad code generated by the compiler. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Jone's law: The man who smiles when things go wrong has thought of someone to blame it on.

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