today's git does not run on Ubuntu

today's git does not run on Ubuntu

[Susan Cragin]

Hello, 
I updated my emacs git today, which compiled seemingly without errors, but does not run. The program opens and freezes immediately. 
I have an unmodified Ubuntu Trusty 64-bit system, and have been compiling emacs for a couple of years without problems. I have all dependencies. 
Nothing pops up in the terminal window. 
Susan Cragin

Re: today's git does not run on Ubuntu

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 2:56 PM, Susan Cragin <susancragin@earthlink.net> wrote:

> I updated my emacs git today, which compiled seemingly without errors, but does not run. The program opens and freezes immediately.

I see the same thing on Windows: "emacs -Q" freezes, "emacs -Q -nw" does not.

It seems a consequence of Paul's latest patches (revno:115529, revno:115532).

Breaking with Ctrl-C gives this backtrace:

Quit (expect signal SIGINT when the program is resumed)
(gdb) thread 1
[Switching to thread 1 (Thread 10728.0x16b8)]
#0  0x01204269 in w32_frame_up_to_date (f=0x3a9d360
<__register_frame_info+61461344>) at w32term.c:730
730         FRAME_MOUSE_UPDATE (f);
(gdb) bt
#0  0x01204269 in w32_frame_up_to_date (f=0x3a9d360
<__register_frame_info+61461344>) at w32term.c:730
#1  0x0103b3a2 in message3_nolog (m=61864465) at xdisp.c:9992
#2  0x0103b08c in message3 (m=61864465) at xdisp.c:9931
#3  0x01172af6 in Fmessage (nargs=2, args=0x88eb08) at editfns.c:3452
#4  0x0117f07f in Ffuncall (nargs=3, args=0x88eb04) at eval.c:2786
#5  0x011bf97c in exec_byte_code (bytestr=19642409, vector=19642429,
maxdepth=24, args_template=0, nargs=0, args=0x88ee3c) at
bytecode.c:919
#6  0x0117f971 in funcall_lambda (fun=19642389, nargs=0,
arg_vector=0x88ee3c) at eval.c:2973
#7  0x0117f3cb in Ffuncall (nargs=1, args=0x88ee38) at eval.c:2854
#8  0x011bf97c in exec_byte_code (bytestr=19642961, vector=19642981,
maxdepth=92, args_template=1028, nargs=1, args=0x88f1ac) at
bytecode.c:919
#9  0x0117f971 in funcall_lambda (fun=19642941, nargs=1,
arg_vector=0x88f1a8) at eval.c:2973
#10 0x0117f3cb in Ffuncall (nargs=2, args=0x88f1a4) at eval.c:2854
#11 0x011bf97c in exec_byte_code (bytestr=19630113, vector=19630133,
maxdepth=68, args_template=0, nargs=0, args=0x88f50c) at
bytecode.c:919
#12 0x0117f971 in funcall_lambda (fun=19630093, nargs=0,
arg_vector=0x88f50c) at eval.c:2973
#13 0x0117f3cb in Ffuncall (nargs=1, args=0x88f508) at eval.c:2854
#14 0x011bf97c in exec_byte_code (bytestr=19628321, vector=19628341,
maxdepth=48, args_template=0, nargs=0, args=0x88f7c0) at
bytecode.c:919
#15 0x0117f971 in funcall_lambda (fun=19628301, nargs=0,
arg_vector=0x88f7c0) at eval.c:2973
#16 0x0117f690 in apply_lambda (fun=19628301, args=58132514) at eval.c:2914
#17 0x0117e06e in eval_sub (form=59864350) at eval.c:2220
#18 0x0117d68e in Feval (form=59864350, lexical=58132514) at eval.c:1993
#19 0x010f262d in top_level_2 () at keyboard.c:1179
#20 0x0117c075 in internal_condition_case (bfun=0x10f2610
<top_level_2>, handlers=58183970, hfun=0x10f21ab <cmd_error>) at
eval.c:1344
#21 0x010f2661 in top_level_1 (ignore=58132514) at keyboard.c:1187
#22 0x0117b622 in internal_catch (tag=58179330, func=0x10f262f
<top_level_1>, arg=58132514) at eval.c:1108
#23 0x010f2593 in command_loop () at keyboard.c:1148
#24 0x010f1d48 in recursive_edit_1 () at keyboard.c:777
#25 0x010f1f04 in Frecursive_edit () at keyboard.c:841
#26 0x010f0108 in main (argc=2, argv=0xab1b50) at emacs.c:1634

Lisp Backtrace:
"message" (0x88eb08)
warning: SuspendThread failed. (winerr 5)
warning: SuspendThread failed. (winerr 5)
PC register is not available
(gdb)

