Release update

Release update

[Chong Yidong]

Hi fellas,

Here's a short update on the Emacs 23 release process.  We are getting
pretty close, and currently there are two main things to do before
starting the pretest: adding ruby-mode to the CVS repository, and making
rmail-mbox/pmail ready for use.

The papers for ruby-mode are already in the mail; many thanks to Phil
Hagelberg for helping get them signed.  Hopefully, we'll get the
go-ahead from the FSF to add ruby-mode to the repository within a week
or so.  The version of ruby-mode that we hope to commit to CVS is
currently hosted by Phil at

  http://github.com/technomancy/rinari/tree/master%2Futil%2Fruby-mode.el?raw=true

so take a look and see if you can spot any problems.

Rmail-mbox/pmail is going less well, as RMS does not think the new code
is ready for use.  If any of you have the time, please offer to help
Paul Reilly fix bugs in the pmail code.  Much appreciated.

Hopefully, we are still on track to start pretest sometime in December;
let's see.

Re: Release update

[Yavor Doganov]

At Mon, 01 Dec 2008 21:43:01 -0500,
Chong Yidong wrote:
> 
> We are getting pretty close, and currently there are two main things
> to do before starting the pretest: adding ruby-mode to the CVS
> repository, and making rmail-mbox/pmail ready for use.

I don't know what is the Emacs maintainers' opinion about the GNUstep
port wrt release status/goals, but I'd like to mention that in its
current form it is not usable as a replacement of GTK+/Lucid/nox.
Maybe this is not a problem in general, as probably the main goal of
the port is to make Emacs available for users of the Muck OS X system
(as a replacement of the Carbon port).

I don't see it this way, though, although I realize I'm in the
minority.  As a GNUstep user my goal is to use Emacs.app as a
replacement of the Lucid build (or the GTK+ build with the GTK-Step
GTK theme).  This is not possible now, even with my extremely low
Emacs usage requirements.

Whether this is considered release-critical is up to the Emacs
maintainers to decide, naturally.

The trouble is that if GNUstep users don't find this flavor usable to
run it by default, bugs will not be even discovered, let alone fixed.
Of course, it is impossible to fix all bugs in time for the 23
release, but at least the most critical ones should be nailed.

Here is a short summary of what I consider important for the GNUstep
port (in my capacity as a humble user).  I am still experimenting with
some of the bugs to which Adrian sent useful comments.

* #1333: Emacs.app does not load ~/.emacs
  The consequences of this are a real disaster.  Emacs also doesn't
  inherit the environment, which in many cases makes usage of external
  processes a PITA.

* #984: Emacs.app segfaults on startup with the cairo backend
  The cairo backend is still considered experimental in GNUstep Back,
  although probably 90% of the people are using it, because rendering
  is faster and much more beautiful than art.  Not being able to use
  Emacs with cairo means "downgrading" to art, as it is not possible
  to define the backend on a per-app basis (and that's how it should
  be).  This is a GNUstep problem, I think.

* #620: Bootstrapping with the GNUstep port impossible
  Distro unfriendliness.  This is not a problem for regular users, as
  released Emacs already contains byte-compiled files, and there is an
  easy workaround for bootstrapping anyway.  However, nowadays the
  majority of the users prefer distro-provided packages.  Among the
  distros who care about GNUstep and ship it, Emacs.app currently
  cannot be provided for Gentoo because of this, and for Debian
  (gNewSense actually) I am doing a horrible hack/workaround that 
  no sane (Debian) maintainer would upload as an official package.
  As a result, I suspect that at the end this port will have even less
  testing.

* Some GNU Coding Standards violations that I'm going to report soon
  (with patches, eventually).  The problem, basically, is that the
  Emacs.app build system breaks certain user expectations that were in
  place since about forever.

I hope that even intrusive patches for the GNUstep port will be
accepted in the pretest period.

Re: Release update

[Ted Zlatanov]

On Thu, 04 Dec 2008 19:08:29 +0200 Yavor Doganov <yavor@gnu.org> wrote: 

YD> Here is a short summary of what I consider important for the GNUstep
YD> port (in my capacity as a humble user).  I am still experimenting with
YD> some of the bugs to which Adrian sent useful comments.

I wanted to add:

- Emacs.app on Mac OS X crashes at random times and the error is not
  logged and can't be debugged.  This needs to be fixed or it's simply
  not possible to produce a viable environment for real work.

