GNU bug report logs - #39883
28.0.50; macOS blank frame

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 39883 in the body.
You can then email your comments to 39883 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philippe Spiesser <spiesser.philippe <at> orange.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; macOS blank frame
Date: Tue, 3 Mar 2020 10:42:28 +0100

[Message part 1 (text/plain, inline)]

Hello

Every week, after updating local repositories (git pull), I build Emacs 
27.0.60 and
Emacs 28.0.50.
Since the 14 of February 2020, everything is OK with Emacs 27.0.60 but
Emacs 28 starts in a window with a blank frame without displaying any
character. Keyboard is active and I quit with Ctrl-x Ctrl-c.

Yet, everything is Ok when running same Emacs 28 in a terminal with command
.../Emacs.app/Contents/MacOS/Emacs -nw

On the other hand, everything is OK with Emacs 27.0.50

Thinking that it was a macOS problem, I look at the log for the files
src/ns* and I downgrade the repository with the command
git checkout f674c905dc98a4617c40c4bc115462b4ad2ebfc2
and rebuild Emacs 28. So eveything is OK

I can't explain why updates after this commit cause this behavior.


In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin17.7.0, NS 
appkit-1561.61 Version 10.13.6 (Build 17G11023))
of 2020-03-02 built on spungen.home
Repository revision: f674c905dc98a4617c40c4bc115462b4ad2ebfc2
Repository branch: HEAD
Windowing system distributor 'Apple', version 10.3.1561
System Description: Mac OS X 10.13.6

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Undo
Mark set
Undo
Making completion list...

Configured using:
'configure --prefix=/usr/local/Applications --with-ns=yes'

Configured features:
RSVG DBUS GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
NS MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
value of $LANG: fr_FR.UTF-8
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:

None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads dbusbind kqueue cocoa ns lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 45019 7861)
(symbols 48 5930 1)
(strings 32 15241 1747)
(string-bytes 1 505908)
(vectors 16 10150)
(vector-slots 8 126077 6750)
(floats 8 19 44)
(intervals 56 208 0)
(buffers 1000 12))


-- 

	Philippe Spiesser

[Message part 2 (text/html, inline)]

Message #8 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philippe Spiesser <spiesser.philippe <at> orange.fr>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Tue, 3 Mar 2020 20:04:18 +0100 (CET)

On Tue, Mar 03, 2020 at 10:42:28AM +0100, Philippe Spiesser wrote:
> Hello
> 
> Every week, after updating local repositories (git pull), I build Emacs
> 27.0.60 and
> Emacs 28.0.50.
> Since the 14 of February 2020, everything is OK with Emacs 27.0.60 but
> Emacs 28 starts in a window with a blank frame without displaying any
> character. Keyboard is active and I quit with Ctrl-x Ctrl-c.
> 
> Yet, everything is Ok when running same Emacs 28 in a terminal with command
> .../Emacs.app/Contents/MacOS/Emacs -nw
> 
> On the other hand, everything is OK with Emacs 27.0.50
> 
> Thinking that it was a macOS problem, I look at the log for the files
> src/ns* and I downgrade the repository with the command
> git checkout f674c905dc98a4617c40c4bc115462b4ad2ebfc2
> and rebuild Emacs 28. So eveything is OK
> 
> I can't explain why updates after this commit cause this behavior.

Hi Philippe,

I pushed a possible fix for this to the master repository last night.
Could you please try it again?
-- 
Alan Third

Message #11 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Philippe Spiesser <spiesser.philippe <at> orange.fr>
To: Alan Third <alan <at> idiocy.org>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Wed, 4 Mar 2020 13:18:03 +0100

[Message part 1 (text/plain, inline)]

Le 03/03/2020 à 20:04, Alan Third a écrit :
> On Tue, Mar 03, 2020 at 10:42:28AM +0100, Philippe Spiesser wrote:
>> Hello
>>
>> Every week, after updating local repositories (git pull), I build Emacs
>> 27.0.60 and
>> Emacs 28.0.50.
>> Since the 14 of February 2020, everything is OK with Emacs 27.0.60 but
>> Emacs 28 starts in a window with a blank frame without displaying any
>> character. Keyboard is active and I quit with Ctrl-x Ctrl-c.
>>
>> Yet, everything is Ok when running same Emacs 28 in a terminal with command
>> .../Emacs.app/Contents/MacOS/Emacs -nw
>>
>> On the other hand, everything is OK with Emacs 27.0.50
>>
>> Thinking that it was a macOS problem, I look at the log for the files
>> src/ns* and I downgrade the repository with the command
>> git checkout f674c905dc98a4617c40c4bc115462b4ad2ebfc2
>> and rebuild Emacs 28. So eveything is OK
>>
>> I can't explain why updates after this commit cause this behavior.
> Hi Philippe,
>
> I pushed a possible fix for this to the master repository last night.
> Could you please try it again?

