running ./temacs

running ./temacs

[Dan Nicolaescu]

Running just ./temacs is currently not very useful.
The first think it does when starting up is complain that /.emacs.d/ cannot be found.

M-: (getenv "HOME")
return nil

This is because `process-environment' is nil.

emacs.c contains this code:

  /* Initialize and GC-protect Vinitial_environment and
     Vprocess_environment before set_initial_environment fills them
     in.  */
  if (!initialized)
    syms_of_callproc ();
  /* egetenv is a pretty low-level facility, which may get called in
     many circumstances; it seems flimsy to put off initializing it
     until calling init_callproc.  */
  set_initial_environment ();

The first comment above seems to be contradicted by the code in
set_initial_environment that only initializes Vprocess_environment if
`initialized' is true (which is not when running just ./temacs):


void
set_initial_environment (void)
{
  register char **envp;
#ifdef CANNOT_DUMP
  Vprocess_environment = Qnil;
#else
  if (initialized)
#endif
    {
      for (envp = environ; *envp; envp++)
      Vprocess_environment = Fcons (build_string (*envp),
                                         Vprocess_environment);
      /* Ideally, the `copy' shouldn't be necessary, but it seems it's frequent
       to use `delete' and friends on process-environment.  */
      Vinitial_environment = Fcopy_sequence (Vprocess_environment);
    }
}

What is the intention here?

[Hacking around this so that Vprocess_environment is initialized when
not dumping makes ./temacs work correctly]

Re: running ./temacs

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

> Running just ./temacs is currently not very useful.

Yep.

> The first think it does when starting up is complain that /.emacs.d/
> cannot be found.

[snip]

On a related topic, it would be nice to have a working emacs when
CANNOT_DUMP is defined.

IIRC some time ago I built such a beast on GNU/Linux after hard-coding
some macro values on epaths.h and applying the following patch. Please
consider it for inclusion on the mainline sources.

diff --git a/src/eval.c b/src/eval.c
index 06888ca..91f75dd 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -2184,9 +2184,11 @@ do_autoload (Lisp_Object fundef, Lisp_Object funname)
 
   /* This is to make sure that loadup.el gives a clear picture
      of what files are preloaded and when.  */
+#ifndef CANNOT_DUMP
   if (! NILP (Vpurify_flag))
     error ("Attempt to autoload %s while preparing to dump",
           SDATA (SYMBOL_NAME (funname)));
+#endif
 
   fun = funname;
   CHECK_SYMBOL (funname);
diff --git a/src/fns.c b/src/fns.c
index 3d4c07a..dc1a181 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2809,9 +2809,11 @@ The normal messages at start and end of loading FILENAME are suppressed.  *
 
       /* This is to make sure that loadup.el gives a clear picture
         of what files are preloaded and when.  */
+#ifndef CANNOT_DUMP
       if (! NILP (Vpurify_flag))
        error ("(require %s) while preparing to dump",
               SDATA (SYMBOL_NAME (feature)));
+#endif
 
       /* A certain amount of recursive `require' is legitimate,
         but if we require the same feature recursively 3 times,

Re: running ./temacs

[Dan Nicolaescu]

Dan Nicolaescu <dann@gnu.org> writes:

> [Hacking around this so that Vprocess_environment is initialized when
> not dumping makes ./temacs work correctly]

In case anyone wants to see the difference in behavior, here's the ugly hack:

--- src/emacs.c      2010-11-15 06:10:35 +0000
+++ src/emacs.c      2010-11-17 07:40:04 +0000
@@ -1455,7 +1455,15 @@ main (int argc, char **argv)
   /* egetenv is a pretty low-level facility, which may get called in
      many circumstances; it seems flimsy to put off initializing it
      until calling init_callproc.  */
-  set_initial_environment ();
+
+  if (!initialized && !((strcmp (argv[argc-1], "dump") == 0
+                    || strcmp (argv[argc-1], "bootstrap") == 0))){
+    initialized = 1;
+    set_initial_environment ();
+    initialized = 0;
+  }
+  else
+    set_initial_environment ();
   /* AIX crashes are reported in system versions 3.2.3 and 3.2.4
      if this is not done.  Do it after set_global_environment so that we
      don't pollute Vglobal_environment.  */

Re: running ./temacs

[Stefan Monnier]

>> [Hacking around this so that Vprocess_environment is initialized when
>> not dumping makes ./temacs work correctly]
> In case anyone wants to see the difference in behavior, here's the ugly hack:

Could you explain your code (i.e. why you need those strcmp hacks, why
you need to set&unset initialized, ...)?

Basically, the control flow around these parts of the code is a bit too
intricate for my poor head right now, and on top of that, I don't know
what it's trying to achieve.