Because of these random crashes and some other issues I've reported,
I've had to switch to the X11 Emacs in Mac OS X for coding and Gnus
(temporarily, I hope, for its fonts are nasty and it's slow).

Thanks
Ted

Re: Release update

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> - Emacs.app on Mac OS X crashes at random times and the error is not
>   logged and can't be debugged.  This needs to be fixed or it's simply
>   not possible to produce a viable environment for real work.

Have you tried running Emacs in a debugger?

Adrian, have you observed these crashes?  Do you have any idea what
causes them?

Re: Release update

[Stefan Monnier]

> I don't know what is the Emacs maintainers' opinion about the GNUstep
> port wrt release status/goals, but I'd like to mention that in its
> current form it is not usable as a replacement of GTK+/Lucid/nox.
> Maybe this is not a problem in general, as probably the main goal of
> the port is to make Emacs available for users of the Muck OS X system
> (as a replacement of the Carbon port).

The GNUstep port is not release-critical for Emacs-23.1.  I do think
it's an important target, so it might become release-ciritcal for
Emacs-23.2, but I just don't think it's worth delaying a release for it,
given its current status.

> * #1333: Emacs.app does not load ~/.emacs
>   The consequences of this are a real disaster.  Emacs also doesn't
>   inherit the environment, which in many cases makes usage of external
>   processes a PITA.

I have the nagging feeling that this is linked to the
CANNOT_DUMP problem.  So it's probably better to spend time on getting
DUMP to work.

> * #984: Emacs.app segfaults on startup with the cairo backend
>   The cairo backend is still considered experimental in GNUstep Back,
>   although probably 90% of the people are using it, because rendering
>   is faster and much more beautiful than art.  Not being able to use
>   Emacs with cairo means "downgrading" to art, as it is not possible
>   to define the backend on a per-app basis (and that's how it should
>   be).  This is a GNUstep problem, I think.

No idea about this.

> * Some GNU Coding Standards violations that I'm going to report soon
>   (with patches, eventually).  The problem, basically, is that the
>   Emacs.app build system breaks certain user expectations that were in
>   place since about forever.

Awaiting your patches.

> I hope that even intrusive patches for the GNUstep port will be
> accepted in the pretest period.

Patches that only affect GNUstep can be about as intrusive as they want,
yes (as long as they move forward, obviously), since the port is barely
usable anyway.


        Stefan

Re: Release update

[Dan Nicolaescu]

Yavor Doganov <yavor@gnu.org> writes:

  > At Mon, 01 Dec 2008 21:43:01 -0500,
  > Chong Yidong wrote:
  > > 
  > > We are getting pretty close, and currently there are two main things
  > > to do before starting the pretest: adding ruby-mode to the CVS
  > > repository, and making rmail-mbox/pmail ready for use.
  > 
  > I don't know what is the Emacs maintainers' opinion about the GNUstep
  > port wrt release status/goals, but I'd like to mention that in its
  > current form it is not usable as a replacement of GTK+/Lucid/nox.
  > Maybe this is not a problem in general, as probably the main goal of
  > the port is to make Emacs available for users of the Muck OS X system
  > (as a replacement of the Carbon port).
  > 
  > I don't see it this way, though, although I realize I'm in the
  > minority.  As a GNUstep user my goal is to use Emacs.app as a
  > replacement of the Lucid build (or the GTK+ build with the GTK-Step
  > GTK theme).  This is not possible now, even with my extremely low
  > Emacs usage requirements.
  > 
  > Whether this is considered release-critical is up to the Emacs
  > maintainers to decide, naturally.

At the time the nextstep code was checked in Stefan said that it won't
delay a release.  And it probably was a good decision, although A LOT of
people report bugs, unfortunately only the maintainer works on fixing
them.  Not sure why it's so hard to attract developers...

Re: Release update

[Ted Zlatanov]

On Thu, 04 Dec 2008 14:29:06 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> - Emacs.app on Mac OS X crashes at random times and the error is not
>> logged and can't be debugged.  This needs to be fixed or it's simply
>> not possible to produce a viable environment for real work.

CY> Have you tried running Emacs in a debugger?

Yes, unfortunately it didn't help.

CY> Adrian, have you observed these crashes?  Do you have any idea what
CY> causes them?

I reported the issues to emacs-devel and the Emacs.app mailing list in
<m2y702mdfw.fsf@getconnected.com>

Adrian replied only to the Emacs.app mailing list with
<AE3F6761-560A-4113-A84F-BB2D5781BCCD@gmail.com> and the thread stayed
there.  I can summarize here if it's necessary, although Adrian can
probably do a better job.

Ted

Re: Release update

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Hi fellas,
  > 
  > Here's a short update on the Emacs 23 release process.  We are getting

May I suggest that writing a release announcement be part of the release
process?  Something short that summarizes the most important features
would be good to give people reasons to look further in NEWS and to
upgrade, and it's good for PR.  Not everyone wants to read the 2000
lines NEWS file...

Re: Release update

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> May I suggest that writing a release announcement be part of the
> release process?  Something short that summarizes the most important
> features would be good to give people reasons to look further in NEWS
> and to upgrade, and it's good for PR.  Not everyone wants to read the
> 2000 lines NEWS file...

We do include a feature summary in the release announcement; see, for
instance, the 21.1 and 22.1 release announcements.  This is written up
shortly before the release.  We also put a feature summary on the
webpage.

Re: Release update

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > May I suggest that writing a release announcement be part of the
  > > release process?  Something short that summarizes the most important
  > > features would be good to give people reasons to look further in NEWS
  > > and to upgrade, and it's good for PR.  Not everyone wants to read the
  > > 2000 lines NEWS file...
  > 
  > We do include a feature summary in the release announcement; see, for
  > instance, the 21.1 and 22.1 release announcements.  This is written up

The 22.1 announcement is the one I had in mind, and it could be improved
a lot.  Something like:

   - New modes and packages, including Calc, Grep, TRAMP, URL, IDO,
     CUA, ERC, rcirc, Table, Image-Dired, SES, Ruler, Org, PGG,
     Flymake, Password, Printing, Reveal, wdired, t-mouse,
     longlines, savehist, Conf mode, Python mode, DNS mode, etc.

   - Abbrev definitions are read automatically at startup.


is not too helpful for a lot of users.  IMHO the announcement should be
readable for people that are not intimately familiar with the emacs internals.

Re: Release update

[Adrian Robert]

On Dec 4, 2008, at 2:29 PM, Chong Yidong wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> - Emacs.app on Mac OS X crashes at random times and the error is not
>>  logged and can't be debugged.  This needs to be fixed or it's simply
>>  not possible to produce a viable environment for real work.
>
> Have you tried running Emacs in a debugger?
>
> Adrian, have you observed these crashes?  Do you have any idea what
> causes them?

I use Emacs.app heavily on a daily basis on 10.4 and 10.5 for English  
and Chinese text editing and program editing/compilation and don't get  
crashes.  However I don't use more complex modes like gud, gnus, and  
image-viewing.  (Though I was using ecb for a while.)  I don't know  
what the problem would be but if it is intermittent all I can suggest  
is building with no optimization, just -g, to get a better stack  
trace, and running from gdb (cd emacs/src ; gdb ../nextstep/Emacs.app/ 
Contents/MacOS/Emacs).

Re: Release update

[Randal L. Schwartz]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> - Emacs.app on Mac OS X crashes at random times and the error is not
Ted>   logged and can't be debugged.  This needs to be fixed or it's simply
Ted>   not possible to produce a viable environment for real work.

And has incremental building on "make install" been fixed?  Last I checked
a few weeks ago, it still didn't work.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Release update

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> And has incremental building on "make install" been fixed?  Last I checked
Randal> a few weeks ago, it still didn't work.

Yup.  Just verified.  Still broken.  Repeat by:

make bootstrap install # works
touch src/*.m # to force some changes
make install # fails to build a working .app, since things like .app/etc are broken


-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Release update

[Richard M Stallman]

Are people saying that Emacs works better with MacOS than with
GNUstep?  That is not good.  But in order to change this, we need some
GNUstep users to fix the bugs.  Can we recruit some to help, perhaps
by posting on some GNUstep list?

Re: Re: Release update

[richardeng]

Because my PC is slow, I've used WindowMaker(GNUStep) about 4 years.
What kind of skills is needed to solve bugs under GNUStep(module name in bug description is NS?)
It seem that only bugs related to Emacs.app belongs to NS, right?

It's better, if somebody can provide some brief introduction.

Emacs on GNUstep (was: Release update)

[Stefan Monnier]

> Because my PC is slow, I've used WindowMaker(GNUStep) about 4 years.
> What kind of skills is needed to solve bugs under GNUStep(module name
> in bug description is NS?)  It seem that only bugs related to
> Emacs.app belongs to NS, right?

IIUC the main problem with it right now is that it cannot be dumped.
I.e. we cannot perform the compilation step where we load `temacs', then
all the core Emacs files, and then dump the result into a new executable
`emacs'.
This means that Emacs/GNUstep has to load all the fils like subr.el,
simple.el, text-mode.el, ... over and over again at each startup, and it
has several other nasty consequences.

Fixing this requires someone who can delve into the details of how
GNUstep binaries are layed out and how the ObjC runtime is linked and
initialized and how all this interacts.


        Stefan

Emacs on GNUstep (was: Release update)

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Fixing this requires someone who can delve into the details of how
 > GNUstep binaries are layed out and how the ObjC runtime is linked and
 > initialized and how all this interacts.

Or a portable dumper which reloads the Lisp environemnt into a new
malloc'd area, and doesn't care about all that.

Re: Emacs on GNUstep (was: Release update)

[richardeng]

Stephen J. Turnbull wrote:

>>Stefan Monnier writes:
>> Fixing this requires someone who can delve into the details of how
>> GNUstep binaries are layed out and how the ObjC runtime is linked and
>> initialized and how all this interacts.

> Or a portable dumper which reloads the Lisp environemnt into a new
> malloc'd area, and doesn't care about all that.

It doesn't seem a easy job.
I always "./configure && make && make install" in GNUStep.
At now, I don't know the difference between with/without --with-ns
I'll try "./configure --with-ns" to reproduce #620(Bootstrapping with the GNUstep port impossible)

Re: Emacs on GNUstep (was: Release update)

[Stephen J. Turnbull]

richardeng writes:

 > > Or a portable dumper which reloads the Lisp environemnt into a new
 > > malloc'd area, and doesn't care about all that.
 > 
 > It doesn't seem a easy job.

It isn't, and I don't know if the one that has been written for Emacs
would serve as well as the one XEmacs has; Emacs might need to start
from scratch.

I'm just reminding Stefan that there's a long-term solution with lots
of benefits that go beyond making GNUStep a first-class citizen of the
community.

Re: Re: Emacs on GNUstep (was: Release update)

[richardeng]

Stephen J. Turnbull writes:

>richardeng writes:

>> > Or a portable dumper which reloads the Lisp environemnt into a new
> > > malloc'd area, and doesn't care about all that.
> > 
> > It doesn't seem a easy job.

> It isn't, and I don't know if the one that has been written for Emacs
> would serve as well as the one XEmacs has; Emacs might need to start
> from scratch.

> I'm just reminding Stefan that there's a long-term solution with lots
> of benefits that go beyond making GNUStep a first-class citizen of the
> community.

I spent some time on it. Too sad, I was blocked on(apt-get install what-package?): 
checking AppKit/AppKit.h usability... no
checking AppKit/AppKit.h presence... no
checking for AppKit/AppKit.h... no
configure: error: `--with-ns' was specified, but the include

Maybe, apple users should pay more attention on NS release. 
I feel emacs configured without --with-ns well. 
If build without --with-ns, emacs won't work on MacOS GUI? I guess yes.

Re: Emacs on GNUstep

[Chong Yidong]

"richardeng" <richardeng@foxmail.com> writes:

> I spent some time on it. Too sad, I was blocked on(apt-get install what-package?): 
> checking AppKit/AppKit.h usability... no
> checking AppKit/AppKit.h presence... no
> checking for AppKit/AppKit.h... no
> configure: error: `--with-ns' was specified, but the include

You need gnustep-devel and libgnustep-gui-dev.

Re: Release update

[Ted Zlatanov]

On Thu, 4 Dec 2008 17:55:59 -0500 Adrian Robert <adrian.b.robert@gmail.com> wrote: 

AR> On Dec 4, 2008, at 2:29 PM, Chong Yidong wrote:

>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> - Emacs.app on Mac OS X crashes at random times and the error is not
>>> logged and can't be debugged.  This needs to be fixed or it's simply
>>> not possible to produce a viable environment for real work.
>> 
>> Have you tried running Emacs in a debugger?
>> 
>> Adrian, have you observed these crashes?  Do you have any idea what
>> causes them?

AR> I use Emacs.app heavily on a daily basis on 10.4 and 10.5 for English
AR> and Chinese text editing and program editing/compilation and don't get
AR> crashes.  However I don't use more complex modes like gud, gnus, and
AR> image-viewing.  (Though I was using ecb for a while.)  I don't know
AR> what the problem would be but if it is intermittent all I can suggest
AR> is building with no optimization, just -g, to get a better stack
AR> trace, and running from gdb (cd emacs/src ; gdb ../nextstep/Emacs.app/
AR> Contents/MacOS/Emacs).

I ran Emacs.app for a day under the debugger, using Gnus and other
tools, and it worked all right without crashes.  It may be a difference
between my command-line setup and starting it from the MacOS Finder.
I'll keep testing and write back if I find anything useful.

The part where "the error can't be logged or debugged" is the bigger
concern IMO.  Adrian, what needs to happen to have the Emacs.app bundle
(the one users will open) produce usable core files and log messages?
I'll help any way I can.

Ted

Re: Emacs on GNUstep (was: Release update)

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 05 Dec 2008 10:49:42 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> Because my PC is slow, I've used WindowMaker(GNUStep) about 4
>> years.  What kind of skills is needed to solve bugs under
>> GNUStep(module name in bug description is NS?)  It seem that only
>> bugs related to Emacs.app belongs to NS, right?

> IIUC the main problem with it right now is that it cannot be dumped.
> I.e. we cannot perform the compilation step where we load `temacs',
> then all the core Emacs files, and then dump the result into a new
> executable `emacs'.  This means that Emacs/GNUstep has to load all
> the fils like subr.el, simple.el, text-mode.el, ... over and over
> again at each startup, and it has several other nasty consequences.

> Fixing this requires someone who can delve into the details of how
> GNUstep binaries are layed out and how the ObjC runtime is linked
> and initialized and how all this interacts.

I just tried copying ObjC-related information in the .data section not
from the dumping process but from the original temacs file so as to
avoid some confusion during the startup time of the dumped executable.
It seems to work for me at least on GNU/Linux (Ubuntu 9.04).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/unexelf.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/unexelf.c,v
retrieving revision 1.71
diff -c -p -r1.71 unexelf.c
*** src/unexelf.c	7 Feb 2009 13:07:39 -0000	1.71
--- src/unexelf.c	2 May 2009 06:23:18 -0000
*************** unexec (new_name, old_name, data_start, 
*** 1206,1216 ****
        symendp = (ElfW(Sym) *) ((byte *)symp + NEW_SECTION_H (n).sh_size);
  
        for (; symp < symendp; symp ++)
! 	if (strcmp ((char *) (symnames + symp->st_name), "_end") == 0
! 	    || strcmp ((char *) (symnames + symp->st_name), "end") == 0
! 	    || strcmp ((char *) (symnames + symp->st_name), "_edata") == 0
! 	    || strcmp ((char *) (symnames + symp->st_name), "edata") == 0)
! 	  memcpy (&symp->st_value, &new_bss_addr, sizeof (new_bss_addr));
      }
  
    /* This loop seeks out relocation sections for the data section, so
--- 1206,1242 ----
        symendp = (ElfW(Sym) *) ((byte *)symp + NEW_SECTION_H (n).sh_size);
  
        for (; symp < symendp; symp ++)
! 	{
! 	  if (strcmp ((char *) (symnames + symp->st_name), "_end") == 0
! 	      || strcmp ((char *) (symnames + symp->st_name), "end") == 0
! 	      || strcmp ((char *) (symnames + symp->st_name), "_edata") == 0
! 	      || strcmp ((char *) (symnames + symp->st_name), "edata") == 0)
! 	    memcpy (&symp->st_value, &new_bss_addr, sizeof (new_bss_addr));
! 
! 	  /* ObjC runtime modifies the values of some data structures
! 	     such as classes and selectors in the .data section after
! 	     loading.  As the dump process copies the .data section
! 	     from the current process, that causes problems when the
! 	     modified classes are reinitialized in the dumped
! 	     executable.  We copy such data from the old file, not
! 	     from the current process.  */
! 	  if (strncmp ((char *) (symnames + symp->st_name),
! 		       "_OBJC_", sizeof ("_OBJC_") - 1) == 0)
! 	    {
! 	      caddr_t old, new;
! 
! 	      /* XXX: Check the section name of symp->st_shndx? */
! 	      new = ((symp->st_value - NEW_SECTION_H (symp->st_shndx).sh_addr)
! 		     + NEW_SECTION_H (symp->st_shndx).sh_offset + new_base);
! 	      /* "Unpatch" index.  */
! 	      nn = symp->st_shndx;
! 	      if (nn > old_bss_index)
! 		nn--;
! 	      old = ((symp->st_value - NEW_SECTION_H (symp->st_shndx).sh_addr)
! 		     + OLD_SECTION_H (nn).sh_offset + old_base);
! 	      memcpy (new, old, symp->st_size);
! 	    }
! 	}
      }
  
    /* This loop seeks out relocation sections for the data section, so

Re: Emacs on GNUstep

[Stefan Monnier]

> I just tried copying ObjC-related information in the .data section not
> from the dumping process but from the original temacs file so as to
> avoid some confusion during the startup time of the dumped executable.
> It seems to work for me at least on GNU/Linux (Ubuntu 9.04).

Great news, thank you.  I'll try it out as soon as possible.
If you wrap it in appropriate #ifdef, you can install it on the trunk
(and please add a comment indicating that the ifdef shouldn't be
necessary anyway).  Of course, remove the CANNOT_DUMP setting for
GNUStep at the same.


        Stefan

Re: Emacs on GNUstep (was: Release update)

[Yavor Doganov]

YAMAMOTO Mitsuharu wrote:
> I just tried copying ObjC-related information in the .data section
> not from the dumping process but from the original temacs file so as
> to avoid some confusion during the startup time of the dumped
> executable.

Thank you very much!  This looks like a much simpler and more
straightforward approach than trying to duplicate the whole logic
using NSZone functions.

> It seems to work for me at least on GNU/Linux (Ubuntu 9.04).

I confirm it works fine on gNewSense DeltaH (with fairly old
GCC/GNUstep versions) and Debian GNU/kFreeBSD.

What a relief, I bet this fixes a lot of issues in the GNUstep port.

Re: Emacs on GNUstep

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 03 May 2009 15:38:49 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> I just tried copying ObjC-related information in the .data section
>> not from the dumping process but from the original temacs file so
>> as to avoid some confusion during the startup time of the dumped
>> executable.  It seems to work for me at least on GNU/Linux (Ubuntu
>> 9.04).

> Great news, thank you.  I'll try it out as soon as possible.  If you
> wrap it in appropriate #ifdef, you can install it on the trunk (and
> please add a comment indicating that the ifdef shouldn't be
> necessary anyway).  Of course, remove the CANNOT_DUMP setting for
> GNUStep at the same.

We can't simply remove CANNOT_DUMP because dumping requires unexelf.c
currently.  The macro __ELF__ cannot be used here because it doesn't
necessarily imply the use of unexelf.c (e.g., Solaris 10).

How about the patch below?  I also removed UNEXEC_SRC because it is no
longer used anywhere.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: configure.in
===================================================================
RCS file: /sources/emacs/emacs/configure.in,v
retrieving revision 1.594
diff -c -p -r1.594 configure.in
*** configure.in	1 May 2009 15:32:01 -0000	1.594
--- configure.in	4 May 2009 07:59:51 -0000
*************** AC_DEFINE_UNQUOTED(C_SWITCH_X_SITE,  ${C
*** 2536,2543 ****
   HAVE_X_WINDOWS above and your X include files aren't in a place
   that your compiler can find on its own, you might want to add
   "-I/..." or something similar.])
! AC_DEFINE_UNQUOTED(UNEXEC_SRC,       ${UNEXEC_SRC},
! 		   [Define to the unexec source file name.])
  
  if test "${HAVE_X_WINDOWS}" = "yes" ; then
    AC_DEFINE(HAVE_X_WINDOWS, 1,
--- 2536,2546 ----
   HAVE_X_WINDOWS above and your X include files aren't in a place
   that your compiler can find on its own, you might want to add
   "-I/..." or something similar.])
! case "${unexec}" in
!   unexelf.o)
!     AC_DEFINE(UNEXEC_SUPPORT_OBJC, 1, [Define to 1 if unexec supports ObjC.])
!   ;;
! esac
  
  if test "${HAVE_X_WINDOWS}" = "yes" ; then
    AC_DEFINE(HAVE_X_WINDOWS, 1,
*************** AH_BOTTOM([
*** 2607,2614 ****
  #define HAVE_MOUSE
  #endif
  
! /* Sadly for now, GNUstep dump does not work.  */
! #ifdef NS_IMPL_GNUSTEP
  #define CANNOT_DUMP
  #endif
  