Hi,

I rebuild Emacs this morning with last commits, but now, no window is 
displayed and Emacs crashes. I join the trace at this mail.

-- 

	Philippe Spiesser

[Message part 2 (text/html, inline)]

[emacs28-crash.txt (text/plain, attachment)]

Message #14 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philippe Spiesser <spiesser.philippe <at> orange.fr>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Wed, 4 Mar 2020 21:56:04 +0100 (CET)

On Wed, Mar 04, 2020 at 01:18:03PM +0100, Philippe Spiesser wrote:
> I rebuild Emacs this morning with last commits, but now, no window is
> displayed and Emacs crashes. I join the trace at this mail.

Thanks for trying it, I think I know what I’ve done wrong.

I’ve pushed another change to master, can you please try again?
-- 
Alan Third

Message #17 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Philippe Spiesser <spiesser.philippe <at> orange.fr>
To: Alan Third <alan <at> idiocy.org>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Thu, 5 Mar 2020 11:37:24 +0100

[Message part 1 (text/plain, inline)]

Le 04/03/2020 à 21:56, Alan Third a écrit :
> On Wed, Mar 04, 2020 at 01:18:03PM +0100, Philippe Spiesser wrote:
>> I rebuild Emacs this morning with last commits, but now, no window is
>> displayed and Emacs crashes. I join the trace at this mail.
> Thanks for trying it, I think I know what I’ve done wrong.
>
> I’ve pushed another change to master, can you please try again?

Again, I rebuild Emacs and now, you thought right, this problem is solved.

Thank you.

-- 

	Philippe Spiesser

[Message part 2 (text/html, inline)]

Message #22 received at 39883-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philippe Spiesser <spiesser.philippe <at> orange.fr>
Cc: 39883-done <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Thu, 5 Mar 2020 18:16:37 +0100 (CET)

On Thu, Mar 05, 2020 at 11:37:24AM +0100, Philippe Spiesser wrote:
> Le 04/03/2020 à 21:56, Alan Third a écrit :
> > On Wed, Mar 04, 2020 at 01:18:03PM +0100, Philippe Spiesser wrote:
> > > I rebuild Emacs this morning with last commits, but now, no window is
> > > displayed and Emacs crashes. I join the trace at this mail.
> > Thanks for trying it, I think I know what I’ve done wrong.
> > 
> > I’ve pushed another change to master, can you please try again?
> 
> Again, I rebuild Emacs and now, you thought right, this problem is solved.

Thanks for the confirmation. I’ll close this bug report now.
-- 
Alan Third

Message #25 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: 39883 <at> debbugs.gnu.org
Subject: Re: 28.0.50; macOS blank frame
Date: Sun, 29 Mar 2020 23:17:09 +0530

Hi,

I’m still experiencing the problem. I’ve built emacs git revision 1276c8e10 with following configure flags:

configure flags: --prefix=/nix/store/g1hsxv43gq0jyh3wrm7lmc78z3q1nfbm-emacs-git-20200329.0 --disable-build-details --with-modules --with-ns --disable-ns-self-cont
ained --with-json --with-pdumper

Following is the screenshot of `emacs -Q’ demonstrating the issue in case this bug report is of a different issue:

https://i.imgur.com/YuaL3z3.png

Please let me know if you need any further information from me.

Thanks!
--
Ashish | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0

“Sometimes even to live is an act of courage.” (Seneca)

Message #28 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Ashish SHUKLA <ashish.is <at> lostca.se>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Sun, 29 Mar 2020 20:13:54 +0200 (CEST)

On Sun, Mar 29, 2020 at 11:17:09PM +0530, Ashish SHUKLA wrote:
> Hi,
> 
> I’m still experiencing the problem. I’ve built emacs git revision 1276c8e10 with following configure flags:
> 
> configure flags: --prefix=/nix/store/g1hsxv43gq0jyh3wrm7lmc78z3q1nfbm-emacs-git-20200329.0 --disable-build-details --with-modules --with-ns --disable-ns-self-cont
> ained --with-json --with-pdumper
> 
> Following is the screenshot of `emacs -Q’ demonstrating the issue in case this bug report is of a different issue:
> 
> https://i.imgur.com/YuaL3z3.png
> 
> Please let me know if you need any further information from me.