> --- src/emacs.c      2010-11-15 06:10:35 +0000
> +++ src/emacs.c      2010-11-17 07:40:04 +0000
> @@ -1455,7 +1455,15 @@ main (int argc, char **argv)
>    /* egetenv is a pretty low-level facility, which may get called in
>       many circumstances; it seems flimsy to put off initializing it
>       until calling init_callproc.  */
> -  set_initial_environment ();
> +
> +  if (!initialized && !((strcmp (argv[argc-1], "dump") == 0
> +                    || strcmp (argv[argc-1], "bootstrap") == 0))){
> +    initialized = 1;
> +    set_initial_environment ();
> +    initialized = 0;
> +  }
> +  else
> +    set_initial_environment ();
>    /* AIX crashes are reported in system versions 3.2.3 and 3.2.4
>       if this is not done.  Do it after set_global_environment so that we
>       don't pollute Vglobal_environment.  */


-- Stefan

Re: running ./temacs

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> [Hacking around this so that Vprocess_environment is initialized when
>>> not dumping makes ./temacs work correctly]
>> In case anyone wants to see the difference in behavior, here's the ugly hack:
>
> Could you explain your code (i.e. why you need those strcmp hacks, why
> you need to set&unset initialized, ...)?

set_initial_environment only initializes Vprocess_environment if
`initialized' is set.

The ugly hack only sets `initialized' when not dumping, so that if you
run temacs without dumping Vprocess_environment gets initialized.
If Vprocess_environment is not initialized (getenv "HOME") returns
nil, any many things go bad from there.

Re: running ./temacs

[Stefan Monnier]

>>>> [Hacking around this so that Vprocess_environment is initialized when
>>>> not dumping makes ./temacs work correctly]
>>> In case anyone wants to see the difference in behavior, here's the
>>> ugly hack:
>> Could you explain your code (i.e. why you need those strcmp hacks, why
>> you need to set&unset initialized, ...)?
> set_initial_environment only initializes Vprocess_environment if
> `initialized' is set.

Do you happen to know why?


        Stefan

Re: running ./temacs

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>>> [Hacking around this so that Vprocess_environment is initialized when
>>>>> not dumping makes ./temacs work correctly]
>>>> In case anyone wants to see the difference in behavior, here's the
>>>> ugly hack:
>>> Could you explain your code (i.e. why you need those strcmp hacks, why
>>> you need to set&unset initialized, ...)?
>> set_initial_environment only initializes Vprocess_environment if
>> `initialized' is set.
>
> Do you happen to know why?

No idea.  I'd speculate that it's undesirable to initialize it when dumping...

Re: running ./temacs

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Date: Thu, 18 Nov 2010 17:19:13 -0500
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> >>>>> [Hacking around this so that Vprocess_environment is initialized when
> >>>>> not dumping makes ./temacs work correctly]
> >>>> In case anyone wants to see the difference in behavior, here's the
> >>>> ugly hack:
> >>> Could you explain your code (i.e. why you need those strcmp hacks, why
> >>> you need to set&unset initialized, ...)?
> >> set_initial_environment only initializes Vprocess_environment if
> >> `initialized' is set.
> >
> > Do you happen to know why?
> 
> No idea.  I'd speculate that it's undesirable to initialize it when dumping...

Yes, probably.

I'd think it's cleaner to add an argument to set_initial_environment,
which then could tell it whether to initialize Vprocess_environment,
instead of intuiting that inside the function by looking at
`initialized' and CANNOT_DUMP.  We could then set that argument
non-zero when temacs is run with arguments other than "dump" or
"bootstrap".

Re: running ./temacs

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Thu, 18 Nov 2010 17:19:13 -0500
>> Cc: emacs-devel@gnu.org
>> 
>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> 
>> >>>>> [Hacking around this so that Vprocess_environment is initialized when
>> >>>>> not dumping makes ./temacs work correctly]
>> >>>> In case anyone wants to see the difference in behavior, here's the
>> >>>> ugly hack:
>> >>> Could you explain your code (i.e. why you need those strcmp hacks, why
>> >>> you need to set&unset initialized, ...)?
>> >> set_initial_environment only initializes Vprocess_environment if
>> >> `initialized' is set.
>> >
>> > Do you happen to know why?
>> 
>> No idea.  I'd speculate that it's undesirable to initialize it when dumping...
>
> Yes, probably.
>
> I'd think it's cleaner to add an argument to set_initial_environment,
> which then could tell it whether to initialize Vprocess_environment,
> instead of intuiting that inside the function by looking at
> `initialized' and CANNOT_DUMP.  We could then set that argument
> non-zero when temacs is run with arguments other than "dump" or
> "bootstrap".

Agreed.
Also, if we get ./temacs to work correctly then a lot of #ifdef
CANNOT_DUMP code can be reconsidered.  After all running just ./temacs
is very close to running with CANNOT_DUMP defined.

