GNU bug report logs - #1171
ns-version-string

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1171 in the body.
You can then email your comments to 1171 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: ns-version-string
Date: Tue, 14 Oct 2008 21:12:07 -0400

Package: emacs,ns

emacs-version in the nextstep port says:

"GNU Emacs 23.0.60 (i686-pc-linux-gnu, *Step 9.0)"

The "*Step 9.0" piece would seem to be an extra version number used by
Emacs.app when it was separate from mainline Emacs. Now that it has
been merged, this should be removed, since the version number of Emacs
is sufficient.

Message #8 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1171 <at> debbugs.gnu.org
Subject: #1171 - ns-version-string - Emacs bug report logs
Date: Tue, 21 Oct 2008 09:31:21 -0400

I kind of agree with this, but is there another way to indicate which  
window system is being used?  It's useful for bug reports to know if  
it's X11 or NS (or Carbon, even though the info is sometimes redundant  
w/ 22/23 in that case).  What about just plain "*Step", or "NS  
Windowing", or someting like that?

Message #13 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1171 <at> debbugs.gnu.org
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Tue, 21 Oct 2008 11:52:26 -0400

> I kind of agree with this, but is there another way to indicate which window
> system is being used?  It's useful for bug reports to know if  it's X11 or
> NS (or Carbon, even though the info is sometimes redundant  w/ 22/23 in that
> case).  What about just plain "*Step", or "NS  Windowing", or someting
> like that?

The objection was about the "0.9" part, not the *Step part, so yes,
*Step is fine.


        Stefan

Message #16 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 1171 <at> debbugs.gnu.org, Adrian Robert <adrian.b.robert <at> gmail.com>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Tue, 21 Oct 2008 18:37:37 -0400

Stefan Monnier wrote:

> The objection was about the "0.9" part, not the *Step part, so yes,
> *Step is fine.

If there is a meaningful version number for the external GNUstep/Mac
components (analogous to gtk-version-string) against which Emacs was
built, that could also be printed. My complaint is indeed about the
hard-coded "0.9".

Message #21 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>, 1171 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 13:53:17 +0300

Glenn Morris wrote:
> 
> If there is a meaningful version number for the external GNUstep/Mac
> components (analogous to gtk-version-string) against which Emacs was
> built, that could also be printed.

For GNUstep, that would be the Base and GUI versions.  Ideally, the
GSBackend should also be detected and reported, but that's more
complicated as it has to happen at runtime.

For Mac OS X I don't have a clue, really.

The attached patch works for me, although it might not be entirely
correct.