Hi, thanks for the report. What version of macOS are you using? Is
this a Nix system?
-- 
Alan Third

Message #31 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: Alan Third <alan <at> idiocy.org>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Sun, 29 Mar 2020 23:51:27 +0530

> On Mar 29, 2020, at 23:43, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Sun, Mar 29, 2020 at 11:17:09PM +0530, Ashish SHUKLA wrote:
>> Hi,
>> 
>> I’m still experiencing the problem. I’ve built emacs git revision 1276c8e10 with following configure flags:
>> 
>> configure flags: --prefix=/nix/store/g1hsxv43gq0jyh3wrm7lmc78z3q1nfbm-emacs-git-20200329.0 --disable-build-details --with-modules --with-ns --disable-ns-self-cont
>> ained --with-json --with-pdumper
>> 
>> Following is the screenshot of `emacs -Q’ demonstrating the issue in case this bug report is of a different issue:
>> 
>> https://i.imgur.com/YuaL3z3.png
>> 
>> Please let me know if you need any further information from me.
> 
> Hi, thanks for the report. What version of macOS are you using? Is
> this a Nix system?

macOS Catalina 10.15.3

λ uname -a
Darwin sthelena.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan  9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64

And running nix-darwin with nix-emacs-overlay[1]

References:
[1] https://github.com/nix-community/emacs-overlay

Thanks!
--
Ashish | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0

“Sometimes even to live is an act of courage.” (Seneca)

Message #34 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: Alan Third <alan <at> idiocy.org>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Mon, 30 Mar 2020 01:24:59 +0530

On 2020-03-29 23:51, Ashish SHUKLA wrote:
>> On Mar 29, 2020, at 23:43, Alan Third <alan <at> idiocy.org> wrote:
>> 
>> On Sun, Mar 29, 2020 at 11:17:09PM +0530, Ashish SHUKLA wrote:
>>> Hi,
>>> 
>>> I’m still experiencing the problem. I’ve built emacs git revision 
>>> 1276c8e10 with following configure flags:
>>> 
>>> configure flags: 
>>> --prefix=/nix/store/g1hsxv43gq0jyh3wrm7lmc78z3q1nfbm-emacs-git-20200329.0 
>>> --disable-build-details --with-modules --with-ns 
>>> --disable-ns-self-cont
>>> ained --with-json --with-pdumper
>>> 
>>> Following is the screenshot of `emacs -Q’ demonstrating the issue in 
>>> case this bug report is of a different issue:
>>> 
>>> https://i.imgur.com/YuaL3z3.png
>>> 
>>> Please let me know if you need any further information from me.
>> 
>> Hi, thanks for the report. What version of macOS are you using? Is
>> this a Nix system?
> 
> macOS Catalina 10.15.3
> 
> λ uname -a
> Darwin sthelena.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan  9
> 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64
> 
> And running nix-darwin with nix-emacs-overlay[1]

It seems like building with same configure flags, but outside nix causes 
issue to disappear. So, maybe it's something to do with the nix 
environment.

Thanks!
--
Ashish

“There was truth and there was untruth, and if you clung to the truth 
even against the whole world, you were not mad.”
       -- George Orwell, "Nineteen Eighty-Four"

Message #37 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Ashish SHUKLA <ashish.is <at> lostca.se>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Tue, 31 Mar 2020 18:52:37 +0200 (CEST)

On Mon, Mar 30, 2020 at 01:24:59AM +0530, Ashish SHUKLA wrote:
> 
> It seems like building with same configure flags, but outside nix causes
> issue to disappear. So, maybe it's something to do with the nix environment.

Nix used to use headers from macOS 10.10 or thereabouts, even on newer
versions of macOS. I don’t know if this is still the case. The problem
is that our compile‐time feature detection code detects the wrong
features as a result.