--- 2610,2617 ----
  #define HAVE_MOUSE
  #endif
  
! /* Sadly for now, GNUstep dump does not work with all unexecs.  */
! #if defined (NS_IMPL_GNUSTEP) && !defined (UNEXEC_SUPPORT_OBJC)
  #define CANNOT_DUMP
  #endif
  

Re: Emacs on GNUstep (was: Release update)

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 04 May 2009 01:45:51 +0300, Yavor Doganov <yavor@gnu.org> said:

>> I just tried copying ObjC-related information in the .data section
>> not from the dumping process but from the original temacs file so
>> as to avoid some confusion during the startup time of the dumped
>> executable.

> Thank you very much!  This looks like a much simpler and more
> straightforward approach than trying to duplicate the whole logic
> using NSZone functions.

Perhaps the latter wouldn't help the GNUstep dumping problem because
the use of zones on unexmacosx.c is primarily for the problem that the
dumped heap area cannot be used as an ordinary heap in the dumped
executable, IIUC.  The crucial difference would rather be how
ObjC-related data is located in the executable: Mac OS X uses a
dedicated segment, but GNU/Linux uses the .data section that also
contains other read-write data.

>> It seems to work for me at least on GNU/Linux (Ubuntu 9.04).

> I confirm it works fine on gNewSense DeltaH (with fairly old
> GCC/GNUstep versions) and Debian GNU/kFreeBSD.