2008-10-22  Yavor Doganov  <yavor <at> gnu.org>  (tiny change)

	* nsterm.m (syms_of_nsterm): Provide GNUstep Base/GUI versions as
	`ns-version-string'.


--- nsterm.m	21 окт 2008 15:50:42 +0300	1.32
+++ nsterm.m	22 окт 2008 13:17:21 +0300	
@@ -6382,7 +6382,22 @@
   /* TODO: try to move this back into lisp,  ns-win.el loaded too late
            right now */
   {
-    Lisp_Object args[3] = { intern ("ns-version-string"), build_string ("9.0"),
+#ifdef NS_IMPL_GNUSTEP
+  char gnustep_version[40];
+  snprintf (gnustep_version, sizeof (gnustep_version),
+	    "(GNUstep Base %u.%u.%u, GUI %u.%u.%u)",
+	    GNUSTEP_BASE_MAJOR_VERSION, GNUSTEP_BASE_MINOR_VERSION,
+	    GNUSTEP_BASE_SUBMINOR_VERSION,
+	    GNUSTEP_GUI_MAJOR_VERSION, GNUSTEP_GUI_MINOR_VERSION,
+	    GNUSTEP_GUI_SUBMINOR_VERSION);
+#endif
+    Lisp_Object args[3] = { intern ("ns-version-string"),
+#ifdef NS_IMPL_GNUSTEP
+			    build_string (gnustep_version),
+#else
+			    /* TODO: Something appropriate for Mac OS X.  */
+			    build_string ("9.0"),
+#endif
                     build_string ("NS Window system port version number.") };
     Fdefconst (Flist (3, args));
   }

Message #26 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 1171 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 08:29:03 -0400

Hi,

Thanks.  I actually have a patch that does this for both, just haven't  
had time to test yet.  I'll try a quick compile and check-in right now  
since there seems to be a lot of interest in this.




On Oct 22, 2008, at 6:53 AM, Yavor Doganov wrote:

> Glenn Morris wrote:
>>
>> If there is a meaningful version number for the external GNUstep/Mac
>> components (analogous to gtk-version-string) against which Emacs was
>> built, that could also be printed.
>
> For GNUstep, that would be the Base and GUI versions.  Ideally, the
> GSBackend should also be detected and reported, but that's more
> complicated as it has to happen at runtime.
>
> For Mac OS X I don't have a clue, really.
>
> The attached patch works for me, although it might not be entirely
> correct.
>
>
> 2008-10-22  Yavor Doganov  <yavor <at> gnu.org>  (tiny change)
>
> 	* nsterm.m (syms_of_nsterm): Provide GNUstep Base/GUI versions as
> 	`ns-version-string'.
>
>
> --- nsterm.m	21 окт 2008 15:50:42 +0300	1.32
> +++ nsterm.m	22 окт 2008 13:17:21 +0300	
> @@ -6382,7 +6382,22 @@
>   /* TODO: try to move this back into lisp,  ns-win.el loaded too late
>            right now */
>   {
> -    Lisp_Object args[3] = { intern ("ns-version-string"),  
> build_string ("9.0"),
> +#ifdef NS_IMPL_GNUSTEP
> +  char gnustep_version[40];
> +  snprintf (gnustep_version, sizeof (gnustep_version),
> +	    "(GNUstep Base %u.%u.%u, GUI %u.%u.%u)",
> +	    GNUSTEP_BASE_MAJOR_VERSION, GNUSTEP_BASE_MINOR_VERSION,
> +	    GNUSTEP_BASE_SUBMINOR_VERSION,
> +	    GNUSTEP_GUI_MAJOR_VERSION, GNUSTEP_GUI_MINOR_VERSION,
> +	    GNUSTEP_GUI_SUBMINOR_VERSION);
> +#endif
> +    Lisp_Object args[3] = { intern ("ns-version-string"),
> +#ifdef NS_IMPL_GNUSTEP
> +			    build_string (gnustep_version),
> +#else
> +			    /* TODO: Something appropriate for Mac OS X.  */
> +			    build_string ("9.0"),
> +#endif
>                     build_string ("NS Window system port version  
> number.") };
>     Fdefconst (Flist (3, args));
>   }

Message #31 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 1171 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 09:14:58 -0400

> If there is a meaningful version number for the external GNUstep/Mac
> components (analogous to gtk-version-string) against which Emacs was
> built, that could also be printed. My complaint is indeed about the
> hard-coded "0.9".

OK, I've changed it to output a version number determined compile-time  
from the toolkit, currently one of:

gnustep-gui-###
apple-appkit-###

Yavor, if you decide it's better to report the GNUstep base version  
also, you can use NSFoundationVersionNumber for OS X.

There are four other files where I replaced 9.0 with 23.0.60 or  
variants of it.  Eventually it would be nice to do this automatically  
with autoconf.  In this case it is important NOT to include the  
extra .# build number that emacs' build system generates.  This, by  
itself, *should* be used for the CFBundleVersion in the Cocoa  
Info.plist however.

nextstep/Cocoa/Emacs.base/Contents/Info.plist
nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/ 
InfoPlist.strings
nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop
nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist

Message #34 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>, 1171 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 13:05:14 -0400

Adrian Robert wrote:

> There are four other files where I replaced 9.0 with 23.0.60 or  
> variants of it.  Eventually it would be nice to do this automatically  
> with autoconf. 

M-x set-version from admin/admin.el does this kind of thing.
I can add entries for the places you just added at some point.

> In this case it is important NOT to include the extra .# build
> number that emacs' build system generates. This, by itself, *should*
> be used for the CFBundleVersion in the Cocoa Info.plist however.
>
> nextstep/Cocoa/Emacs.base/Contents/Info.plist
> nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/ 
> InfoPlist.strings
> nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop
> nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist

Message #39 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>, Glenn Morris <rgm <at> gnu.org>,
        1171 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Thu, 23 Oct 2008 00:11:53 +0300

Adrian Robert wrote:
> 
> OK, I've changed it to output a version number determined
> compile-time from the toolkit

Thanks, it looks very good and works fine on GNUstep.  However, there
seems to be something inconsistent (unrelated to your changes):

In GNU Emacs 23.0.60 (i686-pc-linux-gnu, NS gnustep-gui-0.12.0)
 of 2008-10-22 on gana.yavor.doganov.org
Windowing system distributor `GNU', version 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48

On GNU and Unix-like systems GNUstep uses X, so I find this very
strange and of course not informative at all.  I haven't checked why
`x-server-version' is so bizarre in this case, but probably you know
already.

> Yavor, if you decide

Well, I can't decide anything since I'm not an Emacs developer ;-)

> it's better to report the GNUstep base version  
> also, you can use NSFoundationVersionNumber for OS X.

GNUstep Base is fairly stable and complete, and I guess so is Apple's
FoundationKit (which is the main reason why gnustep-base is in such a
shape, of course).  I guess the reasoning to include it in
`emacs-version' is if it helps with bug reports.  Although there were
some very nasty bugs in -base (even recently), it is more or less
mature.  Time will tell, I think.

> nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop

IMHO this is entirely useless for GNUstep, because:

1) Typically, GNUstep users do not use freedesktop.org-aware
   environments such as GNOME/KDE/Xfce.
2) Even in the rare cases when they do, the .desktop files must be in
   $(datadir)/applications (or ~/.local/share/applications) in order
   to be parsed, loaded and to show up in the menus.
3) The file is invalid (this can be fixed, certainly, but it is a
   general problem with all standard GNUstep apps where the pl2link
   tool generates broken .desktop files and puts them in the wrong
   place).

Message #44 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: 1171 <at> debbugs.gnu.org
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 18:43:34 -0400

On Oct 22, 2008, at 5:11 PM, Yavor Doganov wrote:

> Adrian Robert wrote:
>>
>> OK, I've changed it to output a version number determined
>> compile-time from the toolkit
>
> Thanks, it looks very good and works fine on GNUstep.  However, there
> seems to be something inconsistent (unrelated to your changes):
>
> In GNU Emacs 23.0.60 (i686-pc-linux-gnu, NS gnustep-gui-0.12.0)
> of 2008-10-22 on gana.yavor.doganov.org
> Windowing system distributor `GNU', version  
> 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48

How do you generate this output?  And do you know what code is  
responsible?


> On GNU and Unix-like systems GNUstep uses X, so I find this very
> strange and of course not informative at all.  I haven't checked why
> `x-server-version' is so bizarre in this case, but probably you know
> already.

x-server-version should be returning identical to ns-version-string  
("gnustep-gui-0.12.0"
 in this case), which it does here.  (Don't be fooled by the name of  
the function, it does not refer to X11.)  If not it is a weird bug.   
If you could put a println in ns_appkit_version() in nsfns.m and see  
if it IS indeed being called and if it IS generating that weird  
string, it would help track it down.


>> nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop
>
> IMHO this is entirely useless for GNUstep, because:
>
> 1) Typically, GNUstep users do not use freedesktop.org-aware
>   environments such as GNOME/KDE/Xfce.
> 2) Even in the rare cases when they do, the .desktop files must be in
>   $(datadir)/applications (or ~/.local/share/applications) in order
>   to be parsed, loaded and to show up in the menus.
> 3) The file is invalid (this can be fixed, certainly, but it is a
>   general problem with all standard GNUstep apps where the pl2link
>   tool generates broken .desktop files and puts them in the wrong
>   place).

OK, I'll think about dropping the file.


thanks,
Adrian

Message #49 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>, 1171 <at> debbugs.gnu.org
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Thu, 23 Oct 2008 02:20:04 +0300

Adrian Robert wrote:
> 
> > Windowing system distributor `GNU', version  
> > 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48
> 
> How do you generate this output?

With M-x report-emacs-bug -- I thought the whole point of this
discussion/bug was inluding useful information in initial bug reports,
without the necessity to ask the bug reporter about additional
details.

Anyway, I don't have strong feelings about this -- reporting the
gnustep-gui version is good enough.

> And do you know what code is responsible?

It's in lisp/mai/emacsbug.el.

> x-server-version should be returning identical to ns-version-string

That's wrong for GNUstep on a GNU/{Linux,Hurd,kFreeBSD} system where
presumably the desirable thing is to report the X server version (in
fact it would be much better to report the GNUstep backend, or both).
Furthermore, although GNUstep has minimal WM support and theoretically
Emacs.app can run under plain X (haven't tried that, personally), it
is a bit inappropriate to call GNU a "Windowing system distributor".
GNUstep provides some primitives, but really relies on X to be
available and running.

> If you could put a println in ns_appkit_version() in nsfns.m and see  
> if it IS indeed being called and if it IS generating that weird  
> string, it would help track it down.

Thanks, I'll hopefully do that tomorrow.

Message #52 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>, 1171 <at> debbugs.gnu.org,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 20:48:16 -0400

Adrian Robert wrote:

> In this case it is important NOT to include the extra .# build
> number that emacs' build system generates. This, by itself, *should*
> be used for the CFBundleVersion in the Cocoa Info.plist however.

You mean in nextstep/Cocoa/Emacs.base/Contents/Info.plist, the
CFBundleVersion string that is currently hard-coded at "9.0" should be
replaced by the Emacs build number ("1", "2", ...), and so get changed
every time Emacs gets rebuilt? I don't see how you would do this.

Actually, this number doesn't even seem to exist in the nextstep port,
since it does not get dumped.

Message #55 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1171 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>,
        Yavor Doganov <yavor <at> gnu.org>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 21:02:51 -0400

Yavor Doganov wrote:

>> nextstep/GNUstep/Emacs.base/Resources/Emacs.desktop
>
> IMHO this is entirely useless for GNUstep, because:
[...]
> 2) Even in the rare cases when they do, the .desktop files must be in
>    $(datadir)/applications (or ~/.local/share/applications) in order
>    to be parsed, loaded and to show up in the menus.

The top-level Makefile.in has a rule (install-etc) which installs the
file etc/emacs.desktop in the right place. This could be
copied/adapted for the GNUstep version.

Message #60 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1171 <at> debbugs.gnu.org, Yavor Doganov <yavor <at> gnu.org>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 22 Oct 2008 21:16:05 -0400

>> 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48
> ("gnustep-gui-0.12.0"

The first line above seems to list the ascii codes of the second line.


        Stefan

Message #65 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 1171 <at> debbugs.gnu.org,
        Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Yavor Doganov <yavor <at> gnu.org>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 12 Nov 2008 15:34:07 +0200

At Wed, 22 Oct 2008 21:16:05 -0400,
Stefan Monnier wrote:
> 
> >> 103.110.117.115.116.101.112.45.103.117.105.45.48.46.49.50.46.48
> > ("gnustep-gui-0.12.0"
> 
> The first line above seems to list the ascii codes of the second line.

Yes, it looks like this this code in emacsbug.el

	    (insert "Windowing system distributor `" (x-server-vendor)
                    "', version "
		    (mapconcat 'number-to-string (x-server-version) ".") "\n")

really expects x-server-version to be a number.

There are more problems with ns-version-string:

1) It shows the FQDN, which some users might find inappropriate.  At
   least this is not consistent with the other flavors.

2) It doesn't show the host on which Emacs was built, but the host on
   which it is currently running, e.g.

GNU Emacs 23.0.60 (i486-pc-linux-gnu, NS gnustep-gui-0.12.0)
 of 2008-11-12 on tzotzolana.yavor.doganov.org, modified for gNewSense

This was built on a different host and I installed it on tzotzolana as
a binary (*.deb) package from an APT repository.

3) The date is also wrong, and shows the current date, not the date
   Emacs was built.  (The actual build date in the above example is
   2008-10-27). I guess this is a nasty consequence of CANNOT_DUMP...

Message #70 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 1171 <at> debbugs.gnu.org
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, Yavor Doganov <yavor <at> gnu.org>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 12 Nov 2008 11:01:57 -0500

> Yes, it looks like this this code in emacsbug.el

> 	    (insert "Windowing system distributor `" (x-server-vendor)
>                     "', version "
> 		    (mapconcat 'number-to-string (x-server-version) ".") "\n")

> really expects x-server-version to be a number.

Actually a list of numbers.

> There are more problems with ns-version-string:
> 1) It shows the FQDN, which some users might find inappropriate.  At
>    least this is not consistent with the other flavors.
> 2) It doesn't show the host on which Emacs was built, but the host on
>    which it is currently running, e.g.
> GNU Emacs 23.0.60 (i486-pc-linux-gnu, NS gnustep-gui-0.12.0)
>  of 2008-11-12 on tzotzolana.yavor.doganov.org, modified for gNewSense
> This was built on a different host and I installed it on tzotzolana as
> a binary (*.deb) package from an APT repository.
> 3) The date is also wrong, and shows the current date, not the date
>    Emacs was built.  (The actual build date in the above example is
>    2008-10-27). I guess this is a nasty consequence of CANNOT_DUMP...

These all seem to be direct consequences of using CANNOT_DUMP and
probably do not manifest under Cocoa.  I wouldn't worry too much about
it (better fix the underlying problem and get dumping to work for
GNUstep).


        Stefan

Message #75 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Yavor Doganov <yavor <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 1171 <at> debbugs.gnu.org, Adrian Robert <adrian.b.robert <at> gmail.com>,
        Yavor Doganov <yavor <at> gnu.org>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 12 Nov 2008 21:11:16 +0200

Stefan Monnier wrote:
> 
> These all seem to be direct consequences of using CANNOT_DUMP and
> probably do not manifest under Cocoa.

Yes, as can be observed by the reports of these users.

> I wouldn't worry too much about it

Sure, the only possible problem is the confusion in bug reports that
the wrong date may cause.  But if Emacs developers remember that it's
bogus, there is no problem.

> (better fix the underlying problem and get dumping to work for
> GNUstep).

Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs?
Or a combination of these?

Message #80 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Yavor Doganov <yavor <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 1171 <at> debbugs.gnu.org
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 12 Nov 2008 14:19:10 -0500

On Nov 12, 2008, at 2:11 PM, Yavor Doganov wrote:

> Stefan Monnier wrote:
>>
>> (better fix the underlying problem and get dumping to work for
>> GNUstep).
>
> Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs?
> Or a combination of these?


Unknown, hopefully just the last one, or the last two.  If someone  
(you?) who is compiling / testing on GNUstep could get together a  
description of the failure when dumping is attempted (probably a stack  
trace of the crash when the dumped emacs is run), and post that to gnustep-dev <at> gnu.org 
, that would be a good start to learning more / starting on a solution.

Adrian

Message #85 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 1171 <at> debbugs.gnu.org
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>, Yavor Doganov <yavor <at> gnu.org>
Subject: Re: bug#1171: #1171 - ns-version-string - Emacs bug report logs
Date: Wed, 12 Nov 2008 14:48:19 -0500

>> I wouldn't worry too much about it
> Sure, the only possible problem is the confusion in bug reports that
> the wrong date may cause.  But if Emacs developers remember that it's
> bogus, there is no problem.

Well, it is not completely irrelelvant, but fixing it is probably more
trouble than will be incurred because of confusion.

>> (better fix the underlying problem and get dumping to work for GNUstep).
> Does this require changes in the GNU ObjC runtime, GNUstep, or Emacs?
> Or a combination of these?

It should only require changes in Emacs, normally.
But the main thing it requires is someone to attack the problem.


        Stefan

Message #88 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 1171 <at> debbugs.gnu.org
Cc: Adrian Robert <adrian.b.robert <at> gmail.com>
Subject: Re: bug#1171: ns-version-string
Date: Thu, 11 Dec 2008 18:46:42 -0500

Please consider fixing the NS implementation of x-server-version to
return a list of three integers, as it is documented to do (xfns.c,
w32fns.c).

It's getting a bit ridiculous seeing all the Emacs.App bug reports with

  Windowing system distributor `Apple', version  
  97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53
  configured using `configure  '--with-ns''

(Again, this comes from M-x report-emacs-bug.)

Thanks.

Message #93 received at 1171 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 1171 <at> debbugs.gnu.org
Subject: Re: bug#1171: ns-version-string
Date: Wed, 31 Dec 2008 17:03:29 +0200

On Dec 12, 2008, at 1:46 AM, Glenn Morris wrote:

>
> Please consider fixing the NS implementation of x-server-version to
> return a list of three integers, as it is documented to do (xfns.c,
> w32fns.c).

Done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.