Could you perhaps try changing src/nsterm.h so that this:

#define NS_DRAW_TO_BUFFER 1

is always defined? You should be able to just delete or comment out
the #if and #endif.

I don’t know how easy that is for you with Nix, hopefully it’s pretty
straight forward.
-- 
Alan Third

Message #40 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: Alan Third <alan <at> idiocy.org>, 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Wed, 1 Apr 2020 09:51:37 +0530

[Message part 1 (text/plain, inline)]

On 3/31/20 10:22 PM, Alan Third wrote:
> On Mon, Mar 30, 2020 at 01:24:59AM +0530, Ashish SHUKLA wrote:
>>
>> It seems like building with same configure flags, but outside nix causes
>> issue to disappear. So, maybe it's something to do with the nix environment.
> 
> Nix used to use headers from macOS 10.10 or thereabouts, even on newer
> versions of macOS. I don’t know if this is still the case. The problem
> is that our compile‐time feature detection code detects the wrong
> features as a result.
> 
> Could you perhaps try changing src/nsterm.h so that this:
> 
> #define NS_DRAW_TO_BUFFER 1
> 
> is always defined? You should be able to just delete or comment out
> the #if and #endif.
> 
> I don’t know how easy that is for you with Nix, hopefully it’s pretty
> straight forward.
> 

Hi Alan,

It turns out after deleting those lines the problem is resolved. I will
investigate on Nix side, what went wrong.

Thank you, and I really appreciate your help.

-- 
Ashish SHUKLA | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0

“Indians will believe anything told to them anyway. And besides for the
doubters, there's $%^#~@~~ CARRIER LOST” (Joseph Koshy)

[signature.asc (application/pgp-signature, attachment)]

Message #43 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Ashish SHUKLA <ashish.is <at> lostca.se>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Wed, 1 Apr 2020 20:53:10 +0200 (CEST)

On Wed, Apr 01, 2020 at 09:51:37AM +0530, Ashish SHUKLA wrote:
> On 3/31/20 10:22 PM, Alan Third wrote:
> > On Mon, Mar 30, 2020 at 01:24:59AM +0530, Ashish SHUKLA wrote:
> >>
> >> It seems like building with same configure flags, but outside nix causes
> >> issue to disappear. So, maybe it's something to do with the nix environment.
> > 
> > Nix used to use headers from macOS 10.10 or thereabouts, even on newer
> > versions of macOS. I don’t know if this is still the case. The problem
> > is that our compile‐time feature detection code detects the wrong
> > features as a result.
> > 
> > Could you perhaps try changing src/nsterm.h so that this:
> > 
> > #define NS_DRAW_TO_BUFFER 1
> > 
> > is always defined? You should be able to just delete or comment out
> > the #if and #endif.
> > 
> > I don’t know how easy that is for you with Nix, hopefully it’s pretty
> > straight forward.
> > 
> 
> Hi Alan,
> 
> It turns out after deleting those lines the problem is resolved. I will
> investigate on Nix side, what went wrong.

It’s quite possible we’ll need to provide some sort of option to force
this, or to do run‐time feature detection. I don’t much fancy trying
to code up the runtime detection for this feature, but if we need it
we need it.

For my own future reference: perhaps we should do a test in
./configure rather than rely on the contents of the headers?
-- 
Alan Third

Message #46 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: Alan Third <alan <at> idiocy.org>, 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Thu, 2 Apr 2020 11:49:45 +0530

[Message part 1 (text/plain, inline)]

