Emacs 23.0.95 pretest is available
Eli Zaretskii
http://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.95.tar.gz
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.95.tar.gz
I have just built it on my XP machine, and it seems to build and work
fine. However, I would appreciate if more people could give it a try
and report any problems they saw (or the lack thereof). In
particular, if someone could build and run it on plain DOS and report
the results, that would be most appreciated.
Thanks in advance.
Rugxulo
On Jun 27, 8:59 am, Eli Zaretskii <e...@gnu.org> wrote:
> Another pretest of Emacs 23.1 is available:
>
> http://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.95.tar.gz
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.95.tar.gz
>
> I have just built it on my XP machine, and it seems to build and work
> fine.
"make install" took approx. 4 1/2 mins. for me on my P4 (XP) although
I spent at least five hours today messing with this (trying to be
helpful, I know volunteers are few). However, on XP or FreeDOS, if
using GCC 2.95.3 (oldy moldy which I'm fond of), it seems to hang at
loadup.el (I think) unless --with-system-malloc is used. Also see the
note below about "top_srcdir" and "srcdir".
Anyways, briefly / lightly tested the "system malloc" build on XP and
Vista (e.g. loading 100 MB enwik8), and it seems to work correctly as
in previous versions.
------------------------------------------------
"Your file has been saved and can now be downloaded 10 times. It will
be deleted after 90 days without download"
1. Download Link: Click here to download file (39 MB)
http://rapidshare.com/files/249435775/emacs-23.0.95.7z.html
MD5: 30F44E396768AD40D6057FA453CA8080
------------------------------------------------
> However, I would appreciate if more people could give it a try
> and report any problems they saw (or the lack thereof).
"C-x 5 1" etc. (frames) seem to be giving problems (FreeDOS or Vista).
I don't use frames that much, so I'm not sure when that broke exactly.
> In
> particular, if someone could build and run it on plain DOS and report
> the results, that would be most appreciated.
I still don't have a decent DOS setup with 'Net access, so it's quite
awkward. But I did use a boot floppy (FreeDOS 2038 stable, FreeCOM
0.84-pre2), a small USB jump drive (64 MB total) which the BIOS
emualtes as a HD, plus a really big RAM drive (RDISK) to unpack and
build on. First of all, I tried with StarLFN (probably should've also
tried DOSLFN, but that's for another day), which slows everything down
way way WAY too much (and didn't work), so I decided to try without
any LFNs. Either way, Make (3.79.1 or 3.81) seemed to have problems
finding test-distrib.c, so I had to manually change Makefile
"top_srcdir" and lib-src/Makefile "srcdir" to point to "/dev/e/emacs"
and "/dev/e/emacs/lib-src", respectively, instead of the weird shell
hack that is trying to use "e:/emacs" instead (which doesn't work,
dunno why). Otherwise, it seems to build okay and works (doctor,
tetris, gomoku, C-x b, menus) except for frames (all OSes) and "C-x
i" (can't find Info dir in FreeDOS w/ SFNs, but Vista w/ LFNs works
okay). I also tried with 3.4.4 for laughs just in case some of it was
GCC version specific, but no apparent differences (well, no silly
alignment warnings, 2.95.3 says "... too much, defaulting to 4 " a
lot) beyond a slightly bigger .EXE (well, and the above loadup issue
which 3.4.4 doesn't have, but it doesn't have 8-byte alignment either,
so the above download is using GCC 4.4.0).
I should've probably tested some Leim stuff (E-o), but I didn't get
around to that this time. I just blindly assume it still works. Then
again, now that I've built it, it won't be hard rebooting to try real
DOS since a 40 MB .7z will actually fit on my jump drive.
Oh, and just in case you're really curious, I did try building a
previous alpha the other day once I upgraded to SP2, no luck (and no
surprise). So Vista (NT 6.0) still won't build it correctly. Win 7 (NT
6.1) -> Oct. 22, get ready! (Blargh.) I think MS gives free updates
for it in the U.S. for any computer bought on or after June 26th. I'm
already tired of hearing about it. :-/
Eli Zaretskii
> Date: Sat, 27 Jun 2009 19:41:56 -0700 (PDT)
>
> "make install" took approx. 4 1/2 mins.
Is it good or bad?
If bad, what part took most of the time?
> However, on XP or FreeDOS, if using GCC 2.95.3 (oldy moldy which I'm
> fond of), it seems to hang at loadup.el (I think)
What do you see if you interrupt it at this stage (you will need to
run it under GDB for this to work).
> "C-x 5 1" etc. (frames) seem to be giving problems (FreeDOS or Vista).
Ouch! Thanks for reporting this, patch to fix it below.
> Either way, Make (3.79.1 or 3.81) seemed to have problems
> finding test-distrib.c
Please show the signs of these problems.
> instead of the weird shell hack that is trying to use "e:/emacs"
> instead
Sorry, I don't follow: what weird hack, and why does it use e:/emacs?
> "C-x i" (can't find Info dir in FreeDOS w/ SFNs, but Vista w/ LFNs works
> okay).
I believe you mean "C-h i".
Do you have INFOPATH set on any of these machines? Please look in
djgpp.env: it sets things up so that Emacs expects to find the Info
files that come with Emacs in %DJDIR%/gnu/emacs/info; if you installed
Emacs in some other directory, you will need to set INFOPATH to point
to its `info' subdirectory.
If all of this does not help, please show your value of the variable
Info-directory-list after you type "C-h i".
> I also tried with 3.4.4 for laughs just in case some of it was
> GCC version specific, but no apparent differences (well, no silly
> alignment warnings, 2.95.3 says "... too much, defaulting to 4 " a
> lot) beyond a slightly bigger .EXE (well, and the above loadup issue
> which 3.4.4 doesn't have, but it doesn't have 8-byte alignment either,
> so the above download is using GCC 4.4.0).
I use GCC 3.4.4 and don't have any alignment issues.
Thanks again for testing. Here's the patch for the problem with
"C-x 5 1" (already in the Emacs repository):
2009-06-28 Eli Zaretskii <el...@gnu.org>
* term.c (create_tty_output) [MSDOS]: #ifdef away.
(tty_free_frame_resources) [MSDOS]: Add a DOS-specific version.
--- src/term.c~ 2009-06-06 23:42:16 +0300
+++ src/term.c 2009-06-28 21:34:54 +0300
@@ -3185,6 +3185,7 @@ DEFUN ("gpm-mouse-stop", Fgpm_mouse_stop
Initialization
***********************************************************************/
+#ifndef MSDOS
/* Initialize the tty-dependent part of frame F. The frame must
already have its device initialized. */
@@ -3218,6 +3219,20 @@ tty_free_frame_resources (struct frame *
xfree (f->output_data.tty);
}
+#else /* MSDOS */
+
+/* Delete frame F's face cache. */
+
+static void
+tty_free_frame_resources (struct frame *f)
+{
+ if (! FRAME_TERMCAP_P (f) && ! FRAME_MSDOS_P (f))
+ abort ();
+
+ if (FRAME_FACE_CACHE (f))
+ free_frame_faces (f);
+}
+#endif /* MSDOS */
/* Reset the hooks in TERMINAL. */
Rugxulo
On Jun 28, 1:59 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Rugxulo <rugx...@gmail.com>
> > Date: Sat, 27 Jun 2009 19:41:56 -0700 (PDT)
>
> > "make install" took approx. 4 1/2 mins.
>
> Is it good or bad?
>
> If bad, what part took most of the time?
Sorry for the confusion, but it's fine, no problem. That's quite fast.
What I actually meant was "make install" will build (if not already)
and then put the .EXEs in \bin in approx. 4 mins. Just for curiosity,
I wanted to see how long it would take. I didn't mean the "install"
part was slow.
> > However, on XP or FreeDOS, if using GCC 2.95.3 (oldy moldy which I'm
> > fond of), it seems to hang at loadup.el (I think)
>
> What do you see if you interrupt it at this stage (you will need to
> run it under GDB for this to work).
I don't know if it's worth investigating, but I may try again
tomorrow. Obviously I didn't much expect anyone to use 2.95.3 anymore
(although I imagine it's not ideal that it doesn't, I mean, it's still
a good compiler, and 2001 isn't exactly ancient). I could guess
alignment issues or maybe the malloc, but who knows.
> > "C-x 5 1" etc. (frames) seem to be giving problems (FreeDOS or Vista).
>
> Ouch! Thanks for reporting this, patch to fix it below.
Heh. ;-)
> > Either way, Make (3.79.1 or 3.81) seemed to have problems
> > finding test-distrib.c
>
> Please show the signs of these problems.
I can't quote exactly without booting DOS, but it just won't even
compile anything until I change the definition of srcdir. I don't know
what causes this, a FreeDOS incompatibility, Make + FreeDOS, FreeCOM,
who knows. The only surefire way to figure it out is to try another
DOS and/or shell.
> > instead of the weird shell hack that is trying to use "e:/emacs"
> > instead
>
> Sorry, I don't follow: what weird hack, and why does it use e:/emacs?
Heh, okay, lemme find the lines and explicitly mention them. (Note
that I also noticed that it worked fine on XP, so for whatever reason
it only has issues under pure FreeDOS.) Identifying this quirk alone
took quite a long time, but I didn't want to report back without some
idea of what was wrong.
--------------------------
# (emacs-23.0.95/Makefile):
#
# Generate a full pathname of the top-level installation directory
top_srcdir := $(subst \,/,$(shell cd))
# won't work in FreeDOS unless manually changed
# to "/dev/e/emacs" or whatever
--------------------------
In other words, in FreeDOS GNU make can't find test-distrib.c at all
until this is manually fixed. (GNU make is annoyingly picky.)
> > "C-x i" (can't find Info dir in FreeDOS w/ SFNs, but Vista w/ LFNs works
> > okay).
>
> I believe you mean "C-h i".
Yes, sorry.
> Do you have INFOPATH set on any of these machines? Please look in
> djgpp.env: it sets things up so that Emacs expects to find the Info
> files that come with Emacs in %DJDIR%/gnu/emacs/info; if you installed
> Emacs in some other directory, you will need to set INFOPATH to point
> to its `info' subdirectory.
I meant without DJGPP detected, active, or installed, Emacs can't find
its own .info files except under LFN environment (Windows).
> If all of this does not help, please show your value of the variable
> Info-directory-list after you type "C-h i".
I'm not on DOS now, so I can't tell you what it says there. But it
seems that it's all defined in PATHS.EL anyways.
> > I also tried with 3.4.4 for laughs just in case some of it was
> > GCC version specific, but no apparent differences (well, no silly
> > alignment warnings, 2.95.3 says "... too much, defaulting to 4 " a
> > lot) beyond a slightly bigger .EXE (well, and the above loadup issue
> > which 3.4.4 doesn't have, but it doesn't have 8-byte alignment either,
> > so the above download is using GCC 4.4.0).
>
> I use GCC 3.4.4 and don't have any alignment issues.
Really? CONFIG.BAT whines for me. And I thought you were using 3.4.3,
finally upgraded? ;-)
> Thanks again for testing. Here's the patch for the problem with
> "C-x 5 1" (already in the Emacs repository):
Thanks for the quick patch. :-)
Can somebody else try building on Vista (config.bat --with-system-
malloc msdos), and see if it fails? As mentioned, it doesn't take
long, only a few minutes.
Eli Zaretskii
> Date: Sun, 28 Jun 2009 18:03:55 -0700 (PDT)
>
> --------------------------
> # (emacs-23.0.95/Makefile):
> #
> # Generate a full pathname of the top-level installation directory
> top_srcdir := $(subst \,/,$(shell cd))
> # won't work in FreeDOS unless manually changed
> # to "/dev/e/emacs" or whatever
> --------------------------
What shell does FreeDOS use, and what do you get from that shell when
you type "cd" with no arguments?
The following two lines of the top-level Makefile:
SHELL=/xyzzy/command
MAKESHELL=/xyzzy/command
are there to make sure command.com (and not some other shell) is used,
so that "cd" returns the current working directory. If FreeDOS has
its own incompatible version of command.com, that might explain the
problem.
Maybe it's time to replace this trickery with $CURDIR, which exists
since Make 3.77.
> > > "C-x i" (can't find Info dir in FreeDOS w/ SFNs, but Vista w/ LFNs works
> > > okay).
> >
> > I believe you mean "C-h i".
>
> Yes, sorry.
>
> > Do you have INFOPATH set on any of these machines? Please look in
> > djgpp.env: it sets things up so that Emacs expects to find the Info
> > files that come with Emacs in %DJDIR%/gnu/emacs/info; if you installed
> > Emacs in some other directory, you will need to set INFOPATH to point
> > to its `info' subdirectory.
>
> I meant without DJGPP detected, active, or installed, Emacs can't find
> its own .info files except under LFN environment (Windows).
Do you mean the DJGPP variable is not set at all?
> > > I also tried with 3.4.4 for laughs just in case some of it was
> > > GCC version specific, but no apparent differences (well, no silly
> > > alignment warnings, 2.95.3 says "... too much, defaulting to 4 " a
> > > lot) beyond a slightly bigger .EXE (well, and the above loadup issue
> > > which 3.4.4 doesn't have, but it doesn't have 8-byte alignment either,
> > > so the above download is using GCC 4.4.0).
> >
> > I use GCC 3.4.4 and don't have any alignment issues.
>
> Really? CONFIG.BAT whines for me. And I thought you were using 3.4.3,
> finally upgraded? ;-)
Yes, I upgraded because 3.4.3 has bugs in the debug info it produces,
which I bumped into when working on GDB.
Rugxulo
On Jun 28, 10:17 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Rugxulo <rugx...@gmail.com>
> > Date: Sun, 28 Jun 2009 18:03:55 -0700 (PDT)
>
> > --------------------------
> > # (emacs-23.0.95/Makefile):
> > #
> > # Generate a full pathname of the top-level installation directory
> > top_srcdir := $(subst \,/,$(shell cd))
> > # won't work in FreeDOS unless manually changed
> > # to "/dev/e/emacs" or whatever
> > --------------------------
>
> What shell does FreeDOS use, and what do you get from that shell when
> you type "cd" with no arguments?
FreeDOS uses FreeCOM. Here I was using 0.84-pre2, but some prefer
0.82pl3 for its alleged better stability. (I've never had any issues
with either.) But 0.82pl3 doesn't support LFNs or DESCRIPT.IONs, and
0.84-pre2 only supports all features in 186 (not 8086) compiles. So
it's a (small) tradeoff.
(0.82pl3 download):
http://sourceforge.net/project/showfiles.php?group_id=5109&package_id=9826&release_id=203962
(0.84-pre2 download, command[xs].zip):
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/
(4DOS 8.00, final Lucho release):
http://4dos.zzl.org/
Anyways, long story short, it seems FreeCOM (either version) reports
"E:\EMACS" while 4DOS reports "e:\emacs". I can't imagine that
something so silly as case sensitivity could be the trouble, but
apparently it is!
> Maybe it's time to replace this trickery with $CURDIR, which exists
> since Make 3.77.
Since I don't think it would even work with any non-GNU (and non-
DJGPP) make anyways, I think that's a fair suggestion. /current/3.79.1
and /beta/3.81 are the latest available for DJGPP anyways, so it's
fair to assume everyone already has one of them by now. I've even seen
a few other projects claim to require 3.81 or newer. So it wouldn't be
far out to assume 3.77+ for Emacs.
> > > Do you have INFOPATH set on any of these machines? Please look in
> > > djgpp.env: it sets things up so that Emacs expects to find the Info
> > > files that come with Emacs in %DJDIR%/gnu/emacs/info; if you installed
> > > Emacs in some other directory, you will need to set INFOPATH to point
> > > to its `info' subdirectory.
>
> > I meant without DJGPP detected, active, or installed, Emacs can't find
> > its own .info files except under LFN environment (Windows).
>
> Do you mean the DJGPP variable is not set at all?
Sorry, my bad. I never installed (or intended to install) the full GNU
Emacs into the DJGPP directory. While the idea isn't bad, I dislike
making my setup too unwieldy, so I build it and even use it
separately. But when building, obviously %DJGPP% is set, which loads
DJGPP.ENV, which sets INFOPATH. In other words, it works fine without
%DJGPP% set (Emacs can load its own Info files fine via C-h i). So
never mind. ;-)
> > > I use GCC 3.4.4 and don't have any alignment issues.
>
> > Really? CONFIG.BAT whines for me. And I thought you were using 3.4.3,
> > finally upgraded? ;-)
>
> Yes, I upgraded because 3.4.3 has bugs in the debug info it produces,
> which I bumped into when working on GDB.
Wow, the smallest upgrade in the history of the universe. Taking a big
risk, eh? Living on the bleeding edge? ;-) j/k
Eli Zaretskii
> Date: Mon, 29 Jun 2009 21:44:45 -0700 (PDT)
>
> > > # Generate a full pathname of the top-level installation directory
> > > top_srcdir := $(subst \,/,$(shell cd))
> > > # won't work in FreeDOS unless manually changed
> > > # to "/dev/e/emacs" or whatever
> > > --------------------------
> >
> > What shell does FreeDOS use, and what do you get from that shell when
> > you type "cd" with no arguments?
> Anyways, long story short, it seems FreeCOM (either version) reports
> "E:\EMACS" while 4DOS reports "e:\emacs". I can't imagine that
> something so silly as case sensitivity could be the trouble, but
> apparently it is!
I don't see how could letter-case matter here. If you can show me
otherwise, please do. The exact error message would be nice.
I suspect that the problem could be not with top_srcdir in the
top-level Makefile, but rather with this line from lib-src/Makefile:
srcdir := $(subst \,/,$(shell command.com /c cd))
Do you have command.com on FreeDOS, and if you do, what does it do
with this line? What does $(srcdir) get set to?
> > > > I use GCC 3.4.4 and don't have any alignment issues.
> >
> > > Really? CONFIG.BAT whines for me. And I thought you were using 3.4.3,
> > > finally upgraded? ;-)
> >
> > Yes, I upgraded because 3.4.3 has bugs in the debug info it produces,
> > which I bumped into when working on GDB.
>
> Wow, the smallest upgrade in the history of the universe. Taking a big
> risk, eh? Living on the bleeding edge? ;-) j/k
It's very simple: the only other port is of GCC 4.x, and I don't want
yet to go there.
Rugxulo
On Jun 30, 1:05 pm, Eli Zaretskii <e...@gnu.org> wrote:
>
> I don't see how could letter-case matter here. If you can show me
> otherwise, please do. The exact error message would be nice.
Well, it seemed to work with 4DOS without any modifications, so I'm
blindly guessing that case matters. Below is the exact error message:
-------------------------------
[ FreeDOS ] Mon 06-29-2009>make
cd lib-src
d:/gcc/bin/make.exe top_srcdir=e:/emacs version="23.0.95"
make.exe[1]: Entering directory `e:/emacs/lib-src'
make.exe[1]: *** No rule to make target `/test-distrib.c', needed by
`test-distrib'. Stop.
make.exe[1]: Leaving directory `e:/emacs/lib-src'
make.exe: *** [lib-src] Error 2
-------------------------------
> I suspect that the problem could be not with top_srcdir in the
> top-level Makefile, but rather with this line from lib-src/Makefile:
>
> srcdir := $(subst \,/,$(shell command.com /c cd))
I changed both Makefile and lib-src/Makefile, both top_srcdir and
srcdir, respectively.
> Do you have command.com on FreeDOS, and if you do, what does it do
> with this line? What does $(srcdir) get set to?
FreeCOM is named COMMAND.COM for compatibility. I guess it gets set to
"E:\EMACS\lib-src". (I should really test again and use djecho to
verify it.) All I'm saying is that it won't work with FreeCOM unless I
manually change it. I can't say why.
> > Wow, the smallest upgrade in the history of the universe. Taking a big
> > risk, eh? Living on the bleeding edge? ;-) j/k
>
> It's very simple: the only other port is of GCC 4.x, and I don't want
> yet to go there.
Hey, it's fine, I use all kinds of GCCs, so it's no biggie. In fact, I
think the AVR targeting ones work better in 3.x than 4.x. Latest
OpenBSD 4.5 still uses 3.3.5 (I think some non-x86 targets (Sparc??
VAX??) have bugs with newer versions). However, most other people use
4.x due to its improvements (although *BSD avoid anything newer than
4.2.1, if even, due to GPLv3). Actually, I think 4.0.x was vaguely
buggy, 4.2.x had a big unknown slowdown, and 4.3.2 brought things back
up to par. That's not to say they don't whine a lot (-Wno-parentheses
is pretty much required, IMHO). But hey, 3.4.4 is from 2005, so it's
not old, and I still use it (and older!) on various computers, esp. my
P166 (although in all honesty, despite being twice as fast as 4.4.0,
it's twice as slow as 2.95.3, go figure). For laughs you may want to
try the DJGPP/ELF hack (COFF or ELF supported), which uses 4.0.1. GCC
4.x really does optimize better (esp. C++) although not a billion
times better or anything.
Eli Zaretskii
> Date: Tue, 30 Jun 2009 15:29:37 -0700 (PDT)
>
> [ FreeDOS ] Mon 06-29-2009>make
> cd lib-src
> d:/gcc/bin/make.exe top_srcdir=e:/emacs version="23.0.95"
> make.exe[1]: Entering directory `e:/emacs/lib-src'
> make.exe[1]: *** No rule to make target `/test-distrib.c', needed by
> `test-distrib'. Stop.
> make.exe[1]: Leaving directory `e:/emacs/lib-src'
> make.exe: *** [lib-src] Error 2
So it's clear that the problem is with lib-src/Makefile.
> FreeCOM is named COMMAND.COM for compatibility. I guess it gets set to
> "E:\EMACS\lib-src".
The above error message clearly shows that it gets set to an empty
string, that's how `/test-distrib.c' came into existence. It should
have been `E:/EMACS/lib-src/test-distrib.c' instead.
> GCC 4.x really does optimize better (esp. C++) although not a
> billion times better or anything.
Code that's too optimized is a pain to debug. I'm unwilling to trade
the ability to debug reasonably optimized code for another 6.5% of
speedup.
DJ Delorie
> Code that's too optimized is a pain to debug. I'm unwilling to
> trade the ability to debug reasonably optimized code for another
> 6.5% of speedup.
One of the current projects is to improve the ability to debug
optimized code.
Eli Zaretskii
> From: DJ Delorie <d...@delorie.com>
Yes, I know. I'm waiting impatiently to see such features in a future
version of GCC.
I miss the days of GCC 2.7.x and 2.8.x, when I could debug a -O2
optimized program with almost the same ease as a non-optimized one.
Being able to do that was once one of the most attractive features of
GCC among the other C compilers. Now I always compile Emacs with -O1
because otherwise you cannot even get a correct backtrace or put a
breakpoint on a static function and know that it will be hit if the
function is called.
Rugxulo
On Jun 28, 2:41 am, Rugxulo <rugx...@gmail.com> wrote:
>
> "C-x 5 1" etc. (frames) seem to be giving problems (FreeDOS or Vista).
> I don't use frames that much, so I'm not sure when that broke exactly.
I've recompiled on my XP machine (GCC 4.4.0, --with-system-malloc)
with -Os -mtune=i686, now with the frames fix, so here's the main
EMACS.EXE file (plus Eli's tiny patch) if anybody downloaded the
earlier build.
N.B. I did not UPX it because that runs slower on XP etc. Also, I left
the debug info in the .EXE. In short, you can reduce the .EXE size to
approx. 1.6 MB by using "upx --best --lzma --all-filters".
--------------------------------------------------------------
Your file has been saved and can now be downloaded 10 times. It will
be deleted after 90 days without download.
1. Download Link: Click here to download file (2 MB)
http://rapidshare.com/files/252011814/emacs_exe-23095-fix.7z.html
MD5: 024B4108A986080057CB882559148A4F
--------------------------------------------------------------
P.S. Using Google Chrome on Vista (and it runs pretty fast,
surprisingly).