August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

pcl-cvs fork in the road 24 years, 8 months

Charles G Waldman

I have a simple patch to fix an annoying bug in pcl-cvs - in particular, if you hit `a'to do a cvs add, then, prior to committing, hit `g' to update the *cvs* buffer, you get a bunch of parser errors, coming from the lines Working revision: New file! Repository revision: No revision control file which the pcl-cvs parser does not know how to handle (it's looking for a regexp which must include numeric chars). While this turns out to be quite easy to fix, I also see that Stefan Monnier has been churning out updates to pcl-cvs, and is now up to 2.9.6. While he says his package works with XEmacs, it requires some minor tweaking to actually use it (e.g. some missing `requires', adding the non-bundled file "easy-mmode.el", fixing up autoloads, adding a package-info file, etc). It does not take too much work to make this into a valid XEmacs package. So my question is, should I submit the patches to fix bugs in the R-2_0-Beta_2 version that we ship, or should I submit patches to sync our pcl-cvs package with Stefan Monnier's 2.9.6 substantially reworked 2.9.6 version?

1 participants
0 comments

Re: Viva la muerte! 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Has anyone tried to compile and run XEmacs with and without aliasing > and with and without union type to see if it works? Yes/No. I tried gcc-2.95 no-mule with the default options, without union type and it works (I am running it now). However that doesn't mean much. Ulrich Drepper just reported a crash in a Mule enabled XEmacs, on the assert on line 364 of insdel.c. I am not saying it is related but above it is exactly the type code that typically breaks. (Using longs to "parallelize" char operations). Jan

1 participants
0 comments

This is not pixel-based scrolling .... 24 years, 8 months

Andy Piper

... because that would be way slow. But I think its close to what people want. Only vertical scrolling implemented so far. This is not an official patch, just a preview so people can play if they want. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: xemacs source code HOWTO ? 24 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > > > Have you tried `C-c C-e' in C mode? > > > > No. One is never too old to learn :-). True. :-) I use it all the time. The only thing that irks me about C-c C-e is that it invokes cpp and thus goes all the way. This is irritating in XEmacs sources where many macros call other macros, and it is often the case that I don't want to see the fully expanded blob. I'd like a tool able to expand one layer of C macros at a time.

1 participants
0 comments

Re: <ndbm.h> missing 24 years, 8 months

Karl Kleinpaste

I mentioned this on 12 Aug in <vxkg11orgxm.fsf(a)beaver.jprc.com>. My interim solution was to export CPATH=/usr/include/db1 to make sure that both configure and gcc could find ndbm.h. This is a glibc2.1 issue, due to db2's arrival.

1 participants
0 comments

Viva la muerte! 24 years, 8 months

Hrvoje Niksic

My Debian upgrade greeted me with this: As of gcc-2.95, optimisation at level 2 (-O2) and higher includes an optimisation which breaks C code that does not adhere to the C standard. Such code occurs in the Linux kernel, and probably other places. To compile the kernel (and probably other packages) with -O2 or better optimisation, you need to add '-fno-strict-aliasing' to the compile line (e.g. the CFLAGS settings in ...linux/Makefile). Before submitting a bug report for gcc, check if the package compiles with this flag added. If yes, submit a bug report for the package. More information can be found in /usr/share/doc/gcc/README.Debian.gz [Press RETURN to continue] Has anyone tried to compile and run XEmacs with and without aliasing and with and without union type to see if it works?

2 participants
1 comments

Re: web site access mechanisms (was _real_ long subject) 24 years, 8 months

john s jacobs anderson

[ ...and this is Stephen's reply back to me. *To be perfectly clear:* This message, while it appears to be from John S Jacobs Anderson <jacobs(a)azstarnet.com> is actually from Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp>. Sorry for any confusion. jsja] As far as I can tell the message I received was a private reply to me, only. Was that your intent? If not, feel free to borrow what ever you find useful from this message (or repost it to the list, for that matter). >>>>> "john" == john s jacobs anderson <jacobs(a)azstarnet.com> writes: "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: john> Is there somewhere this 'Review Board' business is john> explained? I've seen it referred to a couple of times and I john> gather it's basically the XEmacs Cabal (there is no john> cabal). Is this correct? No. There is a Review Board. It is implemented as a closed mailing list, xemacs-review(a)xemacs.org. The members are the "brought to you by" list, more or less. They also have CVS commit access to the entire source tree. The procedure of operation is not clear to outsiders, nor to members, I suspect, but members do seem to have the right to "veto" a patch they don't like. Overriding a veto would presumably get messy; I don't think there is a standard procedure. When the board first was formed, there were a couple of patch wars where a given patch flipped in and out of the code base every few hours. (It wasn't as bad as it sounds, there were real changes to the patch each time. But the parties were, ah, ideologically motivated to find problems with the opposite solution. IIRC, the patches were never commited, it was just "I veto" "I resubmit and override your veto" back and forth, although there were threats to actually commit a patch while the other guys were asleep.) Membership is by invitation from the Cabal^H^H^H^H^HReview Board. john> That is, a person _ultimately_ (but not necessarily john> _personally_) responsible This is a principle that should be observed more throughout. john> It seems like having someone do this type of stuff would be john> another step towards getting more developer time towards john> development. Tiggers bounce, developers code. That's what they do. The problem is that we need to get some (probably non-developers) the responsibility for the Information Ministry (how Stalinist! ;-), and the authority (including commit access and xemacs-review membership) needed to make it work. We had a massive battle over ChangeLog entries. The forces of Right won (no changelog, the patchbot rejects your submission out of hand with a polite message about the need for a ChangeLog entry). I think the Information ministry probably ought to be notified of UI and API changes (things that should go into NEWS). Developers are going to like that even less, because it's harder to write up. Viz the package mess. >> Yes, I wonder about whether it will cause drag on design >> operations. Remember, XEmacs's directory structure changes >> only slowly, but we can expect that the Web site's directory >> structure will change fairly often, at least for a while. john> Actually, the directory structure is going to change as john> little as I can help it, (from what it is right now). I've john> seen ump-teen links to www.xemacs.org during my link john> gathering expeditions, which was why the old mess of content john> is still there -- so those links don't break. OK, well that's good then. One obstacle to CVS down. john> Yes, that's a good place to send stuff that needs to go john> up. I plan on 24 to 48 hour turnaround for any and all john> submissions; just send it. Don't worry about HTML if you john> don't want to, I can do that easily too. I don't recommend you go there; submissions should be patches on existing files. We want to know who wrote what, so that if something uninterpretable gets out there, we know who to ask. We want to be able to revert to previous history if a design change just doesn't work out. That's where CVS helps. john> Of course, if you've got access, feel free to do it john> yourself, also. Send me a note and let me know, or at least john> modify the comments in the page header. (Add another <META john> type="author"> tag.) Write some standards. Make your job easy. If somebody sends you something, and you want to make an exception because "somebody" is your mother, feel free. If you really feel guilty, write a mode (but there are already several good HTML-editing modes). But the developers are used to coding to standard, and most people who are willing to submit doc patches probably would be too. Things like the <META TYPE="author"> tag. And how to do it. Commenting style. Etc. john> Files aren't going to move. OK. john> I guess the Review Board would get updates for file adds and john> file mods, too, but do they care? If they have commit authority on the documentation base, and they probably should. These are the people doing things like implementing the package system, porting to Win32 APIs, etc. They're the logical people to write the first big drafts of documentation for those. I recently wrote a book with 3 other authors, and having it under CVS really helped. I could see who committed when, and what they committed. I felt much less defensive about letting people edit my chapters. "Last patch wins" and I knew how to revert to "my" version. john> We've already got the submission/confirmation part (mail john> webmaster(a)xemacs.org stuff, I (or somebody else) posts it, john> we tell you it's posted). The only advantage to CVS would be john> (1) maintaining a local 'source' tree for the web site and john> (2) making sure two people weren't editing the file at the john> same time. john> Is that worth the effort, or is there something I'm missing? Well, I think that for packages and other add-ons, individual maintainers should have direct access to the Web site. I argued above for review board access. I think that access will be (or evolve that way) narrow enough to work, but broad enough that submission/confirmation will be a pain in the neck for the Webmaster. I think that having the history of changes is a good thing. I think it's worth it; we (somebody on the list) know how to implement it. It shouldn't impose too much on you, until it's actually ready to fly. It is possible to check for things like "author tags" in CVS. It should even be possible to demand that the submitter have a tag corresponding to him in the file (take a little work, that). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." -- ------------------------------------------------------------------------ John S Jacobs Anderson Apprentice Geek jacobs(a)azstarnet.com Journeyman Molecular Biologist <URL:http://www.treefort.org/~jacobs/> <- GeneHack:bioinfo*linux*opinion

2 participants
1 comments

Re: <ndbm.h> missing 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I understand too little of what's going on in database.c to provide a > good fix, though. The best fix would probably to finally port the database support to db2. Jan

1 participants
0 comments

Re: xemacs source code HOWTO ? 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Have you tried `C-c C-e' in C mode? > No. One is never too old to learn :-). (it's algorithm to find cpp breaks down completely here though.) Jan

1 participants
0 comments

Re: Layout support + widget fixes 24 years, 8 months

Jan Vroonhof

Andy Piper <andyp(a)san-jose.beasys.com> writes: > You can't search normal dialogs. And that is actually a big problem some times. I have often wanted to just that. I don't want this now because it will probably be very hard to implement, I am just thinking about ways that allow it in the future. Jan

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 August 1999