On 4/2/20 12:23 AM, Alan Third wrote:
> On Wed, Apr 01, 2020 at 09:51:37AM +0530, Ashish SHUKLA wrote:
>> On 3/31/20 10:22 PM, Alan Third wrote:
>>> On Mon, Mar 30, 2020 at 01:24:59AM +0530, Ashish SHUKLA wrote:
>>>>
>>>> It seems like building with same configure flags, but outside nix causes
>>>> issue to disappear. So, maybe it's something to do with the nix environment.
>>>
>>> Nix used to use headers from macOS 10.10 or thereabouts, even on newer
>>> versions of macOS. I don’t know if this is still the case. The problem
>>> is that our compile‐time feature detection code detects the wrong
>>> features as a result.
>>>
>>> Could you perhaps try changing src/nsterm.h so that this:
>>>
>>> #define NS_DRAW_TO_BUFFER 1
>>>
>>> is always defined? You should be able to just delete or comment out
>>> the #if and #endif.
>>>
>>> I don’t know how easy that is for you with Nix, hopefully it’s pretty
>>> straight forward.
>>>
>>
>> Hi Alan,
>>
>> It turns out after deleting those lines the problem is resolved. I will
>> investigate on Nix side, what went wrong.
> 
> It’s quite possible we’ll need to provide some sort of option to force
> this, or to do run‐time feature detection. I don’t much fancy trying
> to code up the runtime detection for this feature, but if we need it
> we need it.
> 
> For my own future reference: perhaps we should do a test in
> ./configure rather than rely on the contents of the headers?
> 

That definitely seems more foolproof. Let me know if you like me to test
your diff.

Thanks!
-- 
Ashish SHUKLA

[signature.asc (application/pgp-signature, attachment)]

Message #49 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Ashish SHUKLA <ashish.is <at> lostca.se>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Sat, 11 Apr 2020 14:29:25 +0100

[Message part 1 (text/plain, inline)]

On Thu, Apr 02, 2020 at 11:49:45AM +0530, Ashish SHUKLA wrote:
> On 4/2/20 12:23 AM, Alan Third wrote:
> > 
> > It’s quite possible we’ll need to provide some sort of option to force
> > this, or to do run‐time feature detection. I don’t much fancy trying
> > to code up the runtime detection for this feature, but if we need it
> > we need it.
> 
> That definitely seems more foolproof. Let me know if you like me to test
> your diff.

Can you please try the attached patches? The fix for this is built on
the one for fixing frame resizing. Ultimately they should both end up
on master, so I didn’t want to make separate branches and have to
rework them later.

You may have to set this CFLAG to enable the changes:

    -DMAC_OS_X_VERSION_MAX_ALLOWED=101500
-- 
Alan Third

[0001-Allow-dynamic-choice-of-drawing-path-on-NS-bug-39883.patch (text/plain, attachment)]

[v5-0001-Fix-NS-frame-resizing-issues-bug-40200-bug-28872.patch (text/plain, attachment)]

Message #52 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: Alan Third <alan <at> idiocy.org>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Sun, 12 Apr 2020 11:54:53 +0530

On Apr 11, 2020, at 18:59, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Thu, Apr 02, 2020 at 11:49:45AM +0530, Ashish SHUKLA wrote:
>> On 4/2/20 12:23 AM, Alan Third wrote:
>>> 
>>> It’s quite possible we’ll need to provide some sort of option to force
>>> this, or to do run‐time feature detection. I don’t much fancy trying
>>> to code up the runtime detection for this feature, but if we need it
>>> we need it.
>> 
>> That definitely seems more foolproof. Let me know if you like me to test
>> your diff.
> 
> Can you please try the attached patches? The fix for this is built on
> the one for fixing frame resizing. Ultimately they should both end up
> on master, so I didn’t want to make separate branches and have to
> rework them later.
> 
> You may have to set this CFLAG to enable the changes:
> 
>    -DMAC_OS_X_VERSION_MAX_ALLOWED=101500
> -- 
> Alan Third
> <0001-Allow-dynamic-choice-of-drawing-path-on-NS-bug-39883.patch><v5-0001-Fix-NS-frame-resizing-issues-bug-40200-bug-28872.patch>

Hi

Without setting CFLAGS following error occurred:

==================================================================
  CC       image.o
  CC       json.o
  CC       nsterm.o
  CC       nsfns.o
  CC       nsmenu.o
  CC       nsselect.o
  CC       nsimage.o
  CC       macfont.o
  CC       terminfo.o
  CC       lastfile.o
nsterm.m:6300:21: error: use of undeclared identifier 'drawingBuffer'
  CGContextRelease (drawingBuffer);
                    ^