Things like:
  if (1
#ifndef CANNOT_DUMP
      && initialized
#endif
      )

might not be needed at all... 

Re: running ./temacs

[Stefan Monnier]

>> >>>>> [Hacking around this so that Vprocess_environment is initialized when
>> >>>>> not dumping makes ./temacs work correctly]
>> >>>> In case anyone wants to see the difference in behavior, here's the
>> >>>> ugly hack:
>> >>> Could you explain your code (i.e. why you need those strcmp hacks, why
>> >>> you need to set&unset initialized, ...)?
>> >> set_initial_environment only initializes Vprocess_environment if
>> >> `initialized' is set.
>> > Do you happen to know why?
>> No idea.  I'd speculate that it's undesirable to initialize it when
>> dumping...
> Yes, probably.

So `initialized' is not the right variable to test.
Maybe Vpurify_flag would be closer since it is a better indicator of
whether we're about to dump or not, AFAIK.


        Stefan

Re: running ./temacs

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> >>>>> [Hacking around this so that Vprocess_environment is initialized when
>>> >>>>> not dumping makes ./temacs work correctly]
>>> >>>> In case anyone wants to see the difference in behavior, here's the
>>> >>>> ugly hack:
>>> >>> Could you explain your code (i.e. why you need those strcmp hacks, why
>>> >>> you need to set&unset initialized, ...)?
>>> >> set_initial_environment only initializes Vprocess_environment if
>>> >> `initialized' is set.
>>> > Do you happen to know why?
>>> No idea.  I'd speculate that it's undesirable to initialize it when
>>> dumping...
>> Yes, probably.
>
> So `initialized' is not the right variable to test.
> Maybe Vpurify_flag would be closer since it is a better indicator of
> whether we're about to dump or not, AFAIK.

Vpurify_flag does not quite work. lread.c:init_obarray sets it
unconditionally:

  /* Qt is correct even if CANNOT_DUMP.  loadup.el will set to nil at end.  */
  Vpurify_flag = Qt;

I checked in a simplified version of this and of
set_initial_environment.
./temacs runs now.  It starts up in -nw mode, but that's a different
issue.  It would be great if someone could solve that one too...

Re: running ./temacs

[Dan Nicolaescu]

Dan Nicolaescu <dann@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> >>>>> [Hacking around this so that Vprocess_environment is initialized when
>>>> >>>>> not dumping makes ./temacs work correctly]
>>>> >>>> In case anyone wants to see the difference in behavior, here's the
>>>> >>>> ugly hack:
>>>> >>> Could you explain your code (i.e. why you need those strcmp hacks, why
>>>> >>> you need to set&unset initialized, ...)?
>>>> >> set_initial_environment only initializes Vprocess_environment if
>>>> >> `initialized' is set.
>>>> > Do you happen to know why?
>>>> No idea.  I'd speculate that it's undesirable to initialize it when
>>>> dumping...
>>> Yes, probably.
>>
>> So `initialized' is not the right variable to test.
>> Maybe Vpurify_flag would be closer since it is a better indicator of
>> whether we're about to dump or not, AFAIK.
>
> Vpurify_flag does not quite work. lread.c:init_obarray sets it
> unconditionally:
>
>   /* Qt is correct even if CANNOT_DUMP.  loadup.el will set to nil at end.  */
>   Vpurify_flag = Qt;
>
> I checked in a simplified version of this and of
> set_initial_environment.
> ./temacs runs now.  It starts up in -nw mode, but that's a different
> issue.  It would be great if someone could solve that one too...

It looks like this is enough to get ./temacs run in X11 mode:

=== modified file 'src/dispnew.c'
--- src/dispnew.c 2011-05-25 03:45:04 +0000
+++ src/dispnew.c 2011-05-31 06:17:37 +0000
@@ -6235,9 +6235,6 @@ init_display (void)
     }
 
   if (!inhibit_window_system && display_arg
-#ifndef CANNOT_DUMP
-     && initialized
-#endif
      )
     {
       Vinitial_window_system = Qx;

=== modified file 'src/frame.c'
--- src/frame.c   2011-05-29 00:45:00 +0000
+++ src/frame.c   2011-05-31 06:13:37 +0000
@@ -544,10 +544,8 @@ make_initial_frame (void)
   /* The default value of menu-bar-mode is t.  */
   set_menu_bar_lines (f, make_number (1), Qnil);
 
-#ifdef CANNOT_DUMP
   if (!noninteractive)
     init_frame_faces (f);
-#endif
 
   return f;
 }

Any reason not to check this in?

