October 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Introduction: Richard Reingruber 23 years, 6 months

Richard

Hello everybody on this list, I will be working with you on XEmacs. As I am new to the XEmacs developper comunity, I should introduce myself: My Name is Richard Reingruber. I am a master student of Michael Sperber. We are planning to integrate a moving generational garbage collection into XEmacs. Currently mutator and garbage collection are tighly couppled through the way lisp objects are represented. So a first step is to replace this representation and make the lisp Objects more abstract. My work will be in the cvs repository on a branch called NewGC-21-2 Richard

1 participants
0 comments

Re: syntax-table text properties 23 years, 6 months

Hrvoje Niksic

Matt Tucker <tuck(a)whistlingfish.net> writes: > -- Hrvoje Niksic <hniksic(a)arsdigita.com> spake thusly: > > > Do you plan to add the support for this to the regex code? I have no > > idea how hard that is, or whether the FSF had done it? > > Absolutely. In fact, it's next on my list of things to do. Excellent. After that, I think your patch should just go in. I don't think we even need the configure-time switch, heavens know we have too many of these already. We can keep the Lisp variable for font-lock, though, to bring us through the debugging stage. > FSF supports it, but my impression is that that support might not be > complete. (I've noticed there are a few places in the FSF code where > they don't correctly lookup the syntax table property. My suspicion > is that since this is not a heavily used feature, this hasn't ever > been noticed. I'm trying to clean up these instances as I go.) That's one of the rare good things about "merges" with FSF Emacs: the code gets better debugging because it goes through at least another pair of careful eyes. > I can certainly see the value in it. I'm a bit concerned about the > cost of having to calculate that each time through the parse (on top > of lookup up all the extents in the first place). I agree. > I suppose the right way to do it is instead of keeping a single > syntax table, keep a list of all syntax tables (from innermost out > to the buffer's) and when doing the lookup for a character run > through this list until a match is hit. Yes. Also, you could optimize things by caching these lists in internal hash tables, at the time when they're added to the extent (you have control over the extents code, so you can do that). > One question would be whether a specified code could be overridden > by a more specific table. For example: > > > This is some text with custom syntax tables. > ^---- custom table ---------------^ > ^-- whitespace --------------^ > ^ -- custom table -^ > > Would "custom syntax tables" be whitespace, or would it use the > second custom table for its lookups, and only be whitespace in the > case of characters that don't have a match in the second table? I would say the latter. > I'll probably end up implementing overlappable extents in the next > version, despite the fact that I don't see a need for it yet. > (Perhaps someone else will, if the feature is there.) That would be cool. You might want to look if adding the overlapping support would break compatibility with the FSF for the common cases. And there's the speed issue again. XEmacs is very complex. We should always be extremely careful with adding this kind of stuff.

1 participants
0 comments

Sumo & Packages Release 23 years, 6 months

Steve Youngs

The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. I've just released new sumos and updates to quite a few individual packages. Find them at <ftp://ftp.xemacs.org/pub/xemacs/packages/> or at the usual mirrors. Starting with this release I've signed the package-index file with my GnuPG key. Fingerprint - CFB7 C8C2 2DC7 5608 5C9D 4947 79C1 0339 59E4 C4B2 Please let me know if there are any problems. ========================================================= New in this release: Most of the packages (62 of 85) have been updated. The majority of the updates are doc string typo fixes. So, perhaps this time around you may be better off installing the sumos. ada-1.09-pkg.tar.gz - doc fixes apel-1.19-pkg.tar.gz - doc fixes auctex-1.22-pkg.tar.gz - doc fixes bbdb-1.10-pkg.tar.gz - doc fixes c-support-1.15-pkg.tar.gz - doc fixes calc-1.13-pkg.tar.gz - doc fixes calendar-1.15-pkg.tar.gz - update to cal-xemacs.el cc-mode-1.21-pkg.tar.gz - doc fixes debug-1.12-pkg.tar.gz - doc fixes dired-1.08-pkg.tar.gz - doc fixes edebug-1.11-pkg.tar.gz - doc fixes edict-1.10-pkg.tar.gz - doc fixes edit-utils-1.53-pkg.tar.gz - doc fixes, updates to func-menu.el, new file power-macros.el edt-1.10-pkg.tar.gz - doc fixes efs-1.21-pkg.tar.gz - doc fixes, fix to CWD problem egg-its-1.23-pkg.tar.gz - doc fixes, update to egg.el eicq-1.02-pkg.tar.gz - doc fixes, update maintainer's email elib-1.07-pkg.tar.gz - doc fixes emerge-1.08-pkg.tar.gz - doc fixes eterm-1.12-pkg.tar.gz - doc fixes eudc-1.32-pkg.tar.gz - doc fixes gnats-1.11-pkg.tar.gz - doc fixes gnus-1.51-pkg.tar.gz - doc fixes hm--html-menus-1.15-pkg.tar.gz - doc fixes idlwave-1.22-pkg.tar.gz - Update to version 4.5 ilisp-1.13-pkg.tar.gz - doc fixes ispell-1.20-pkg.tar.gz - doc fixes jde-1.23-pkg.tar.gz - doc fixes lookup-1.05-pkg.tar.gz - doc fixes mail-lib-1.31-pkg.tar.gz - doc fixes, update to mail-utils.el mailcrypt-2.05-pkg.tar.gz - doc fixes, add gnus, mh-e, rmail, vm to load-path mew-1.11-pkg.tar.gz - doc fixes mine-1.13-pkg.tar.gz - doc fixes mule-base-1.35-pkg.tar.gz - doc fixes net-utils-1.14-pkg.tar.gz - doc fixes os-utils-1.24-pkg.tar.gz - doc fixes pc-1.18-pkg.tar.gz - doc fixes pcl-cvs-1.50-pkg.tar.gz - doc fixes prog-modes-1.30-pkg.tar.gz - doc fixes, updates to sql.el, teco.el, awk-mode.el psgml-1.20-pkg.tar.gz - doc fixes reftex-1.21-pkg.tar.gz - doc fixes semantic-1.02-pkg.tar.gz - Update to version 1.3 sgml-1.07-pkg.tar.gz - doc fixes skk-1.16-pkg.tar.gz - doc fixes slider-1.12-pkg.tar.gz - doc fixes speedbar-1.17-pkg.tar.gz - doc fixes, Update to version 0.13 strokes-1.07-pkg.tar.gz - doc fixes supercite-1.16-pkg.tar.gz - doc fixes text-modes-1.27-pkg.tar.gz - doc fixes textools-1.11-pkg.tar.gz - doc fixes time-1.10-pkg.tar.gz - doc fixes tm-1.24-pkg.tar.gz - doc fixes tooltalk-1.12-pkg.tar.gz - doc fixes tpu-1.11-pkg.tar.gz - doc fixes vc-1.24-pkg.tar.gz - doc fixes vhdl-1.11-pkg.tar.gz - doc fixes view-process-1.10-pkg.tar.gz - doc fixes vm-1.25-pkg.tar.gz - doc fixes w3-1.16-pkg.tar.gz - doc fixes xemacs-base-1.44-pkg.tar.gz - doc fixes, updates to macros.el, add-log.el, compile.el xemacs-devel-1.29-pkg.tar.gz - doc fixes zenirc-1.08-pkg.tar.gz - doc fixes -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|

1 participants
0 comments

Re: [Bug #117375] Long standing bug in XEmacs' dired 23 years, 6 months

Michael Sperber

>>>>> "Boris" == Boris Folgmann <boris(a)folgmann.com> writes: Boris> "Michael Sperber [Mr. Preprocessor]" schrieb: >> My guess is that it's a locale problem. Are the month names in your >> directory listing German by any chance? Boris> Yes, is this the problem? Doesn't XEmacs honor some locale Boris> settings? I know of no way to determine the names of the month from the locale in any automatic fashion. From what I've gathered, FSF Emacs uses some sort of heuristics to work anyway. I'm not a big fan of this approach, but I'll investigate at some point. Anyway, you want to set `dired-re-month-and-time' to something reflecting your locale, and you should be fine. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

3 participants
2 comments

Re: syntax-table text properties 23 years, 6 months

Matt Tucker

I'm cc'ing xemacs-beta on this one, since it includes some discussion about general design issues. I'm attaching the previous messages (which went to xemacs-review), for those who are interested in reading the discussion leading up to this. This is all based on a recently submitted patch which can be found at <http://www.xemacs.org/list-archives/xemacs-patches/200010/msg00077.htm l>. -- Hrvoje Niksic <hniksic(a)arsdigita.com> spake thusly: > Do you plan to add the support for this to the regex code? I have no > idea how hard that is, or whether the FSF had done it? Absolutely. In fact, it's next on my list of things to do. FSF supports it, but my impression is that that support might not be complete. (I've noticed there are a few places in the FSF code where they don't correctly lookup the syntax table property. My suspicion is that since this is not a heavily used feature, this hasn't ever been noticed. I'm trying to clean up these instances as I go.) > Regarding documentation, another place where the new feature should be > mentioned is the docstring of `set-extent-property' where all the > other magical properties are documented. (And it's probably more > advisable to use the term "exent property" rather than "text > property", because the feature does not apply only to text > properties.) Thanks for the suggestion. I'll take care of that. > The point is someone might want to write additional independent code, > such as a minor mode, that adds more extents. This strategy works in > XEmacs because the extents have identities and are allowed to overlap; > therefore each body of code can freely add and remove its own extents > without having to care about the others. I can certainly see the value in it. I'm a bit concerned about the cost of having to calculate that each time through the parse (on top of lookup up all the extents in the first place). I suppose the right way to do it is instead of keeping a single syntax table, keep a list of all syntax tables (from innermost out to the buffer's) and when doing the lookup for a character run through this list until a match is hit. One question would be whether a specified code could be overridden by a more specific table. For example: This is some text with custom syntax tables. ^---- custom table ---------------^ ^-- whitespace --------------^ ^ -- custom table -^ Would "custom syntax tables" be whitespace, or would it use the second custom table for its lookups, and only be whitespace in the case of characters that don't have a match in the second table? I'll probably end up implementing overlappable extents in the next version, despite the fact that I don't see a need for it yet. (Perhaps someone else will, if the feature is there.) > Two more things, based on the font-lock.el part of the patch. > > * I don't see code that implements docstring fontification using > parse-partial-sexp. I think font-lock-docstring-face is a nice > XEmacs addition, and I wouldn't like to lose it. > > * You're using the variables font-lock-string-face and > font-lock-comment-face, instead of the faces directly, as it's > supposed to be done under XEmacs. The variables are evil because > they add a needless new level of indirection, and because changes to > the variables are not reflected in buffers. Thanks. I didn't realize either of these, but I'll make the necessary changes.

1 participants
0 comments

Re: outstanding issues 23 years, 6 months

Raymond Toy

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> Hrvoje Niksic <hniksic(a)arsdigita.com> writes: >> Raymond Toy <toy(a)rtp.ericsson.se> writes: >> >> > o xemacs crashes for me quite often in either gc or >> > make_lisp_buffer_stream. (Already reported). I have a sneaking >> > suspicion that it's a gcc 2.95.2 problem. After recompiling with >> > Sun CC 5.0, I haven't run into it today in the last few hours, >> > whereas it was happening as often as every 30 minutes with gcc >> > 2.95.2. I'll have to try with gcc 2.7.2.2 too. Perhaps a note in >> > the PROBLEMS file? >> >> Maybe, maybe not. Remember that it could also be a memory corruption >> bug, and those can go away when you change *anything* -- and come back >> to haunt you a year later. >> >> Is gcc 2.95.2 a stable release of Gcc? Gunnar> It's supposed to be. Ray, could you try compiling with gcc but with Gunnar> less aggressive optimisation (say -O1 instead of -O3)? I reconfigured with --cflags=-O1 and rebuilt. I get this: Dumping under the name xemacs unexec(): dldump(/apps/public/XEmacs/src/xemacs-21.2.36/src/xemacs): ld.so.1: ./temacs: fatal: /apps/public/XEmacs/src/xemacs-21.2.36/src/xemacs: unknown dynamic entry: 1879048176 So gcc 2.95.2 on Solaris with -O1 optimization can't even produce a working temacs. It does, however, produce a working temacs with -O3 optimization, but that seems to cause crashes while using xemacs. I think I'll stick to gcc 2.7.2.2 or Sun C compiler for compiling xemacs. I've been using the Sun C compiled version for about a day and a half, and it's been quite stable, unlike the crash every 30-60 minutes scenario I was getting last week with 2.95.2. Ray

1 participants
0 comments

Re: RFC: xemacsweb - XEmacs vs. GNU Emacs 23 years, 6 months

Per Bothner

Valdis.Kletnieks(a)vt.edu writes: > 1) Placing code in the public domain means that you can no longer put > a "hold harmless" clause in as part of the copyright (i.e. you can't say > "by copying this software, you agree to not sue us if it breaks"). There is no such clause in the GPL. There is a a non-warranty *statement*, not an *agreement*. I see no reason why you couldn't put such a statement in a public-domain document? (Of course someone might remove it, but then they are the ones likely to get sued.) > Thus, if you put code in the public domain, you're liable to all > sorts of legal nasties if it causes a problem for somebody. You are always liable to all sorts of legal nasties. A non-warranty clause is just a warning, it does not prevent anyone from suing or even winning. It is just informational - though it is good to include it. > 2) Remember that one of Microsoft's first products was a Basic interpreter, > which was basically just a public domain one that was ripped off and sold > under the Microsoft label. Yes, there are good reasons for preferring GPL over public domain (or a looser MIT-style license). I don't see that fear as being important for *changes* to an existing GPL program, since those changes would be difficult to "rip off" and use in a different non-CPL application. (Except perhaps being a new non-trivial algorithm or implementation thereof.) > I think both of these are good reasons why a corporation would want to > be *damned* sure it was issuing code under an appropriate open license > rather than allowing it to slide into public domain. I agree to a large extent. I am just pointing out there are alternatives to copyright assignment, if people don't want to do that, especially when it comes to changes to an existing GPL program. -- --Per Bothner per(a)bothner.com http://www.bothner.com/~per/

2 participants
1 comments

Re: RFC: xemacsweb - XEmacs vs. GNU Emacs 23 years, 6 months

Hrvoje Niksic

Valdis.Kletnieks(a)vt.edu writes: > 1) Placing code in the public domain means that you can no longer put > a "hold harmless" clause in as part of the copyright (i.e. you can't say > "by copying this software, you agree to not sue us if it breaks"). Thus, > if you put code in the public domain, you're liable to all sorts of legal > nasties if it causes a problem for somebody. Huh? Can this really be true? In that case, why would anyone put any piece of software under PD?

1 participants
0 comments

RE: (setq indent-tabs-mode nil) not working in 21.2b36 on NT? 23 years, 6 months

Troy Noble

More information. xemacs-21.2-b36.tar.gz built on RedHat 6.2 Linux with --pdump=yes exhibits the same problem. So it doesn't seem to be germaine to the win32 port of pdump, but is more at the core of pdump I would suspect. I did set a trace-style breakpoint on indent_tabs_mode, and found that (on win32) it gets set once in the following place when the pdump loads. But it never again gets set throughout the lifetime of the XEmacs session. dumper.c, Line 1040: /* Put back the opaques */ for (i=0; i<((dump_header *)pdump_start)->nb_opaquedmp; i++) { struct pdump_dumpopaqueinfo di = PDUMP_READ (p, struct pdump_dumpopaqueinfo); > memcpy (di.data, p, di.size); p += di.size; } Don't know what that means for sure, I suppose I could crawl in and learn how the portable dumper works... if time permits. If I compile without pdump, every time I (setq indent-tabs-mode ...), I get a breakpoint on watch at the following location. Never did get here when running with pdump enabled though. It's almost like once the pdump data gets loaded, XEmacs "forgets" how to set indent_tabs_mode. Suspect that's true of other DEVFAR's too, in which case this is a much bigger problem than just indent-to not working. symbols.c, Line 1259: case SYMVAL_BOOLEAN_FORWARD: if (magicfun) magicfun (sym, &newval, Qnil, 0); *((int *) symbol_value_forward_forward (fwd)) > = !NILP (newval); return; -----Original Message----- From: Troy Noble [mailto:troy.noble＠channelpoint.com] Sent: Sunday, October 22, 2000 7:32 PM To: 'sperber(a)informatik.uni-tuebingen.de'; Adrian Aichner Cc: Troy Noble; 'xemacs-beta(a)xemacs.org'; 'xemacs-nt(a)xemacs.org' Subject: RE: (setq indent-tabs-mode nil) not working in 21.2b36 on NT? >>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes: >>>>> "sperber" == sperber(a)informatik.uni-tuebingen.de <sperber(a)informatik.uni-tuebingen.de> writes: sperber> Sure sounds like the pdump bug we've known about for ages. Of course, sperber> we need to know if you're using pdump to be sure. Mike, It does indeed appear to be a problem with pdump. Once I enabled USE_PORTABLE_DUMPER=1 The one I compiled started exhibiting the same behavior as the 21.2b36 binary I downloaded off the net. If I breakpoint at src/indent.c line 317, the debugger reports indent_tabs_mode = 1, even though describe-variable indent-tabs-mode indicates the value is "nil". That is indeed consistent with the behavior I'm seeing (it is incorrectly inserting tabs instead of spaces). APA> we need a lot more info. That's how problems can get solved: facts. Adrian, Apologies for not providing more information. I've not contributed bug reports to xemacs list before, so am kinda new at this. APA> How did you get the sources (CVS or tarballs)? I used the xemacs-21.2-b36.tar.gz tarball. This same problem has been reported since b34, so I know it's somewhat long-standing. If the pdump bug has been around a long time, that would explain it. APA> So you did a Windows native build, right? Yes, win32 native GUI... no X support... using MSVC 5.0, not cygwin. APA> Please send us your xemacs/nt/config.inc file then. My nt/config.inc included below. I took a pretty simple-minded approach and put all the .h and .lib files for all the aux libraries in the same directory. Seemed to work OK. APA> Did you use the portable dumper option (we can tell from config.inc)? Not originally. And my .exe worked fine But once I followed Mike's suggestion and turned use of pdump on, the problem re-appeared with the version I compiled too. I would be willing to troubleshoot further if someone could point the way, but as I said.. I'm kinda new at this, so not sure how much progress I'd make. APA> These are just a few simple question on the way to solve the mystery. Thanks for the feedback. Where should I go from here? Troy nt/config.inc: --------------------------------- snip

1 participants
0 comments

Re: RFC: xemacsweb - XEmacs vs. GNU Emacs 23 years, 6 months

Per Bothner

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Per> The standard assignment has this clause: > > Per> Upon thirty days' prior written notice, the Foundation > Per> agrees to grant me non-exclusive rights to use the Work ... > > I just asked a lawyer, what, if anything, this clause means. He > hasn't replied yet. It is not clear to me whether "use" would allow > redistribution under another license without the FSF's explicit > participation, since licensing is evidently a power of the copyright > holder. I think "use as I see fit" would allow that. I also think if you or your company's lawyer (I am writing generically) find the wording ambiguous, then rewrite it! If you want to add or re-write a clause, then there is no rule against that. (It would slow the procces down, though.) > Per> There are other options. For example, you can "disclaim" > Per> copyright - i.e. sign a statement that you're putting your > Per> changes into the public domain. > > Not a profit-oriented corporation. A corporation has a fiduciary > responsibility to its stockholders. Using GPL, you can argue you've > discharged that obligation by the usual ESR-style arguments about > efficacy of open-source development, but disclaiming copyright is > simply destroying corporate assets. Nonsense. Corporations assign/give code to organizations that release the code under very unrestrictive licenses, which are pretty darn close to public domain. The minor "fiduciary" advantage of using (say) a MIT-style license or some BSD variant over public demain is minor and one could argue that there are compensating advantages to using public domain: It is simpler, and hence saves expensive lawyer and manager time. It is also better understood legally. Corporations also donate to charities all the time, which would also seem to kill your "fiduciary responsibility" argument. > It is true that the FSF is restricted from enforcing proprietary > licenses themselves, but they could abandon the Work to the public > domain, which would have the same effect of permitting proprietary > improvements to the code. I'll go along with the concern as being valid. However, Ben wrote: some evil corporate identity [could] revoke the GPL and enforce any license they please. That I believe is not a valid issue. -- --Per Bothner per(a)bothner.com http://www.bothner.com/~per/

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