1 error generated.
make[1]: *** [Makefile:404: nsterm.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/private/tmp/nix-build-emacs-git-20200412.0.drv-0/source/src'
make: *** [Makefile:424: src] Error 2
builder for '/nix/store/ipkfwl0i5xq2006g1j04nsh510y8snvn-emacs-git-20200412.0.drv' failed with exit code 2
cannot build derivation '/nix/store/0rq2gm9527ynz2f97xmlx4wpk5hpkly7-emacs-git-with-packages-20200412.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/qkiy84nhzmzkkpkz9ayh6fivy1lp8s9j-hm_.configzsh.zshrc.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/qz9gbgh031nlih9knmcbh8dk8g7c85q1-home-manager-files.drv': 1 dependencies couldn't be built
==================================================================

With CFLAGS set:

==================================================================
1 warning generated.
  CC       lastfile.o
In file included from <built-in>:360:
<command line>:4:9: warning: 'MAC_OS_X_VERSION_MAX_ALLOWED' macro redefined [-Wmacro-redefined]
#define MAC_OS_X_VERSION_MAX_ALLOWED 101500
        ^
<command line>:3:9: note: previous definition is here
#define MAC_OS_X_VERSION_MAX_ALLOWED 101200
        ^
nsterm.m:1148:8: error: use of undeclared identifier 'self'
  if ([self wantsUpdateLayer])
       ^
nsterm.m:1185:8: error: use of undeclared identifier 'self'
  if ([self wantsUpdateLayer])
       ^
nsterm.m:1234:12: error: use of undeclared identifier 'self'
      if ([self wantsUpdateLayer])
           ^
1 warning generated.
nsterm.m:1294:8: error: use of undeclared identifier 'self'
  if ([self wantsUpdateLayer])
111       ^ warning
 warning warning generated generated generated1.
.
.
1 warning generated warning.
 generated.
1 warning generated.
1 warning and 4 errors generated.
make[1]: *** [Makefile:404: nsterm.o] Error 1
make[1]: Leaving directory '/private/tmp/nix-build-emacs-git-20200412.0.drv-0/source/src'
make: *** [Makefile:424: src] Error 2
builder for '/nix/store/xf0x6mcjm6v4wn5zy0hnaicln7ipl9xc-emacs-git-20200412.0.drv' failed with exit code 2
cannot build derivation '/nix/store/hxcxbsby3vyf9apiq3zn9qvbjznz9bs5-emacs-git-with-packages-20200412.0.drv': 1 dependencies couldn't be built
==================================================================

The warning message "'MAC_OS_X_VERSION_MAX_ALLOWED' macro redefined” was emitted during compilation of every file.

FTR, I tested it with 43282a67[1].

References:
[1] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=43282a6772630275259dbc7560913c07f72eb06e

Thanks!
--
Ashish | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0

“Sometimes even to live is an act of courage.” (Seneca)

Message #55 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Ashish SHUKLA <ashish.is <at> lostca.se>
Cc: 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Sun, 12 Apr 2020 10:53:53 +0100

[Message part 1 (text/plain, inline)]

On Sun, Apr 12, 2020 at 11:54:53AM +0530, Ashish SHUKLA wrote:
> On Apr 11, 2020, at 18:59, Alan Third <alan <at> idiocy.org> wrote:
> > 
> > You may have to set this CFLAG to enable the changes:
> > 
> >    -DMAC_OS_X_VERSION_MAX_ALLOWED=101500
> 
> Hi
> 
> Without setting CFLAGS following error occurred:
> 
> ==================================================================
>   CC       image.o
>   CC       json.o
>   CC       nsterm.o
>   CC       nsfns.o
>   CC       nsmenu.o
>   CC       nsselect.o
>   CC       nsimage.o
>   CC       macfont.o
>   CC       terminfo.o
>   CC       lastfile.o
> nsterm.m:6300:21: error: use of undeclared identifier 'drawingBuffer'
>   CGContextRelease (drawingBuffer);
>                     ^
> 1 error generated.

I’m surprised this didn’t show up before.

> In file included from <built-in>:360:
> <command line>:4:9: warning: 'MAC_OS_X_VERSION_MAX_ALLOWED' macro redefined [-Wmacro-redefined]
> #define MAC_OS_X_VERSION_MAX_ALLOWED 101500
>         ^
> <command line>:3:9: note: previous definition is here
> #define MAC_OS_X_VERSION_MAX_ALLOWED 101200
>         ^

This looks suspiciously like you’re already setting that define in
your configure command. If you’re building with nix check the build
script. You, or whoever created it, probably had to add the define to
101200 (which is macOS 10.12) so it would correctly handle some
features added since macOS 10.10. I know that John Weigley uses (or
used) that value.

There’s a possibility it will appear in a different form, but it will
be something that either has 101200 or 10.12.

> nsterm.m:1148:8: error: use of undeclared identifier 'self'
>   if ([self wantsUpdateLayer])
>        ^

Silly mistake on my part.

New patch attached. You still have to use the other patch from my last
email as well.
-- 
Alan Third

[v2-0001-Allow-dynamic-choice-of-drawing-path-on-NS-bug-39.patch (text/plain, attachment)]

Message #58 received at 39883 <at> debbugs.gnu.org (full text, mbox):

From: Ashish SHUKLA <ashish.is <at> lostca.se>
To: Alan Third <alan <at> idiocy.org>, 39883 <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Sun, 12 Apr 2020 16:29:19 +0530

[Message part 1 (text/plain, inline)]

On 4/12/20 3:23 PM, Alan Third wrote:
> On Sun, Apr 12, 2020 at 11:54:53AM +0530, Ashish SHUKLA wrote:
>> On Apr 11, 2020, at 18:59, Alan Third <alan <at> idiocy.org> wrote:
>>>
>>> You may have to set this CFLAG to enable the changes:
>>>
>>>    -DMAC_OS_X_VERSION_MAX_ALLOWED=101500
>>
>> Hi
>>
>> Without setting CFLAGS following error occurred:
>>
>> ==================================================================
>>   CC       image.o
>>   CC       json.o
>>   CC       nsterm.o
>>   CC       nsfns.o
>>   CC       nsmenu.o
>>   CC       nsselect.o
>>   CC       nsimage.o
>>   CC       macfont.o
>>   CC       terminfo.o
>>   CC       lastfile.o
>> nsterm.m:6300:21: error: use of undeclared identifier 'drawingBuffer'
>>   CGContextRelease (drawingBuffer);
>>                     ^
>> 1 error generated.
> 
> I’m surprised this didn’t show up before.
> 
>> In file included from <built-in>:360:
>> <command line>:4:9: warning: 'MAC_OS_X_VERSION_MAX_ALLOWED' macro redefined [-Wmacro-redefined]
>> #define MAC_OS_X_VERSION_MAX_ALLOWED 101500
>>         ^
>> <command line>:3:9: note: previous definition is here
>> #define MAC_OS_X_VERSION_MAX_ALLOWED 101200
>>         ^
> 
> This looks suspiciously like you’re already setting that define in
> your configure command. If you’re building with nix check the build
> script. You, or whoever created it, probably had to add the define to
> 101200 (which is macOS 10.12) so it would correctly handle some
> features added since macOS 10.10. I know that John Weigley uses (or
> used) that value.

Looks like that indeed[1] came from John Wiegley's work. I wasn't
overriding it properly in my local emacs derivation. Thanks for pointing
this out.

> 
> There’s a possibility it will appear in a different form, but it will
> be something that either has 101200 or 10.12.
> 
>> nsterm.m:1148:8: error: use of undeclared identifier 'self'
>>   if ([self wantsUpdateLayer])
>>        ^
> 
> Silly mistake on my part.
> 
> New patch attached. You still have to use the other patch from my last
> email as well.

With updated patches, and CFLAGS changed, it fixed the problem. Without
CFLAGS change, it built fine with problem persisting.

References:
[1]
https://github.com/NixOS/nixpkgs/commit/aa2160e1b62bdc6795c465e68301ec8684540b24

Thanks!
-- 
Ashish SHUKLA

[signature.asc (application/pgp-signature, attachment)]

Message #61 received at 39883-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Ashish SHUKLA <ashish.is <at> lostca.se>
Cc: 39883-done <at> debbugs.gnu.org
Subject: Re: bug#39883: 28.0.50; macOS blank frame
Date: Thu, 16 Apr 2020 19:22:38 +0100

On Sun, Apr 12, 2020 at 04:29:19PM +0530, Ashish SHUKLA wrote:
> 
> With updated patches, and CFLAGS changed, it fixed the problem. Without
> CFLAGS change, it built fine with problem persisting.

Hi Ashish, I’ve pushed this change to master, so hopefully that’s us
done and therefore I’m closing the bug report.
-- 
Alan Third

Previous Next

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