Re: running ./temacs

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 31 May 2011 02:36:38 -0400
> 
> It looks like this is enough to get ./temacs run in X11 mode:
> 
> === modified file 'src/dispnew.c'
> --- src/dispnew.c 2011-05-25 03:45:04 +0000
> +++ src/dispnew.c 2011-05-31 06:17:37 +0000
> @@ -6235,9 +6235,6 @@ init_display (void)
>      }
>  
>    if (!inhibit_window_system && display_arg
> -#ifndef CANNOT_DUMP
> -     && initialized
> -#endif
>       )
>      {
>        Vinitial_window_system = Qx;
> 
> === modified file 'src/frame.c'
> --- src/frame.c   2011-05-29 00:45:00 +0000
> +++ src/frame.c   2011-05-31 06:13:37 +0000
> @@ -544,10 +544,8 @@ make_initial_frame (void)
>    /* The default value of menu-bar-mode is t.  */
>    set_menu_bar_lines (f, make_number (1), Qnil);
>  
> -#ifdef CANNOT_DUMP
>    if (!noninteractive)
>      init_frame_faces (f);
> -#endif
>  
>    return f;
>  }
> 
> Any reason not to check this in?

What would be the purpose of getting temacs run in GUI mode?

Re: running ./temacs

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Tue, 31 May 2011 02:36:38 -0400
>> 
>> It looks like this is enough to get ./temacs run in X11 mode:
>> 
>> === modified file 'src/dispnew.c'
>> --- src/dispnew.c 2011-05-25 03:45:04 +0000
>> +++ src/dispnew.c 2011-05-31 06:17:37 +0000
>> @@ -6235,9 +6235,6 @@ init_display (void)
>>      }
>>  
>>    if (!inhibit_window_system && display_arg
>> -#ifndef CANNOT_DUMP
>> -     && initialized
>> -#endif
>>       )
>>      {
>>        Vinitial_window_system = Qx;
>> 
>> === modified file 'src/frame.c'
>> --- src/frame.c   2011-05-29 00:45:00 +0000
>> +++ src/frame.c   2011-05-31 06:13:37 +0000
>> @@ -544,10 +544,8 @@ make_initial_frame (void)
>>    /* The default value of menu-bar-mode is t.  */
>>    set_menu_bar_lines (f, make_number (1), Qnil);
>>  
>> -#ifdef CANNOT_DUMP
>>    if (!noninteractive)
>>      init_frame_faces (f);
>> -#endif
>>  
>>    return f;
>>  }
>> 
>> Any reason not to check this in?
>
> What would be the purpose of getting temacs run in GUI mode?

Minimize the differences between temacs and emacs.  Other than dumping,
is it useful to have temacs and emacs behave differently?

Hopefully temacs should be much easier to get to work under valgrind
(and other similar tools) for example.
Another use would be for cross-compiling.  One can cross-compile temacs,
but if the result behave differently, it's not very useful.  If it
behaved the same, it would start up slower, but it would otherwise work
just the same as emacs.

Re: running ./temacs

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Tue, 31 May 2011 02:55:23 -0400
> 
> >> Any reason not to check this in?
> >
> > What would be the purpose of getting temacs run in GUI mode?
> 
> Minimize the differences between temacs and emacs.  Other than dumping,
> is it useful to have temacs and emacs behave differently?
> 
> Hopefully temacs should be much easier to get to work under valgrind
> (and other similar tools) for example.
> Another use would be for cross-compiling.  One can cross-compile temacs,
> but if the result behave differently, it's not very useful.  If it
> behaved the same, it would start up slower, but it would otherwise work
> just the same as emacs.

All these are worthy goals, IMO.  And I see no reasons not to commit
your suggested changes.

Thanks.

Re: running ./temacs

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Tue, 31 May 2011 02:55:23 -0400
>> 
>> >> Any reason not to check this in?
>> >
>> > What would be the purpose of getting temacs run in GUI mode?
>> 
>> Minimize the differences between temacs and emacs.  Other than dumping,
>> is it useful to have temacs and emacs behave differently?
>> 
>> Hopefully temacs should be much easier to get to work under valgrind
>> (and other similar tools) for example.
>> Another use would be for cross-compiling.  One can cross-compile temacs,
>> but if the result behave differently, it's not very useful.  If it
>> behaved the same, it would start up slower, but it would otherwise work
>> just the same as emacs.
>
> All these are worthy goals, IMO.  And I see no reasons not to commit
> your suggested changes.

Thanks, checked in.

The HAVE_NS code in dispnew.c might need similar treatment, but I can't
test that one.

Re: running ./temacs

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 31 May 2011 01:19:01 -0400
> 
> I checked in a simplified version of this and of
> set_initial_environment.
> ./temacs runs now.

Thanks.

> It starts up in -nw mode, but that's a different
> issue.  It would be great if someone could solve that one too...

AFAIK, temacs is supposed to start in -nw mode, because the frame it
creates is a TTY frame.  But why is that a problem?  Can't you use
emacsclient to create a GUI frame afterwards, once temacs is up and
running?