Thanks for testing.

> What a relief, I bet this fixes a lot of issues in the GNUstep port.

I hope so.  But it is quite unstable in my environment regardless of
dumping.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs on GNUstep

[Stefan Monnier]

> We can't simply remove CANNOT_DUMP because dumping requires unexelf.c
> currently.  The macro __ELF__ cannot be used here because it doesn't
> necessarily imply the use of unexelf.c (e.g., Solaris 10).

I think it's OK to say that the GNUStep port currently only "works" with
ELF systems.  In any case, experience has shown that CANNOT_DUMP doesn't
really work, so if people want to use GNUStep under Solaris, they're
just going to have to debug the corresponding dump process.  In this
context, it's worthwhile to keep/put the "#ifdef NS_IMPL_GNUSTEP" in
unexelf.c as a document that can be useful for hackers trying to make it
work on other unex*.c.


        Stefan

Re: Emacs on GNUstep

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 04 May 2009 09:45:40 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> We can't simply remove CANNOT_DUMP because dumping requires
>> unexelf.c currently.  The macro __ELF__ cannot be used here because
>> it doesn't necessarily imply the use of unexelf.c (e.g., Solaris
>> 10).

> I think it's OK to say that the GNUStep port currently only "works"
> with ELF systems.  In any case, experience has shown that
> CANNOT_DUMP doesn't really work, so if people want to use GNUStep
> under Solaris, they're just going to have to debug the corresponding
> dump process.  In this context, it's worthwhile to keep/put the
> "#ifdef NS_IMPL_GNUSTEP" in unexelf.c as a document that can be
> useful for hackers trying to make it work on other unex*.c.

Dumping "works", but the GNUstep port itself doesn't at least for me.
Maybe you want to show some warning message at the configure time not
only for non-ELF systems but also for the GNUstep port in general.
I've installed a change only for unexelf.c.  Please make remaining
changes as you think appropriate.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs on GNUstep

[Stefan Monnier]

> Dumping "works", but the GNUstep port itself doesn't at least for me.

Same for me.

> Maybe you want to show some warning message at the configure time not
> only for non-ELF systems but also for the GNUstep port in general.
> I've installed a change only for unexelf.c.  Please make remaining
> changes as you think appropriate.

Thanks.  I've removed the CANNOT_DUMP.


        Stefan