while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) { ! /* Subtract the size of trailing null pages from filesize. It can be smaller than vmsize in segment commands. In such a ! case, trailing pages are initialized with zeros. */ ! for (p = ranges->address + ranges->size; p > ranges->address; ! p -= sizeof (int)) ! if (*(((int *) p)-1)) break; ! filesize = ROUNDUP_TO_PAGE_BOUNDARY (p - ranges->address); ! assert (filesize <= ranges->size);
while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) { ! /* Subtract the size of trailing null bytes from filesize. It can be smaller than vmsize in segment commands. In such a ! case, trailing bytes are initialized with zeros. */ ! for (p = ranges->address + ranges->size; p > ranges->address; p--) ! if (*(((char *) p)-1)) break; ! filesize = p - ranges->address;
This patch seems to work. I've tested it only on PPC as I don't have multiple licenses for Leopard. Could you report the result if you have Leopard on Intel Mac?
while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) { ! /* Subtract the size of trailing null pages from filesize. It can be smaller than vmsize in segment commands. In such a ! case, trailing pages are initialized with zeros. */ ! for (p = ranges->address + ranges->size; p > ranges->address; ! p -= sizeof (int)) ! if (*(((int *) p)-1)) ! break; ! filesize = ROUNDUP_TO_PAGE_BOUNDARY (p - ranges->address); ! assert (filesize <= ranges->size);
while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) { ! /* Subtract the size of trailing null bytes from filesize. It can be smaller than vmsize in segment commands. In such a ! case, trailing bytes are initialized with zeros. */ ! for (p = ranges->address + ranges->size; p > ranges->address; p--) ! if (*(((char *) p)-1)) ! break; ! filesize = p - ranges->address;
> This patch seems to work. I've tested it only on PPC as I don't have > multiple licenses for Leopard. Could you report the result if you > have Leopard on Intel Mac?
> while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) > { > ! /* Subtract the size of trailing null pages from filesize. It > can be smaller than vmsize in segment commands. In such a > ! case, trailing pages are initialized with zeros. */ > ! for (p = ranges->address + ranges->size; p > ranges->address; > ! p -= sizeof (int)) > ! if (*(((int *) p)-1)) > ! break; > ! filesize = ROUNDUP_TO_PAGE_BOUNDARY (p - ranges->address); > ! assert (filesize <= ranges->size);
> while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) > { > ! /* Subtract the size of trailing null bytes from filesize. It > can be smaller than vmsize in segment commands. In such a > ! case, trailing bytes are initialized with zeros. */ > ! for (p = ranges->address + ranges->size; p > ranges->address; p--) > ! if (*(((char *) p)-1)) > ! break; > ! filesize = p - ranges->address;
> This patch seems to work. I've tested it only on PPC as I don't have > multiple licenses for Leopard. Could you report the result if you > have Leopard on Intel Mac?
> while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) > { > ! /* Subtract the size of trailing null pages from filesize. It > can be smaller than vmsize in segment commands. In such a > ! case, trailing pages are initialized with zeros. */ > ! for (p = ranges->address + ranges->size; p > ranges->address; > ! p -= sizeof (int)) > ! if (*(((int *) p)-1)) > ! break; > ! filesize = ROUNDUP_TO_PAGE_BOUNDARY (p - ranges->address); > ! assert (filesize <= ranges->size);
> while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) > { > ! /* Subtract the size of trailing null bytes from filesize. It > can be smaller than vmsize in segment commands. In such a > ! case, trailing bytes are initialized with zeros. */ > ! for (p = ranges->address + ranges->size; p > ranges- > >address; p--) > ! if (*(((char *) p)-1)) > ! break; > ! filesize = p - ranges->address;
> This patch seems to work. I've tested it only on PPC as I don't have > multiple licenses for Leopard. Could you report the result if you > have Leopard on Intel Mac?
> while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) > { > ! /* Subtract the size of trailing null pages from filesize. It > can be smaller than vmsize in segment commands. In such a > ! case, trailing pages are initialized with zeros. */ > ! for (p = ranges->address + ranges->size; p > ranges->address; > ! p -= sizeof (int)) > ! if (*(((int *) p)-1)) > ! break; > ! filesize = ROUNDUP_TO_PAGE_BOUNDARY (p - ranges->address); > ! assert (filesize <= ranges->size);
> while (num && num_unexec_regions < MAX_UNEXEC_REGIONS) > { > ! /* Subtract the size of trailing null bytes from filesize. It > can be smaller than vmsize in segment commands. In such a > ! case, trailing bytes are initialized with zeros. */ > ! for (p = ranges->address + ranges->size; p > ranges->address; p--) > ! if (*(((char *) p)-1)) > ! break; > ! filesize = p - ranges->address;
On Oct 29, 4:17 pm, YAMAMOTO Mitsuharu <mituh...@math.s.chiba-u.ac.jp> wrote:
> This patch seems to work. I've tested it only on PPC as I don't have > multiple licenses for Leopard. Could you report the result if you > have Leopard on Intel Mac?
Just to clarify, the patch (thank you Yamamoto Mitsuharu!) works great for Leopard on Intel Macs (mine is a Core 2 Duo iMac) when applied to GNU Emacs 22.1 release. The patch does allow GNU Emacs from CVS (presently 23.0.50) to build (though configure doesn't properly set HAVE_LIBRESOLV -- just add `-lresolv' to the temacs link rule in src/ Makefile). However, Emacs 23.0.50 freezes on any sort of input. Similarly, the patch allows Emacs-app rc2a to build and run, but as with 23.0.50, it seems unusable.
On Fri, 02 Nov 2007 17:09:20 +0900 William Xu <william....@gmail.com> wrote:
WX> slew...@gmail.com writes: >> However, Emacs 23.0.50 freezes on any sort of input.
WX> Yes, same here... Typing any key, it takes several seconds to respond WX> again. Barely usable.
This has been reported to the emacs-devel mailing list repeatedly. It was probably introduced with the Unicode merge in August. See the emacs-devel archives or
Ted Zlatanov <t...@lifelogs.com> writes: > This has been reported to the emacs-devel mailing list repeatedly. It > was probably introduced with the Unicode merge in August.
Hmm, i'm running it happily now with:
,----[ emacs-version ] | GNU Emacs 23.0.50.9 (powerpc-apple-darwin8.10.0, Carbon Version 1.6.0) | of 2007-10-20 on enjoy-life `----
I built it on osx 10.4.10, with option, `--prefix=$HOME --with-carbon --without-x'.
And the other thing is that i disable the fink in the `configure' file by applying nofink.patch from carbon emacs 22.1. (since i couldn't even bootstrap emacs with fink, and i also don't understand why people refuse to remove it)
So i guess the slow responsiveness is introduced either by recent cvs changes(20071020 - now) or osx changes(10.4 -> 10.5).
Since I built cvs emacs regularly, looks like i could still run cvs emacs built after 20071020, but i couldn't remember the exact revision that introduced this problem. (And i have no osx 10.4 anymore..)
>> This has been reported to the emacs-devel mailing list repeatedly. It >> was probably introduced with the Unicode merge in August.
WX> Hmm, i'm running it happily now with:
WX> ,----[ emacs-version ] WX> | GNU Emacs 23.0.50.9 (powerpc-apple-darwin8.10.0, Carbon Version 1.6.0) WX> | of 2007-10-20 on enjoy-life WX> `----
WX> I built it on osx 10.4.10, with option, `--prefix=$HOME --with-carbon WX> --without-x'.
WX> And the other thing is that i disable the fink in the `configure' file WX> by applying nofink.patch from carbon emacs 22.1. (since i couldn't even WX> bootstrap emacs with fink, and i also don't understand why people refuse WX> to remove it)
I use Darwin Ports, no Fink. gcc comes from the Apple dev tools.
I am still experiencing the problem, and I'm pretty sure it hasn't changed since August when I first noticed it. Please try making a clean build with any version between August and now, on OS X 10.4 or 10.5, and you'll see the input problem. If you really are not having the input problem with the build you mention above, maybe it doesn't occur on PPC platforms (i386 here). I'm very curious about your build, because no one else has reported success on MacOS as you have.
The last good build for me was GNU Emacs 22.1.50.2 (i386-apple-darwin8.10.1, Carbon Version 1.6.0) of 2007-08-01 on tzz.local
and the last build I tried, which has the input problem: GNU Emacs 23.0.50.1 (i386-apple-darwin9.0.0, Carbon Version 1.6.0) of 2007-08-01 on tzz.local
WX> So i guess the slow responsiveness is introduced either by recent cvs WX> changes(20071020 - now) or osx changes(10.4 -> 10.5).
It's definitely not OS X 10.4 vs 10.5. I have observed the input problem on both (10.4.10 and 10.5).
WX> Since I built cvs emacs regularly, looks like i could still run cvs WX> emacs built after 20071020, but i couldn't remember the exact revision WX> that introduced this problem. (And i have no osx 10.4 anymore..)
On Mon, 05 Nov 2007 13:14:34 -0600 Ted Zlatanov <t...@lifelogs.com> wrote:
TZ> and the last build I tried, which has the input problem: TZ> GNU Emacs 23.0.50.1 (i386-apple-darwin9.0.0, Carbon Version 1.6.0) of 2007-08-01 on tzz.local
That's 2007-11-05 for the date, sorry:
GNU Emacs 23.0.50.1 (i386-apple-darwin9.0.0, Carbon Version 1.6.0) of 2007-11-05 on tzz.local
Ted Zlatanov <t...@lifelogs.com> writes: > If you really are not having the input > problem with the build you mention above, maybe it doesn't occur on PPC > platforms (i386 here). I'm very curious about your build, because no > one else has reported success on MacOS as you have.
Yes, i have no input problem too. I saw people talking about the input problem on some mailing list, which i actually didn't know what they were talking about.
But i only started to build emacs on my ibook since Sep (i installed debian on it previously). So i don't know much about its previous status. Maybe my success is due to ppc platform.
Anyway, i just bought a new macbook..I'll have to struggle to make it work on osx as you guys too...
On Tue, 06 Nov 2007 03:37:29 -0500 Richard Stallman <r...@gnu.org> wrote:
RS> The last good build for me was RS> GNU Emacs 22.1.50.2 (i386-apple-darwin8.10.1, Carbon Version 1.6.0) of 2007-08-01 on tzz.local
RS> Can you determine which change caused the problem?
I can't exactly, since the unicode branch was merged when the problem started happening. This was discussed at length on the emacs-devel mailing list, and there's a whole Carbon vs. Cocoa issue that's complicating things (and making the Carbon port less desirable to developers, apparently). I know little about MacOS, Carbon, or Cocoa, so other than testing fixes I'm not very useful there. I hope to eventually find the time to track what changed since August that's causing the input problem.
Ted Zlatanov wrote: > I can't exactly, since the unicode branch was merged when the problem > started happening.
You mean multi-tty.
For clarity: we are talking about the CVS trunk here, not the 22 branch.
> This was discussed at length on the emacs-devel mailing list,
Yes. The Mac Carbon port in the CVS trunk has known problems and is effectively unsupported. Bug reports about it are not helpful, and this is the wrong list for any discussion about it (or any other problems in non-released versions of Emacs).
On Tue, 06 Nov 2007 18:26:33 -0500 Glenn Morris <r...@gnu.org> wrote:
GM> Ted Zlatanov wrote: >> I can't exactly, since the unicode branch was merged when the problem >> started happening.
GM> You mean multi-tty.
GM> For clarity: we are talking about the CVS trunk here, not the 22 branch.
>> This was discussed at length on the emacs-devel mailing list,
GM> Yes. The Mac Carbon port in the CVS trunk has known problems and is GM> effectively unsupported. Bug reports about it are not helpful, and GM> this is the wrong list for any discussion about it (or any other GM> problems in non-released versions of Emacs).
Sorry. William Xu and slew...@gmail.com brought up the CVS Carbon issues, and I continued the discussion here instead of redirecting it.