* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
@ 2009-12-09 4:39 ` Juanma Barranquero
2009-12-09 11:33 ` Eli Zaretskii
2009-12-09 9:14 ` Giovanni Lanzani
` (5 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-09 4:39 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
On Wed, Dec 9, 2009 at 03:54, Chong Yidong <cyd@stupidchicken.com> wrote:
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
> Pretesters: please send me an email reporting success or failure on your
> build platform.
I've tried both building and bootstrapping the tar.gz file on
Windows 7 Home Edition (build 7600)
compiling with
gcc.exe (TDM-2 mingw32) 4.4.1-dw2
Building works fine.
Bootstrapping does not compile the *.el files in the subdirs under
lisp/cedet/semantic/; a subsequent "make cvs-update install" fixes it.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 4:39 ` Juanma Barranquero
@ 2009-12-09 11:33 ` Eli Zaretskii
2009-12-09 12:46 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2009-12-09 11:33 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: cyd, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 9 Dec 2009 05:39:02 +0100
> Cc: emacs-devel@gnu.org
>
> Bootstrapping does not compile the *.el files in the subdirs under
> lisp/cedet/semantic/; a subsequent "make cvs-update install" fixes it.
Doesn't compile because the *.elc files are already there and
"bootstrap-clean" does not remove them, or doesn't compile because it
wasn't told to do so, even if *.elc supplied with the tarball are
removed?
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 11:33 ` Eli Zaretskii
@ 2009-12-09 12:46 ` Juanma Barranquero
2009-12-09 20:46 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-09 12:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, emacs-devel
On Wed, Dec 9, 2009 at 12:33, Eli Zaretskii <eliz@gnu.org> wrote:
> Doesn't compile because the *.elc files are already there and
> "bootstrap-clean" does not remove them, or doesn't compile because it
> wasn't told to do so, even if *.elc supplied with the tarball are
> removed?
Sorry, I didn't really made myself clear here.
The *.elc for lisp/cedet/semantic/*/*.el files are in the tarball.
The .BAT script that I use to bootstrap Emacs starts by cleaning the
source dir, removing *.elc, *.o, etc. I'm using the realclean target
etc., though after the switch I'll use "bzr clean-tree --unknown
--ignored --detritus"; the intent is having a clean checkout.
After that,
cd nt
configure
make bootstrap
make install
does not compile the semantic/*/*.el files.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 12:46 ` Juanma Barranquero
@ 2009-12-09 20:46 ` Chong Yidong
2009-12-09 20:50 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 20:46 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> Sorry, I didn't really made myself clear here.
>
> The *.elc for lisp/cedet/semantic/*/*.el files are in the tarball.
>
> The .BAT script that I use to bootstrap Emacs starts by cleaning the
> source dir, removing *.elc, *.o, etc. I'm using the realclean target
> etc., though after the switch I'll use "bzr clean-tree --unknown
> --ignored --detritus"; the intent is having a clean checkout.
>
> After that,
>
> cd nt
> configure
> make bootstrap
> make install
>
> does not compile the semantic/*/*.el files.
One possibility is that the Makefile in the tarball doesn't compile the
semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
after the tarball was made, fixes this. Dunno why the problem doesn't
show up on GNU/Linux, though.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:46 ` Chong Yidong
@ 2009-12-09 20:50 ` Juanma Barranquero
2009-12-09 21:00 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-09 20:50 UTC (permalink / raw)
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
On Wed, Dec 9, 2009 at 21:46, Chong Yidong <cyd@stupidchicken.com> wrote:
> One possibility is that the Makefile in the tarball doesn't compile the
> semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
> after the tarball was made, fixes this. Dunno why the problem doesn't
> show up on GNU/Linux, though.
I don't think Makefile.in is involved in this; likely a problem with
the Windows-specific makefile.w32-in.
The problem, BTW, has surely been happening for a while on the trunk;
we just didn't notice until now.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:50 ` Juanma Barranquero
@ 2009-12-09 21:00 ` Chong Yidong
2009-12-09 21:08 ` Glenn Morris
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 21:00 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> On Wed, Dec 9, 2009 at 21:46, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> One possibility is that the Makefile in the tarball doesn't compile the
>> semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
>> after the tarball was made, fixes this. Dunno why the problem doesn't
>> show up on GNU/Linux, though.
>
> I don't think Makefile.in is involved in this; likely a problem with
> the Windows-specific makefile.w32-in.
>
> The problem, BTW, has surely been happening for a while on the trunk;
> we just didn't notice until now.
Then I am confused as to why "make cvs-update install" would fix the
problem.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:00 ` Chong Yidong
@ 2009-12-09 21:08 ` Glenn Morris
2009-12-09 21:45 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Glenn Morris @ 2009-12-09 21:08 UTC (permalink / raw)
To: Chong Yidong; +Cc: Juanma Barranquero, Eli Zaretskii, emacs-devel
Chong Yidong wrote:
> Then I am confused as to why "make cvs-update install" would fix the
> problem.
I think WINS_CEDET_SUBDIRS is missing from the list of directories to
compile (WINS_ALMOST) in lisp/makefile.w32-in.
cvs-update runs recompile which uses batch-byte-recompile-directory,
so compiling the files in a different way.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:08 ` Glenn Morris
@ 2009-12-09 21:45 ` Chong Yidong
2009-12-10 0:45 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 21:45 UTC (permalink / raw)
To: Glenn Morris; +Cc: Juanma Barranquero, Eli Zaretskii, emacs-devel
Glenn Morris <rgm@gnu.org> writes:
> Chong Yidong wrote:
>
>> Then I am confused as to why "make cvs-update install" would fix the
>> problem.
>
> I think WINS_CEDET_SUBDIRS is missing from the list of directories to
> compile (WINS_ALMOST) in lisp/makefile.w32-in.
>
> cvs-update runs recompile which uses batch-byte-recompile-directory,
> so compiling the files in a different way.
You're right, of course. Juanma, could you test this change and see if
it does the right thing?
*** emacs/lisp/makefile.w32-in.~1.101.~ 2009-11-20 09:20:56.000000000 -0500
--- emacs/lisp/makefile.w32-in 2009-12-09 16:44:40.000000000 -0500
***************
*** 89,97 ****
cedet \
cedet/ede \
cedet/semantic \
! cedet/srecode
!
! WINS_CEDET_SUBDIRS=\
cedet/semantic/analyze \
cedet/semantic/bovine \
cedet/semantic/decorate \
--- 89,95 ----
cedet \
cedet/ede \
cedet/semantic \
! cedet/srecode \
cedet/semantic/analyze \
cedet/semantic/bovine \
cedet/semantic/decorate \
***************
*** 118,137 ****
textmodes \
url
! # Directories with lisp files to compile
! WINS_ALMOST=$(WINS_BASIC) \
$(WINS_CEDET)
- # Directories to extract data from (customs, autoloads, etc.)
- WINS_UPDATES=$(WINS_ALMOST) \
- $(WINS_CEDET_SUBDIRS)
-
# Directories to add to subdirs.el
WINS_SUBDIR=$(WINS_BASIC) \
obsolete
! # All directories, except CEDET subdirs
! WINS= $(WINS_ALMOST) \
term \
obsolete
--- 116,132 ----
textmodes \
url
! # Directories with lisp files to compile, and to extract data from
! # (customs, autoloads, etc.)
! WINS_UPDATES=$(WINS_BASIC) \
$(WINS_CEDET)
# Directories to add to subdirs.el
WINS_SUBDIR=$(WINS_BASIC) \
obsolete
! # All directories
! WINS= $(WINS_UPDATES) \
term \
obsolete
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:45 ` Chong Yidong
@ 2009-12-10 0:45 ` Juanma Barranquero
2009-12-11 16:48 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-10 0:45 UTC (permalink / raw)
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
On Wed, Dec 9, 2009 at 22:45, Chong Yidong <cyd@stupidchicken.com> wrote:
> You're right, of course. Juanma, could you test this change and see if
> it does the right thing?
Yes, apparently so, though you'll have to remove also the references
to WINS_CEDET_SUBDIRS in targets bootstrap-clean-CMD and
boostrap-clean-SH.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 0:45 ` Juanma Barranquero
@ 2009-12-11 16:48 ` Chong Yidong
2009-12-11 16:58 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-11 16:48 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> On Wed, Dec 9, 2009 at 22:45, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> You're right, of course. Juanma, could you test this change and see
>> if it does the right thing?
>
> Yes, apparently so, though you'll have to remove also the references
> to WINS_CEDET_SUBDIRS in targets bootstrap-clean-CMD and
> boostrap-clean-SH.
OK, I've checked the corrected fix into CVS. Could you check if it
works?
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 16:48 ` Chong Yidong
@ 2009-12-11 16:58 ` Juanma Barranquero
0 siblings, 0 replies; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-11 16:58 UTC (permalink / raw)
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
On Fri, Dec 11, 2009 at 17:48, Chong Yidong <cyd@stupidchicken.com> wrote:
> OK, I've checked the corrected fix into CVS. Could you check if it
> works?
The change you've committed is the one I already tested (including the
missing fixes in the bootstrap-clean-* targets). Also, I bootstrap
quite often, so any trouble should be evident before the next pretest
release.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
2009-12-09 4:39 ` Juanma Barranquero
@ 2009-12-09 9:14 ` Giovanni Lanzani
2009-12-09 17:14 ` Jan Djärv
2009-12-09 12:11 ` Andreas Schwab
` (4 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Giovanni Lanzani @ 2009-12-09 9:14 UTC (permalink / raw)
To: emacs-devel; +Cc: ulissesroc
Chong Yidong <cyd@stupidchicken.com> writes:
> Emacs pretest 23.1.90 is now available for download via FTP, at the
> following location:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>
> The xdelta against Emacs 23.1 is here:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform. Report bugs via M-x report-emacs-bugs, or email
> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>
> Note that the default for `mail-user-agent' has been changed from Mail
> mode to Message mode; if you have Mail mode-specific customizations,
> please check them.
>
> There are quite a number of changes relative to Emacs 23.1, including
> several new packages, notably the CEDET package of development tools.
> See etc/NEWS for details.
>
I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
following
./configure --with-ns
make install
But it ends with the error
Undefined symbols:
"_xg_select", referenced from:
_wait_reading_process_output in process.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make: *** [src] Error 2
Cheers
Giovanni
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 9:14 ` Giovanni Lanzani
@ 2009-12-09 17:14 ` Jan Djärv
[not found] ` <95bd41770912090936x26bdf529n4f54ce42729c8876@mail.gmail.com>
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 17:14 UTC (permalink / raw)
To: Giovanni Lanzani; +Cc: emacs-devel
Can you send us config.log? In the meantime, try adding --without-dbus (just
a guess).
Jan D.
Giovanni Lanzani skrev 2009-12-09 10.14:
> Chong Yidong<cyd@stupidchicken.com> writes:
>
>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>> following location:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>
>> The xdelta against Emacs 23.1 is here:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform. Report bugs via M-x report-emacs-bugs, or email
>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>
>> Note that the default for `mail-user-agent' has been changed from Mail
>> mode to Message mode; if you have Mail mode-specific customizations,
>> please check them.
>>
>> There are quite a number of changes relative to Emacs 23.1, including
>> several new packages, notably the CEDET package of development tools.
>> See etc/NEWS for details.
>>
>
> I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
> following
>
> ./configure --with-ns
> make install
>
> But it ends with the error
>
> Undefined symbols:
> "_xg_select", referenced from:
> _wait_reading_process_output in process.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[1]: *** [temacs] Error 1
> make: *** [src] Error 2
>
>
> Cheers
>
> Giovanni
>
>
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
2009-12-09 4:39 ` Juanma Barranquero
2009-12-09 9:14 ` Giovanni Lanzani
@ 2009-12-09 12:11 ` Andreas Schwab
2009-12-09 14:35 ` Chong Yidong
2009-12-09 18:39 ` Steven Knight
` (3 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 12:11 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
Please make sure loaddefs.el (and ldefs-boot.el) is up-to-date. The
included loaddefs.el lacks all autoloads from tool-bar.el, for example.
Also, please update your tree before tagging the it, the
EMACS_PRETEST_23_1_90 tag lacks the last change from Stefan before your
checkin.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 12:11 ` Andreas Schwab
@ 2009-12-09 14:35 ` Chong Yidong
2009-12-09 15:48 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 14:35 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Please make sure loaddefs.el (and ldefs-boot.el) is up-to-date. The
> included loaddefs.el lacks all autoloads from tool-bar.el, for example.
That's odd. A `make autoloads' does not regenerate the autoloads from
tool-bar.el, either.
> Also, please update your tree before tagging the it, the
> EMACS_PRETEST_23_1_90 tag lacks the last change from Stefan before your
> checkin.
Unfortunately, this kind of thing tends to happen in first pretests when
people try to squeeze stuff in at the last minute as I'm rolling the
tarball.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 14:35 ` Chong Yidong
@ 2009-12-09 15:48 ` Andreas Schwab
2009-12-09 18:52 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 15:48 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> Unfortunately, this kind of thing tends to happen in first pretests when
> people try to squeeze stuff in at the last minute as I'm rolling the
> tarball.
You can avoid that if you use cvs rtag.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 15:48 ` Andreas Schwab
@ 2009-12-09 18:52 ` Stefan Monnier
2009-12-09 20:07 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2009-12-09 18:52 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>> Unfortunately, this kind of thing tends to happen in first pretests when
>> people try to squeeze stuff in at the last minute as I'm rolling the
>> tarball.
> You can avoid that if you use cvs rtag.
I thought rtag was the problematic one. I always use `tag' instead, so
I know it tags exactly the files I'm seeing at the moment. Then you can
use that tag to export those exact same files to build a tarball, no
matter what else happens on the trunk in the mean time.
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:52 ` Stefan Monnier
@ 2009-12-09 20:07 ` Andreas Schwab
2009-12-09 21:18 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 20:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Unfortunately, this kind of thing tends to happen in first pretests when
>>> people try to squeeze stuff in at the last minute as I'm rolling the
>>> tarball.
>
>> You can avoid that if you use cvs rtag.
>
> I thought rtag was the problematic one. I always use `tag' instead, so
> I know it tags exactly the files I'm seeing at the moment.
The right way is to use rtag, then do a fresh checkout of that tag.
That's the only way to guarantee a consistent tag.
> Then you can use that tag to export those exact same files to build a
> tarball, no matter what else happens on the trunk in the mean time.
As you can see with the EMACS_PRETEST_23_1_90 tag, this can result in
the wrong revisions to be tagged. As a result the git tree is unable to
accurately represent that tag.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:07 ` Andreas Schwab
@ 2009-12-09 21:18 ` Stefan Monnier
2009-12-09 21:45 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2009-12-09 21:18 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>>>> Unfortunately, this kind of thing tends to happen in first pretests when
>>>> people try to squeeze stuff in at the last minute as I'm rolling the
>>>> tarball.
>>> You can avoid that if you use cvs rtag.
>> I thought rtag was the problematic one. I always use `tag' instead, so
>> I know it tags exactly the files I'm seeing at the moment.
> The right way is to use rtag, then do a fresh checkout of that tag.
> That's the only way to guarantee a consistent tag.
"consistent" in which sense?
>> Then you can use that tag to export those exact same files to build a
>> tarball, no matter what else happens on the trunk in the mean time.
> As you can see with the EMACS_PRETEST_23_1_90 tag, this can result in
> the wrong revisions to be tagged.
I really can't imagine why "tag" would be a problem. "tag" is suppose
to tag exactly the revisions of the files you have currently checked
out, so if those files are fine, so is your tag.
Luckily, I soon won't have to worry about such CVS idiosyncrasies
any more.
> As a result the git tree is unable to accurately represent that tag.
I can definitely imagine lots of cases where it might be very difficult
to represent tags properly when translating from CVS to something else,
regardless of how the tag was applied.
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:18 ` Stefan Monnier
@ 2009-12-09 21:45 ` Andreas Schwab
2009-12-09 21:56 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 21:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> "consistent" in which sense?
Consistent in time.
> I really can't imagine why "tag" would be a problem. "tag" is suppose
> to tag exactly the revisions of the files you have currently checked
> out, so if those files are fine, so is your tag.
That's exactly the problem. Your checked out files may be out of date
wrt. the repository.
> I can definitely imagine lots of cases where it might be very difficult
> to represent tags properly when translating from CVS to something else,
> regardless of how the tag was applied.
If you tag consistently there won't be any problem.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:45 ` Andreas Schwab
@ 2009-12-09 21:56 ` Stefan Monnier
2009-12-09 23:14 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2009-12-09 21:56 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>> I really can't imagine why "tag" would be a problem. "tag" is suppose
>> to tag exactly the revisions of the files you have currently checked
>> out, so if those files are fine, so is your tag.
> That's exactly the problem. Your checked out files may be out of date
> wrt. the repository.
"Out of date" in which sense? You mean, there might have been some
commits performed since? Of course, that's true, but it doesn't matter
because "tag" will use the revisions in your tree, which should all be
self-consistent. So it will be the same result as if "tag" was
performed (onsistently) when your file have been checked out
(i.e. before the checkins that may have happened in the mean time).
You can checkout, wait for a year, and then perform "tag", and it will
still be consistent.
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:56 ` Stefan Monnier
@ 2009-12-09 23:14 ` Andreas Schwab
2009-12-10 0:39 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 23:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I really can't imagine why "tag" would be a problem. "tag" is suppose
>>> to tag exactly the revisions of the files you have currently checked
>>> out, so if those files are fine, so is your tag.
>> That's exactly the problem. Your checked out files may be out of date
>> wrt. the repository.
>
> "Out of date" in which sense? You mean, there might have been some
> commits performed since?
No, there were some commits performed before!
> Of course, that's true, but it doesn't matter because "tag" will use
> the revisions in your tree, which should all be self-consistent.
But it is inconsistent with the One True Repository.
> You can checkout, wait for a year, and then perform "tag", and it will
> still be consistent.
But not consistent with a checkout by date.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 23:14 ` Andreas Schwab
@ 2009-12-10 0:39 ` Stefan Monnier
2009-12-10 0:45 ` Andreas Schwab
2009-12-10 2:33 ` Stephen J. Turnbull
0 siblings, 2 replies; 63+ messages in thread
From: Stefan Monnier @ 2009-12-10 0:39 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>>>> I really can't imagine why "tag" would be a problem. "tag" is suppose
>>>> to tag exactly the revisions of the files you have currently checked
>>>> out, so if those files are fine, so is your tag.
>>> That's exactly the problem. Your checked out files may be out of date
>>> wrt. the repository.
>>
>> "Out of date" in which sense? You mean, there might have been some
>> commits performed since?
> No, there were some commits performed before!
Before what?
Here's how the scenario I have in mind:
cvs update
...blabla build, glance at it, try it out, maybe make a tarball of it...
cvs tag
In what way can this be inconsistent with "the One True Repository"?
In what way is this going to be inconsistent with a checkout by date?
In what way could commits performed "before" affect the consistency?
Is this yet another CVS breakage of which I'm not aware?
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 0:39 ` Stefan Monnier
@ 2009-12-10 0:45 ` Andreas Schwab
2009-12-10 2:33 ` Stephen J. Turnbull
1 sibling, 0 replies; 63+ messages in thread
From: Andreas Schwab @ 2009-12-10 0:45 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> In what way is this going to be inconsistent with a checkout by date?
Compare EMACS_PRETEST_23_1_90 in CVS with EMACS_PRETEST_23_1_90 in git.
> Is this yet another CVS breakage of which I'm not aware?
It is improper use of CVS in a changeset oriented world of VCS.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 0:39 ` Stefan Monnier
2009-12-10 0:45 ` Andreas Schwab
@ 2009-12-10 2:33 ` Stephen J. Turnbull
2009-12-10 9:41 ` David Kastrup
1 sibling, 1 reply; 63+ messages in thread
From: Stephen J. Turnbull @ 2009-12-10 2:33 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, Andreas Schwab, emacs-devel
Stefan Monnier writes:
> Here's how the scenario I have in mind:
>
> cvs update
> ...blabla build, glance at it, try it out, maybe make a tarball of it...
> cvs tag
>
> In what way can this be inconsistent with "the One True Repository"?
As you know, CVS commits are not atomic. You are both wrong when you
write of "One True Repository." In CVS you simply cannot have a True
Repository in the sense of "true to the Emacs we want to build for
ourselves and distribute to others" without restricting commits to one
developer at a time.
> In what way is this going to be inconsistent with a checkout by date?
I don't know about your release process, but mine involves testing,
then bumping the version number in configure.ac and version.sh.in, and
putting a release herald in the ChangeLogs, then tagging. If this
happens:
cvs update
... I build build, test, bump
... concurrently, Stefan commits
cvs commit <exactly the version bump changes, assume no conflicts>
cvs tag
then the tag spans in time, but does not include, your commit, and in
that sense is inconsistent with checkout by date.
Andreas's procedure using rtag is prohibitively inconvenient, IMO,
because it involves either tagging an untested version or analysis of
changes by others *and* a full test run *after* the tag is created.
If using tag is "inconsistent with a dVCS world", well, what else is
new?
The right way to handle this in CVS IMO is to use "tag", accept the
date/tag inconsistencies for prereleases, and to prohibit commits by
anyone but the release engineer from "cvs update" to "cvs tag" for
public releases. In that case cvs tag is almost equivalent to cvs
rtag (at least in some versions of CVS there were anomolies having to
do with files that don't exist on the branch being tagged).
Again IMO CVS checkouts by date are only useful for bisection, usually
result in identifying a unique commit, and even if the best you can do
is isolate to a period of say 1 hour with a half-dozen commits, that's
not going to be any worse than (say) bisecting and coming up with the
multi-tty merge as the culprit. You take a diff and start bisecting
by hunks rather than by time.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 2:33 ` Stephen J. Turnbull
@ 2009-12-10 9:41 ` David Kastrup
2009-12-10 12:32 ` Stephen J. Turnbull
0 siblings, 1 reply; 63+ messages in thread
From: David Kastrup @ 2009-12-10 9:41 UTC (permalink / raw)
To: emacs-devel
"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> Stefan Monnier writes:
>
> > Here's how the scenario I have in mind:
> >
> > cvs update
> > ...blabla build, glance at it, try it out, maybe make a tarball of it...
> > cvs tag
> >
> > In what way can this be inconsistent with "the One True Repository"?
>
> As you know, CVS commits are not atomic. You are both wrong when you
> write of "One True Repository." In CVS you simply cannot have a True
> Repository in the sense of "true to the Emacs we want to build for
> ourselves and distribute to others" without restricting commits to one
> developer at a time.
>
> > In what way is this going to be inconsistent with a checkout by
> > date?
>
> I don't know about your release process, but mine involves testing,
> then bumping the version number in configure.ac and version.sh.in, and
> putting a release herald in the ChangeLogs, then tagging. If this
> happens:
>
> cvs update
> ... I build build, test, bump
> ... concurrently, Stefan commits
> cvs commit <exactly the version bump changes, assume no conflicts>
> cvs tag
>
> then the tag spans in time, but does not include, your commit, and in
> that sense is inconsistent with checkout by date.
Which is utterly uninteresting in every respect. The important thing is
that the version is tagged that has been tested and which is intended to
be released. Whether or not that tag can be represented as "state of
repository at a certain point of time" is not only irrelevant, but the
point is _exactly_ that one does not want to have some state of the
repository tagged, but the state that has been tested and approved as
_release_.
> Andreas's procedure using rtag is prohibitively inconvenient, IMO,
> because it involves either tagging an untested version or analysis of
> changes by others *and* a full test run *after* the tag is created.
> If using tag is "inconsistent with a dVCS world", well, what else is
> new?
Of course "inconsistent with a dVCS world" is completely nonsense. The
whole point of dVCS is that you tag what constitutes a version at _your_
local site. This tag does _not_ apply to anything in a central
repository that is not identical to the version at your local site.
> The right way to handle this in CVS IMO is to use "tag", accept the
> date/tag inconsistencies for prereleases, and to prohibit commits by
> anyone but the release engineer from "cvs update" to "cvs tag" for
> public releases.
I don't see why "state of the repository at time point x" is relevant
for anything.
--
David Kastrup
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (2 preceding siblings ...)
2009-12-09 12:11 ` Andreas Schwab
@ 2009-12-09 18:39 ` Steven Knight
2009-12-09 18:56 ` Jan Djärv
2009-12-09 19:01 ` David Robinow
` (2 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Steven Knight @ 2009-12-09 18:39 UTC (permalink / raw)
To: emacs-devel
On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
> Emacs pretest 23.1.90 is now available for download via FTP, at the
> following location:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>
> The xdelta against Emacs 23.1 is here:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform. Report bugs via M-x report-emacs-bugs, or email
> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>
> Note that the default for `mail-user-agent' has been changed from Mail
> mode to Message mode; if you have Mail mode-specific customizations,
> please check them.
>
> There are quite a number of changes relative to Emacs 23.1, including
> several new packages, notably the CEDET package of development tools.
> See etc/NEWS for details.
>
>
> Emacs developers: please note that the tree is now frozen. No new
> features are allowed, unless agreed to by Stefan or myself. Changes
> that are bug fixes or improvements to documentations may still be
> committed directly; when in doubt, send email to emacs-devel@gnu.org. I
> think we will probably begin Emacs 24 development soon-ish, once we make
> the switch from CVS to BZR (we can discuss this further on emacs-devel).
>
> Thanks.
>
>
>
Hi,
I built and installed Emacs on Fedora 11; I did not encounter any errors
when building.
When starting up Emacs, I get the following:
$ emacs -Q
(emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 0'
failed
and the computer emits a beep.
When doing this:
$ emacs -Q -nw
Emacs starts-ups fine.
Please let me know if I should be posting this somewhere else or if you
need more information.
Thanks,
--
Steven Knight
steven.knight@unh.edu
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:39 ` Steven Knight
@ 2009-12-09 18:56 ` Jan Djärv
2009-12-09 19:21 ` Steven Knight
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 18:56 UTC (permalink / raw)
To: steven.knight; +Cc: emacs-devel
Steven Knight skrev:
> On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>> following location:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>
>> The xdelta against Emacs 23.1 is here:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform. Report bugs via M-x report-emacs-bugs, or email
>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>
>> Note that the default for `mail-user-agent' has been changed from Mail
>> mode to Message mode; if you have Mail mode-specific customizations,
>> please check them.
>>
>> There are quite a number of changes relative to Emacs 23.1, including
>> several new packages, notably the CEDET package of development tools.
>> See etc/NEWS for details.
>>
>>
>> Emacs developers: please note that the tree is now frozen. No new
>> features are allowed, unless agreed to by Stefan or myself. Changes
>> that are bug fixes or improvements to documentations may still be
>> committed directly; when in doubt, send email to emacs-devel@gnu.org. I
>> think we will probably begin Emacs 24 development soon-ish, once we make
>> the switch from CVS to BZR (we can discuss this further on emacs-devel).
>>
>> Thanks.
>>
>>
>>
> Hi,
>
> I built and installed Emacs on Fedora 11; I did not encounter any errors
> when building.
>
> When starting up Emacs, I get the following:
>
> $ emacs -Q
>
> (emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 0'
> failed
>
> and the computer emits a beep.
>
> When doing this:
>
> $ emacs -Q -nw
>
> Emacs starts-ups fine.
>
> Please let me know if I should be posting this somewhere else or if you
> need more information.
>
What happens if you do
% emacs -Q -fn fixed
or if that fails
% emacs -Q -fn fixed -g 80x24
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:56 ` Jan Djärv
@ 2009-12-09 19:21 ` Steven Knight
2009-12-09 20:44 ` Jan Djärv
0 siblings, 1 reply; 63+ messages in thread
From: Steven Knight @ 2009-12-09 19:21 UTC (permalink / raw)
To: emacs-devel
On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
> Steven Knight skrev:
>> On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
>>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>>> following location:
>>>
>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>>
>>> The xdelta against Emacs 23.1 is here:
>>>
>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>>
>>> This is the first pretest for what will be the Emacs 23.2 release.
>>>
>>> Pretesters: please send me an email reporting success or failure on
>>> your
>>> build platform. Report bugs via M-x report-emacs-bugs, or email
>>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>>
>>> Note that the default for `mail-user-agent' has been changed from Mail
>>> mode to Message mode; if you have Mail mode-specific customizations,
>>> please check them.
>>>
>>> There are quite a number of changes relative to Emacs 23.1, including
>>> several new packages, notably the CEDET package of development tools.
>>> See etc/NEWS for details.
>>>
>>>
>>> Emacs developers: please note that the tree is now frozen. No new
>>> features are allowed, unless agreed to by Stefan or myself. Changes
>>> that are bug fixes or improvements to documentations may still be
>>> committed directly; when in doubt, send email to
>>> emacs-devel@gnu.org. I
>>> think we will probably begin Emacs 24 development soon-ish, once we
>>> make
>>> the switch from CVS to BZR (we can discuss this further on
>>> emacs-devel).
>>>
>>> Thanks.
>>>
>>>
>> Hi,
>>
>> I built and installed Emacs on Fedora 11; I did not encounter any
>> errors when building.
>>
>> When starting up Emacs, I get the following:
>>
>> $ emacs -Q
>>
>> (emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width >
>> 0' failed
>>
>> and the computer emits a beep.
>>
>> When doing this:
>>
>> $ emacs -Q -nw
>>
>> Emacs starts-ups fine.
>>
>> Please let me know if I should be posting this somewhere else or if
>> you need more information.
>>
>
> What happens if you do
> % emacs -Q -fn fixed
> or if that fails
> % emacs -Q -fn fixed -g 80x24
>
> Jan D.
>
>
>
Hi,
Using either of the above commands starts emacs without issue. How do I
resolve my issue without using the font fixed? Also I should have
mentioned that using emacs 23.1 I was to build and start emacs without
issue.
Thanks,
--
Steven Knight
steven.knight@unh.edu
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 19:21 ` Steven Knight
@ 2009-12-09 20:44 ` Jan Djärv
2009-12-09 21:20 ` Steven Knight
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 20:44 UTC (permalink / raw)
To: steven.knight; +Cc: emacs-devel
Steven Knight skrev 2009-12-09 20.21:
>> What happens if you do
>> % emacs -Q -fn fixed
>> or if that fails
>> % emacs -Q -fn fixed -g 80x24
>>
>> Jan D.
>>
>>
>>
> Hi,
>
> Using either of the above commands starts emacs without issue. How do I
> resolve my issue without using the font fixed? Also I should have
> mentioned that using emacs 23.1 I was to build and start emacs without
> issue.
>
First we need to find out what font you are trying to use. Can you start 23.1
that works and in *scratch* evaluate
(frame-parameter nil 'font)
and see what it returns?
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:44 ` Jan Djärv
@ 2009-12-09 21:20 ` Steven Knight
2009-12-11 7:47 ` Jan D.
0 siblings, 1 reply; 63+ messages in thread
From: Steven Knight @ 2009-12-09 21:20 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs-devel
On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
> First we need to find out what font you are trying to use. Can you
> start 23.1 that works and in *scratch* evaluate
>
> (frame-parameter nil 'font)
>
> and see what it returns?
>
> Jan D.
>
>
Hi,
You bet. I started emacs (using emacs -Q) and evaluated the above code.
Here is the result:
-unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
Thanks,
--
Steven Knight
steven.knight@unh.edu
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:20 ` Steven Knight
@ 2009-12-11 7:47 ` Jan D.
2009-12-11 14:50 ` Steven Knight
0 siblings, 1 reply; 63+ messages in thread
From: Jan D. @ 2009-12-11 7:47 UTC (permalink / raw)
To: steven.knight; +Cc: emacs-devel
On 2009-12-09 22:20, Steven Knight wrote:
> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>> First we need to find out what font you are trying to use. Can you
>> start 23.1 that works and in *scratch* evaluate
>>
>> (frame-parameter nil 'font)
>>
>> and see what it returns?
>>
>> Jan D.
>>
>>
>
> Hi,
>
> You bet. I started emacs (using emacs -Q) and evaluated the above code.
> Here is the result:
>
> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>
Hmm. I think you must debug this, I'm trying to figure out where.
Does starting with -fn Monospace-12 work?
Can you start gdb on emacs and set a breakpoint in
x_default_font_parameter? A session would look something like:
(gdb) b x_default_font_parameter
(gdb) r -Q
break in x_default_font_parameter
And then type n to step through and print out variables as they are
assigned:
(gdb) p font
(gdb) pr
and
(gdb) p system_font
I hope we find something here.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 7:47 ` Jan D.
@ 2009-12-11 14:50 ` Steven Knight
2009-12-11 15:03 ` Jan D.
2009-12-12 16:20 ` Jan Djärv
0 siblings, 2 replies; 63+ messages in thread
From: Steven Knight @ 2009-12-11 14:50 UTC (permalink / raw)
To: Jan D.; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
> On 2009-12-09 22:20, Steven Knight wrote:
>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>> First we need to find out what font you are trying to use. Can you
>>> start 23.1 that works and in *scratch* evaluate
>>>
>>> (frame-parameter nil 'font)
>>>
>>> and see what it returns?
>>>
>>> Jan D.
>>>
>>>
>>
>> Hi,
>>
>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>> Here is the result:
>>
>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>
>
> Hmm. I think you must debug this, I'm trying to figure out where.
> Does starting with -fn Monospace-12 work?
$ emacs -Q -fn Monospace-12
Arithmetic error
>
> Can you start gdb on emacs and set a breakpoint in
> x_default_font_parameter? A session would look something like:
> (gdb) b x_default_font_parameter
> (gdb) r -Q
> break in x_default_font_parameter
>
> And then type n to step through and print out variables as they are
> assigned:
> (gdb) p font
> (gdb) pr
>
> and
> (gdb) p system_font
>
I will do this and let you know.
I've attached a copy of my config.log file (bzipped). I am running
emacs-23.1.90 on a Fedora 11 system under KDE 4.3.3.
Thanks for all the help,
--
Steven Knight
steven.knight@unh.edu
[-- Attachment #2: config.log.bz2 --]
[-- Type: application/octet-stream, Size: 17158 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 14:50 ` Steven Knight
@ 2009-12-11 15:03 ` Jan D.
2009-12-12 16:20 ` Jan Djärv
1 sibling, 0 replies; 63+ messages in thread
From: Jan D. @ 2009-12-11 15:03 UTC (permalink / raw)
To: steven.knight; +Cc: emacs-devel
On 2009-12-11 15:50, Steven Knight wrote:
> On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
>> On 2009-12-09 22:20, Steven Knight wrote:
>>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>>> First we need to find out what font you are trying to use. Can you
>>>> start 23.1 that works and in *scratch* evaluate
>>>>
>>>> (frame-parameter nil 'font)
>>>>
>>>> and see what it returns?
>>>>
>>>> Jan D.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>>> Here is the result:
>>>
>>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>>
>>
>> Hmm. I think you must debug this, I'm trying to figure out where.
>> Does starting with -fn Monospace-12 work?
> $ emacs -Q -fn Monospace-12
> Arithmetic error
Wow, that was unexpected. I think I have to install Fedora 11 and KDE.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 14:50 ` Steven Knight
2009-12-11 15:03 ` Jan D.
@ 2009-12-12 16:20 ` Jan Djärv
2009-12-14 23:48 ` Steven Knight
1 sibling, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-12 16:20 UTC (permalink / raw)
To: steven.knight; +Cc: emacs-devel
Steven Knight skrev 2009-12-11 15.50:
> On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
>> On 2009-12-09 22:20, Steven Knight wrote:
>>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>>> First we need to find out what font you are trying to use. Can you
>>>> start 23.1 that works and in *scratch* evaluate
>>>>
>>>> (frame-parameter nil 'font)
>>>>
>>>> and see what it returns?
>>>>
>>>> Jan D.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>>> Here is the result:
>>>
>>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>>
>>
>> Hmm. I think you must debug this, I'm trying to figure out where.
>> Does starting with -fn Monospace-12 work?
> $ emacs -Q -fn Monospace-12
> Arithmetic error
>>
>> Can you start gdb on emacs and set a breakpoint in
>> x_default_font_parameter? A session would look something like:
>> (gdb) b x_default_font_parameter
>> (gdb) r -Q
>> break in x_default_font_parameter
>>
>> And then type n to step through and print out variables as they are
>> assigned:
>> (gdb) p font
>> (gdb) pr
>>
>> and
>> (gdb) p system_font
>>
> I will do this and let you know.
No need now.
>
> I've attached a copy of my config.log file (bzipped). I am running
> emacs-23.1.90 on a Fedora 11 system under KDE 4.3.3.
>
Thanks, I found the problem after installing Fedora 11 with KDE. Please test
again with an updated Emacs.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-12 16:20 ` Jan Djärv
@ 2009-12-14 23:48 ` Steven Knight
0 siblings, 0 replies; 63+ messages in thread
From: Steven Knight @ 2009-12-14 23:48 UTC (permalink / raw)
To: Jan Djärv; +Cc: emacs-devel
On 12/12/2009 11:20 AM Jan Djärv wrote:
>
> Thanks, I found the problem after installing Fedora 11 with KDE. Please
> test again with an updated Emacs.
>
> Jan D.
>
>
Hi,
I checkout emacs from cvs and built it; and it works! Thank you so much
for your help.
Thanks,
--
--------------------------------------------------------------------------------
Steven Knight steven.knight@unh.edu
-------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (3 preceding siblings ...)
2009-12-09 18:39 ` Steven Knight
@ 2009-12-09 19:01 ` David Robinow
2009-12-09 20:17 ` Chong Yidong
2009-12-14 4:59 ` Juanma Barranquero
2009-12-18 5:27 ` Drew Adams
6 siblings, 1 reply; 63+ messages in thread
From: David Robinow @ 2009-12-09 19:01 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Tue, Dec 8, 2009 at 9:54 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform.
nmake (VS2003) does not like {...} in makefile macros.
A few pairs seem to have crept in.
It builds fine on Windows XP Home with the attached patch.
[-- Attachment #2: makefile.w32.patches --]
[-- Type: application/octet-stream, Size: 1480 bytes --]
*** lib-src/makefile.w32-in.orig 2009-12-08 20:41:30.000000000 -0500
--- lib-src/makefile.w32-in 2009-12-09 09:56:23.375000000 -0500
***************
*** 191,202 ****
OTHER_PLATFORM_SUPPORT = \
$(lispsource)dos-fns.elc \
$(lispsource)dos-vars.elc \
! ${lispsource}term/internal.elc \
! ${lispsource}term/pc-win.elc \
$(lispsource)x-dnd.elc \
$(lispsource)term/x-win.elc \
! ${lispsource}emacs-lisp/easymenu.elc \
! ${lispsource}term/ns-win.elc
lisp1= \
--- 191,202 ----
OTHER_PLATFORM_SUPPORT = \
$(lispsource)dos-fns.elc \
$(lispsource)dos-vars.elc \
! $(lispsource)term/internal.elc \
! $(lispsource)term/pc-win.elc \
$(lispsource)x-dnd.elc \
$(lispsource)term/x-win.elc \
! $(lispsource)emacs-lisp/easymenu.elc \
! $(lispsource)term/ns-win.elc
lisp1= \
*** doc/lispintro/makefile.w32-in.orig 2009-10-28 10:20:50.000000000 -0400
--- doc/lispintro/makefile.w32-in 2009-12-09 09:53:25.453125000 -0500
***************
*** 54,60 ****
emacs-lisp-intro.dvi: $(INFO_SOURCES)
$(ENVADD) $(TEXI2DVI) $(srcdir)/emacs-lisp-intro.texi
! emacs-lisp-intro.pdf: ${INFO_SOURCES}
$(ENVADD) $(TEXI2PDF) $(srcdir)/emacs-lisp-intro.texi
emacs-lisp-intro.html: $(INFO_SOURCES)
--- 54,60 ----
emacs-lisp-intro.dvi: $(INFO_SOURCES)
$(ENVADD) $(TEXI2DVI) $(srcdir)/emacs-lisp-intro.texi
! emacs-lisp-intro.pdf: $(INFO_SOURCES)
$(ENVADD) $(TEXI2PDF) $(srcdir)/emacs-lisp-intro.texi
emacs-lisp-intro.html: $(INFO_SOURCES)
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 19:01 ` David Robinow
@ 2009-12-09 20:17 ` Chong Yidong
0 siblings, 0 replies; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 20:17 UTC (permalink / raw)
To: David Robinow; +Cc: emacs-devel
David Robinow <drobinow@gmail.com> writes:
> On Tue, Dec 8, 2009 at 9:54 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform.
>
> nmake (VS2003) does not like {...} in makefile macros.
> A few pairs seem to have crept in.
>
> It builds fine on Windows XP Home with the attached patch.
Thanks; applied.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (4 preceding siblings ...)
2009-12-09 19:01 ` David Robinow
@ 2009-12-14 4:59 ` Juanma Barranquero
2009-12-14 16:03 ` Chong Yidong
2009-12-18 5:27 ` Drew Adams
6 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-14 4:59 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
Non-obsolete python.el requires obsolete sym-comp.el, which produces a
warning "Package sym-comp is obsolete!" while loading python.el[c].
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-14 4:59 ` Juanma Barranquero
@ 2009-12-14 16:03 ` Chong Yidong
2009-12-14 16:20 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-14 16:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> Non-obsolete python.el requires obsolete sym-comp.el, which produces a
> warning "Package sym-comp is obsolete!" while loading python.el[c].
Stefan removed sym-comp usage from Python just before the pretest, but
left the (require 'sym-comp) statement in. Removing it fixes this.
But the new completion-at-point for Python is completely broken.
Consider the following recipe:
1. C-x C-f foo.py
2. i M-TAB
=> Emacs loops while completion-at-point is working, apparently without
any exit (I tried waiting for about a minute).
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-14 16:03 ` Chong Yidong
@ 2009-12-14 16:20 ` Chong Yidong
0 siblings, 0 replies; 63+ messages in thread
From: Chong Yidong @ 2009-12-14 16:20 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> Non-obsolete python.el requires obsolete sym-comp.el, which produces a
>> warning "Package sym-comp is obsolete!" while loading python.el[c].
>
> Stefan removed sym-comp usage from Python just before the pretest, but
> left the (require 'sym-comp) statement in. Removing it fixes this.
>
> But the new completion-at-point for Python is completely broken.
> Consider the following recipe:
>
> 1. C-x C-f foo.py
> 2. i M-TAB
>
> => Emacs loops while completion-at-point is working, apparently without
> any exit (I tried waiting for about a minute).
I found the problem: the code in Python was passing a string with text
property notation to the Python interpreter, confusing it. Should be
fixed in the repository now.
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (5 preceding siblings ...)
2009-12-14 4:59 ` Juanma Barranquero
@ 2009-12-18 5:27 ` Drew Adams
6 siblings, 0 replies; 63+ messages in thread
From: Drew Adams @ 2009-12-18 5:27 UTC (permalink / raw)
To: 'Chong Yidong', emacs-devel
Will a Windows binary be posted for the pretest?
Or has it been posted already?
I looked here, but don't see one:
http://alpha.gnu.org/gnu/emacs/pretest/windows/
^ permalink raw reply [flat|nested] 63+ messages in thread