January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > We give the memory of destroyed buffers back don't we? > > > > Only in some cases, when compiling with relocating allocator. > > But these some include 99% of the platforms our user run on, don't > they? The fact is, I'm not convinced that Scheme works reliably. The mmap-based relocating allocator is supposed to return memory to the system, but even so... I still think opening (and unzipping) a bunch of files is not to be dismissed lightly. I guess I'm in the minority. > [The devils advocate could argue at this point that you should > consider switching to a distro that has more frequent releases] Like Solaris? :-) I'd use just about anything else, but everyone around me uses Debian, so Debian it is. (And yes, they use potato too.) Ah, if only system administration were my favorite hobby. > > > > What's ~/.xemacs? > > > > > > A convenient directory for XEmacs to write stuff too, such as > > > precomputed help tables of contents. > > > > I thought the idea was that such a directory was strictly > > optional. I, for one, don't have one. > > But if you need a feature that needs it, you'll need to. In that case, XEmacs should create it for me. My turn to play the devil's advocate, I guess.

1 participants
0 comments

Re: Info disaster? 24 years, 4 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > But it is only once per XEmacs session, > > I'm sorry to be a spoil-sport, but no it's not. Than _that_ is a bug. > > We give the memory of destroyed buffers back don't we? > > Only in some cases, when compiling with relocating allocator. But these some include 99% of the platforms our user run on, don't they? > > Don't use unstable versions of distributions (although I need to see > > whether the transition is complete enough, come potato release > > time). > > You have got to be kidding. Slink is older than bible, and the > versions of some crucial packages are too old to be even useful. I use a Slink+minimal updates at home it still works adequately... [The devils advocate could argue at this point that you should consider switching to a distro that has more frequent releases] > > > What's ~/.xemacs? > > > > A convenient directory for XEmacs to write stuff too, such as > > precomputed help tables of contents. > > I thought the idea was that such a directory was strictly optional. > I, for one, don't have one. But if you need a feature that needs it, you'll need to. Jan

1 participants
0 comments

Re: Info disaster? 24 years, 4 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> No, I don't see one. Furthermore, Michael, I don't understand you of Stephen> all people making this objection. I thought you advocated automatic Stephen> building of lists of files and things whenever possible, precisely Stephen> because you think XEmacs can get it as right as anybody does? The discussion you refer to was centered around an entirely different topic---we were arguing whether missing dir files should produce error messages. But you're right: If it were up to me, I'd dump the whole concept of dir files and caches and whatnot. My machine isn't especially fast by today's standards, and when I start up info, it pulls a gazillion info files from a distributed file system. I don't mind the startup cost (maybe 20 seconds) at all. I think the problem in Hrvoje's setup is really that all the info files are gzipped. Given today's price for disk space, I think unpacking them would be the easiest way to fix the problem. Stephen> If so, shouldn't the only cache we trust be one we make Stephen> ourselves? Sure, but in that case, let's abandon dir files entirely. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 4 months

Daniel Pittman

