viteno> After applying xemacs-21.4.4-21.4.5.patch to my existing viteno> source tree, I can't successfully compile Well, the CVS checkout, the full tarball, and patching up from 21.4.4 (from full tarball) all build fine for me. YMDidV :( viteno> Now, [struct window] doesn't have a member dedicated. It does. In src/winslots.h, included at src/window.h:196. viteno> Hints? I hope that helps, 'cause I can't figure out what might be going wrong. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Recapping as Ben and Nix probably haven't been following the thread: viteno> After applying xemacs-21.4.4-21.4.5.patch to my existing viteno> source tree, I can't successfully compile, because of gcc -c -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -W\ shadow -Wpointer-arith -Demacs -I. -DHAVE_CONFIG_H -I/client/include -I/usr/X1\ 1R6/include window.c window.c: In function `window_loop': window.c:2692: invalid operands to binary && gmake[1]: *** [window.o] Error 1 viteno> The source reads struct window *p = ...; case UNDEDICATE_BUFFER: { if ((XBUFFER (p->buffer) == XBUFFER (obj)) && (p->dedicated)) p->dedicated = Qnil; break; } I replied that it works for me. viteno> Oh well, so it must be connected to the configure options viteno> (sorry for not sending them in earlier). You probably should send the whole Installation file with the initial report. viteno> Ah, found the culprit. A configure run without viteno> --use-union-type leads to successfull compilation. Thanks. Reproduced. Patch: steve＠tleeps18:/var/tmp/XEmacs/xemacs-21.4.5$ diff -u src/window.c{~,} --- src/window.c~ Tue Oct 23 17:35:39 2001 +++ src/window.c Wed Oct 24 10:36:29 2001 ＠＠ -2689,7 +2689,8 ＠＠ case UNDEDICATE_BUFFER: { - if ((XBUFFER (p->buffer) == XBUFFER (obj)) && (p->dedicated)) + if ((XBUFFER (p->buffer) == XBUFFER (obj)) + && !NILP (p->dedicated)) p->dedicated = Qnil; break; } Ben, is the fix correct? Nix, if we're going to set to nil anyway, why is the !NILP needed? viteno> Still it's bug, IMHO. Should I file a report? You already did. Bug reports have been redirected to xemacs-beta anyway, as this is where the developers are most likely to see them. And we lost our bug database service anyway, it was hosted on cvs.xemacs.org. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Ben> also, stylistically it's better usually to say EQ (p->buffer, Yup. I guess if you spend enough time in the code, you eventually learn that XOJBECT macros are Lisp objects, but somehow the EQ idiom penetrates my brain immediately. Ben> obj). [i do see that the same idiom occurs elsewhere in the Ben> code. all should be changed.] OK, I'm not going to do that in 21.4, at least not until I've had some sleep and the probability of typos and pure brain damage subsides. :-) How is the Mule workspace coming? I will release a 21.5 in the next few days because it hasn't happened in a while and CVS is still down from the point of view of the testers. But after that, there's not that much activity in 21.5 right now. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

On 24 Oct 2001, Stephen J. Turnbull yowled: As Ben says, it isn't. It's historical cruft from the first version of the patch (the buggy one that dededicated all windows whenever you went down this code path, instead of just dededicating windows onto the buffer you were killing) and I should have zapped it. Oops. -- `You're the only person I know who can't tell the difference between a pair of trousers and a desk.' --- Kieran, to me