Re: today's git does not run on Ubuntu

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 15 Dec 2013 16:20:18 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
> 	EMACS development team <emacs-devel@gnu.org>
> 
> On Sun, Dec 15, 2013 at 2:56 PM, Susan Cragin <susancragin@earthlink.net> wrote:
> 
> > I updated my emacs git today, which compiled seemingly without errors, but does not run. The program opens and freezes immediately.
> 
> I see the same thing on Windows: "emacs -Q" freezes, "emacs -Q -nw" does not.
> 
> It seems a consequence of Paul's latest patches (revno:115529, revno:115532).

Please try again.  It's amazing what one incorrect "true" can do.

Re: today's git does not run on Ubuntu

[Paul Eggert]

Eli Zaretskii wrote:
> It's amazing what one incorrect "true" can do.

Yeowch.  Thanks for fixing that.  I looked for further
errors of that form, and didn't find any.

Desktop tty frames (was: today's git does not run on Ubuntu)

[Juri Linkov]

> I see the same thing on Windows: "emacs -Q" freezes, "emacs -Q -nw" does not.

When I tried "emacs -nw" in this revision, it loads the saved desktop,
creates a new graphical frame and freezes.  This raises the question:
shouldn't the desktop open the saved frame as a tty frame when the desktop
is restored by "emacs -nw"?

Re: Desktop tty frames (was: today's git does not run on Ubuntu)

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 8:48 PM, Juri Linkov <juri@jurta.org> wrote:

> This raises the question:
> shouldn't the desktop open the saved frame as a tty frame when the desktop
> is restored by "emacs -nw"?

That is a good question. In general, the frameset stuff tries to
restore the frames as they were (though there are options to tweak
this) because on POSIX systems Emacs can have tty and GUI frames at
once.

So I suppose the answer is:
- do we want to default to non-GUI frames on POSIX -nw runs? If so, do
we force them to tty frames or ignore them?
- do we want to select this behavior through and option?
- some other idea?

   J

Re: Desktop tty frames (was: today's git does not run on Ubuntu)

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 9:13 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>> This raises the question:
>> shouldn't the desktop open the saved frame as a tty frame when the desktop
>> is restored by "emacs -nw"?

Anyway, note that the desktop only loads in non -q/Q runs, in which
case the user can set desktop-restore-in-current-display to t or
`delete' according to the window-system or whatever they want. So not
sure that something needs to be fixed; but I'm open to be told
otherwise.

   J

Re: Desktop tty frames

[Juri Linkov]

> Anyway, note that the desktop only loads in non -q/Q runs, in which
> case the user can set desktop-restore-in-current-display to t or
> `delete' according to the window-system or whatever they want. So not
> sure that something needs to be fixed; but I'm open to be told
> otherwise.

Thanks, desktop-restore-in-current-display=t indeed helps in this situation.

RE: Desktop tty frames (was: today's git does not run on Ubuntu)

[Drew Adams]

> So I suppose the answer is:
> - do we want to default to non-GUI frames on POSIX -nw runs? If so, do
>   we force them to tty frames or ignore them?
> - do we want to select this behavior through and option?
> - some other idea?

It sounds to me like a user might prefer either respecting what was
recorded or limiting to non-GUI (on -nw).  So I'd guess that the
choice should be up to users, as an option.

Re: Desktop tty frames (was: today's git does not run on Ubuntu)

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 10:47 PM, Drew Adams <drew.adams@oracle.com> wrote:

> It sounds to me like a user might prefer either respecting what was
> recorded or limiting to non-GUI (on -nw).  So I'd guess that the
> choice should be up to users, as an option.

It already is, through desktop-restore-in-current-display. The
question is whether the default should be changed. I suppose testing
will tell us.

    J

RE: Desktop tty frames

[Drew Adams]

> > Anyway, note that the desktop only loads in non -q/Q runs, in which
> > case the user can set desktop-restore-in-current-display to t or
> > `delete' according to the window-system or whatever they want. So not
> > sure that something needs to be fixed; but I'm open to be told
> > otherwise.
> 
> Thanks, desktop-restore-in-current-display=t indeed helps in this situation.

I see.  So we already have the relevant option.  In that case, I'm
confused why the question was raised as to whether we need an option
for this.

Re: Desktop tty frames

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 10:52 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I see.  So we already have the relevant option.  In that case, I'm
> confused why the question was raised as to whether we need an option
> for this.

Neither Juri nor I remembered the option existed ;-)

    J

RE: Desktop tty frames

[Drew Adams]

> > I see.  So we already have the relevant option.  In that case, I'm
> > confused why the question was raised as to whether we need an option
> > for this.
> 
> Neither Juri nor I remembered the option existed ;-)

;-)  I wondered about that, and can certainly relate to it.

If this -nw vs GUI thing is an important use case for the option,
perhaps its doc should mention it.  As in, "In particular,..." or
"For example,..."  (Not sure what the default value should be, BTW.)

Re: Desktop tty frames

[Juanma Barranquero]

On Sun, Dec 15, 2013 at 11:27 PM, Drew Adams <drew.adams@oracle.com> wrote:

> If this -nw vs GUI thing is an important use case for the option,
> perhaps its doc should mention it. As in, "In particular,..." or
> "For example,..."

I don't think it is a more important use case than restoring in
multiple X displays or all in one, which was the original use case (as
suggested by Stefan, IIRC).

But if you propose a way to make the docstring clearer, I'll commit
it, no-questions-asked'ly fast.

> (Not sure what the default value should be, BTW.)

The current default is to restore every frame in its original display,
which seems pretty sane to me.

   J

Re: Desktop tty frames

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Sun, Dec 15, 2013 at 11:27 PM, Drew Adams <drew.adams@oracle.com> wrote:
 > 
 > > If this -nw vs GUI thing is an important use case for the option,
 > > perhaps its doc should mention it. As in, "In particular,..." or
 > > "For example,..."
 > 
 > But if you propose a way to make the docstring clearer, I'll commit
 > it, no-questions-asked'ly fast.

Huh, I think you answered the question Drew asked.  But I think the
place to mention this is in the doc for "-nw"!

 > > (Not sure what the default value should be, BTW.)
 > 
 > The current default is to restore every frame in its original display,
 > which seems pretty sane to me.

To me, that does make sense for local Xinerama (multimonitor) setups.

But I don't see how this can be done reliably for remote X frames,
where the names of displays can change in arbitrary ways in different
runs, and typically do.  Inquiring minds want to know: Did you find a
way?

Re: Desktop tty frames

[Juanma Barranquero]

On Mon, Dec 16, 2013 at 1:27 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> But I don't see how this can be done reliably for remote X frames,
> where the names of displays can change in arbitrary ways in different
> runs, and typically do.  Inquiring minds want to know: Did you find a
> way?

How could I? When saving the frames, the only data connecting them
with their display is a string, the contents of the `display'
property. When restoring, I have to trust that it still makes sense.
If it doesn't, the user can customize desktop not to do that. I'm not
sure we can do anything else.

    J

Re: Desktop tty frames

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > How could I?

Perhaps you're a magician!

 > When saving the frames, the only data connecting them
 > with their display is a string, the contents of the `display'
 > property.

That's how I would have done it 10years ago, but lots of things have
changed since then.  Linux has found ways to ensure that devices have
stable names, maybe the X.org guys figured out how to do it be X
servers.

too bad they didn't, eh?

Steve

Re: Desktop tty frames

[Juanma Barranquero]

On Mon, Dec 16, 2013 at 3:55 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> That's how I would have done it 10years ago, but lots of things have
> changed since then.  Linux has found ways to ensure that devices have
> stable names, maybe the X.org guys figured out how to do it be X
> servers.
>
> too bad they didn't, eh?

frameset.el has been mostly tested on Windows, which is what I use; I
have received some feedback, but not much (other than Drew's), which
presumably means that it hasn't caused any major trouble ;-)  But
perhaps POSIX people can suggest ways to make it better.

I suppose we'll know once the pretest starts.

    J

Re: Desktop tty frames

[chad]

FWIW, I have been confused by the emacs -nw behavior (opening a tty
frame, then closing it and opening a GUI frame) before, but not
enough to complain or change the behavior. I still find it a little
odd that I effectively can't use 'emacs -nw'. I'm trying out
desktop-restore-in-current-display 't now, and it seems like a
better default in my use cases.

Hope that helps,
~Chad

Re: Desktop tty frames

[Juanma Barranquero]

On Mon, Dec 16, 2013 at 5:36 PM, chad <chadpbrown@gmail.com> wrote:

> FWIW, I have been confused by the emacs -nw behavior (opening a tty
> frame, then closing it and opening a GUI frame) before, but not
> enough to complain or change the behavior. I still find it a little
> odd that I effectively can't use 'emacs -nw'. I'm trying out
> desktop-restore-in-current-display 't now, and it seems like a
> better default in my use cases.

We could change the default, or we could make the default be t or nil
depending on -nw.

WDOT?

> Hope that helps,

Yes, it does. Thanks.

    J