On 05 Jan 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote: > Daniel Pittman <daniel(a)danann.net> writes: > >> > Otherwise, it seems that the XE_DIE check doesn't get called. Do >> > you think it's a bug? >> >> The check should trigger if it finds a *compile time* >> mismatch. Sadly, this does not seem to follow quite the same rules >> as ld.so. :( >> >> What does ldd(1) say about your XEmacs? > > $ ldd src/xemacs > libXaw.so.6 => /usr/X11R6/lib/Xaw3d/libXaw.so.6 (0x40018000) This is the /wonderful/ Debian thing. At compile time, with flat Xaw, we pick up /usr/X11R6/lib/libXaw.* -- but at runtime the ld.so.conf puts the Xam3d library as 'libXaw.so' in the path first. This can't be found through any method short of dynamic-linking of an executable at configure time and looking in the output on STDERR for the cursed `consider relinking' thing. The quick fix[1] is to edit /etc/ld.so.conf and move the entry for /usr/X11R6/lib/ before the entry for /usr/X11R6/lib/Xaw3d/. That will pick up the correct flat Athena. Building with `--with-athena=3d' will also work. I don't know if we /can/ do anything much about the issue otherwise. It's not actually fixable easily (thanks, Debian) as far as I can see. LD_PRELOADing the correct Athena library would also work.... Daniel Footnotes: [1] which makes everything else use flat Athena unfortunately -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson

2 participants
1 comments

Re: Info disaster? 24 years, 4 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> 1) I meant: cache between two invocations of XEmacs. > > But if you want to do this, the dir files are, by design, *exactly* > the place for such a cache. Except that the dir files are not writable for the user. Do you all people run as root or something? :-) > If you introduce another cache level, you now have 2 possible levels > of inconsistency. Do I have a choice?

2 participants
1 comments

Re: 21.2 Out of sync: window-minibuffer-p arg is optional in Emacs 24 years, 4 months

Hrvoje Niksic

posting-list(a)mailandnews.com (Jari Aalto+mail.emacs) writes: > This is just my opinion, but if function starts with argument BUFFER > ot WINDOW or FRAME, they all should be optional and by default refer > to current (active) unit. An argument should be optional only if it makes sense for it to be optional. For instance, functions used in loops like `window-next-child' or `window-parent' almost never want to deal with selected window. Also, doesn't add much value for `window-live-p' to default to selected window, since the selected window will always be live. I'll update window-minibuffer-p for the sake of compatibility, but I won't touch other functions.

1 participants
0 comments

Re: Minor before/after-change cleanup 24 years, 4 months

Hrvoje Niksic

Norbert Koch <norbert(a)s.netic.de> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > This patch cleans up some code in insdel.c and extents.c related to > > reporting before and after change functions. It does not fix the ^^^ > > infamous modified-buffer-in-change-functions bug mentioned before. > > The fix for that should come in later, if things are right. I've ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > separated this patch because it should be independent of the other, > > and to make review easier. > > Hi Hrvoje! > > If this (too) is meant to fix the bug reported by me (wrt w3) then > sorry not yet. Look for the highlighted words. Fortunately, my patch was followed by a *second* patch, which when applied after the first one DOES fix that crash (or so it should.) Please test that one. > Do we have sort of a "off by one error"? What we have is a "modification function changes the buffer endpoints and trips the code that expects them to stay unchanged error". :-) > #6 0x8109b83 in signal_after_change (buf=0x82f8400, start=0, orig_end=2909, > new_end=0) at insdel.c:2320 > #7 0x810a9f9 in buffer_insert_string_1 (buf=0x82f8400, pos=2909, > nonreloc=0xbfbfd0f4 ">\n", reloc=136603652, offset=0, length=2, flags=0) > at insdel.c:2594 > > What strikes me odd is, that the variable pos changed its value from > -1 to 2909 between these two calls (an optimisation issue?). -1 means "the value of point". 2909 is the actual point.

2 participants
1 comments

Re: Info disaster? 24 years, 4 months

Mike Fabian

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: [...] > > > Just make sure your dirfiles are complete. > > > > How do I do that? [...] > Alternatively, ask "your sysadmin" to run a tool to rebuild the > system-wide dir files (Unfortunately the only such tools seems to be XEmacs). The command-line-tool `install-info', which comes with the GNU texinfo distribution can do that too. -- Mike Fabian <mike.fabian(a)gmx.de> <mike(a)nozomi.rhein-neckar.de>

1 participants
0 comments

report_extent_modification() crash (hopefully) fixed 24 years, 4 months

Hrvoje Niksic

I think the report_extent_modification() crash should be fixed in current CVS. Please try it and let me know. One crash recipe is available at <http://www.xemacs.org/cgi-bin/wilma_hiliter/xemacs-beta/199912/msg00323.html>.

1 participants
0 comments

Re: Info disaster? 24 years, 4 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > > For me the scanning takes a few seconds and surely is worth it. > > > > "A few seconds" is a long time when it repeats all the time. > > But it is only once per XEmacs session, I'm sorry to be a spoil-sport, but no it's not. I get it repeatedly. The best way to repeat it is by going somewhere deep into Info hierarchy, and then press `u' repeatedly to return to `dir'. For some reason, in some cases the top-level dir used to be forgotten and regenerated. > > it very annoying. (And I also wonder about the memory footprint, > > but I'm repeating myself here.) > > We give the memory of destroyed buffers back don't we? Only in some cases, when compiling with relocating allocator. > > > Ad 2. I would say this falls under the "Don't do that then" category. > > > Just make sure your dirfiles are complete. > > > > How do I do that? > > Don't use unstable versions of distributions (although I need to see > whether the transition is complete enough, come potato release > time). You have got to be kidding. Slink is older than bible, and the versions of some crucial packages are too old to be even useful. > > > Ad 3. Seems like a good idea. Something for under ~/.xemacs? > > > > What's ~/.xemacs? > > A convenient directory for XEmacs to write stuff too, such as > precomputed help tables of contents. I thought the idea was that such a directory was strictly optional. I, for one, don't have one.

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 January 2000