Subject: FVWM: FvwmM4/m4 problems

From: Steve Passe <[email-masked]>
Date: Mon, 12 Feb 1996 18:23:00 -0700

Hi,

I just upgraded 2 machines to 2.0.40 and found that my m4 style .fvwmrc
files failed to work correctly.  The basic problem is that certain
options/styles fail to get set.  It also appears to be pseudo-random in
nature, 3 different starts have 3 different results.

Setting DBUG in configure.h I observed that fvwm starts FvwmM4 and then goes
on to do various X11 initializations, finally entering it's HandleEvents loop.
By the time FvwmM4/m4 have processed .fvwm2rc into /tmp/fvwmrcxxxxxx and
returned the SendInfo( "read /tmp/fvwmrcxxxx" ) message MANY X events have
been handled.  I am not an X11 programer, so I have NO idea where the exact
problem is.  My first observation was that placing a "sleep 15" into .xinitrc
immediately after starting fvwm2rc would fix the problem (usually).  So I went
fishing for a way to syncronize fvwm2 and FvwmM4.  The result is the following
set of patches to fvwm/fvwm.c:

------------------------------------- cut -------------------------------------
-
*** fvwm/fvwm.c 1996/02/12 06:34:38     1.1
--- fvwm/fvwm.c 1996/02/12 23:49:47
***************
*** 103,108 ****
--- 103,180 ----
  int fd_width, x_fd;
  char *display_name = NULL;
  
+ #define M4_RACE
+ #if defined( M4_RACE )
+ 
+ int raceSync = False;
+ 
+ /***************************************************************************
+  *
+  * Bogon alert!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+  *  major hack to sync FvwmM4 pre-processor
+  *  this routine was hacked from events.c: My_XNextEvent()
+  *  may or may not work with FvwmCpp
+  *
+  * Wait for configuration by pre-processor to complete.
+  *
+  ****************************************************************************
/
+ int M4OutputReady( void )
+ {
+   extern int fd_width;
+   fd_set in_fdset;
+   Window targetWindow;
+   int i,count;
+   int retval;
+ 
+   DBUG("M4OutputReady","Entered");
+ 
+   FD_ZERO(&in_fdset);
+   for(i=0; i<npipes; i++)
+     {
+       if(readPipes[i]>=0)
+       {
+         FD_SET(readPipes[i], &in_fdset);
+       }
+     }
+ 
+ #ifdef __hpux
+   retval = select( fd_width, (int *)&in_fdset, 0, 0, NULL );
+ #else
+   retval = select( fd_width, &in_fdset, 0, 0, NULL );
+ #endif
+ 
+   /* Check for module input. */
+   for(i=0;i<npipes;i++)
+     {
+       if(readPipes[i] >= 0)
+       {
+         if((retval>0)&&(FD_ISSET(readPipes[i], &in_fdset)))
+           {
+             if((count = 
+                 read(readPipes[i],&targetWindow, sizeof(Window))) >0)
+               {
+                   DBUG("M4OutputReady","calling HandleModuleInput");
+                 /**
+                  * we blindly assume it is the "read /tmp/xxx" message
+                  *  from FvwmM4 or FvwmCpp
+                  */
+                 HandleModuleInput(targetWindow,i);
+                 return True;
+               }
+             if(count <= 0)
+               {
+                   DBUG("M4OutputReady","calling KillModule");
+                 KillModule(i,10);
+               }
+           }
+       }
+     }
+   DBUG("M4OutputReady","Leaving");
+   return False;
+ }
+ #endif /* M4_RACE */
+ 
+ 
  /***********************************************************************
   *
   *  Procedure:
***************
*** 347,352 ****
--- 419,442 ----
    ExecuteFunction(config_command, NULL,&Event,C_ROOT,-1);
    DBUG("main","Done running config_command");
  
+ #if defined( M4_RACE )
+   if ( (mystrncasecmp( config_command, "FvwmM4", 6 ) == 0)
+        || (mystrncasecmp( config_command, "FvwmCpp", 7 ) == 0) )
+   {
+     raceSync = True;
+   }
+ # if 0
+   /**
+    *  something not ready for reading m4 processed config file yet,
+    *  if we do it now 'Scroll' functionality is hosed.
+    */
+   if ( raceSync )
+   {
+     while ( M4OutputReady() != True ) /** spin */;
+   }
+ # endif /* 0 */
+ #endif  /* M4_RACE */ 
+ 
    if(Scr.d_depth<2)
    {
      Scr.gray_pixmap = 
***************
*** 425,430 ****
--- 515,532 ----
  #endif
    XUngrabServer(dpy);
    UnBlackoutScreen();
+ 
+ #if defined( M4_RACE )
+   /**
+    * WE MUST WAIT for FvwmM4 to finish building file, then "read file"
+    * BEFORE we can start handling X events
+    */
+   if ( raceSync )
+   {
+     while ( M4OutputReady() != True ) /** spin */;
+   }
+ #endif  /* M4_RACE */ 
+ 
    DBUG("main","Entering HandleEvents loop...");
    HandleEvents();
    DBUG("main","Back from HandleEvents loop?  Exitting...");

------------------------------------- cut -------------------------------------
-

I also found a bug in FvwmM4 itself, if you don't set '-debug' when invoking
fvwm2rc, FvwmM4 removes /tmp/fvwmrcxxxxxx when it finishes.  This means that 
any
modules started interactively (eg. via pulldown menues) are given the now non-
existant file's name as it's expected config file.

------------------------------------- cut -------------------------------------
-
*** modules/FvwmM4/FvwmM4.c     1996/02/12 06:32:53     1.1
--- modules/FvwmM4/FvwmM4.c     1996/02/12 23:04:33
***************
*** 181,191 ****
--- 181,196 ----
  
    /* For a debugging version, we may wish to omit this part. */
    /* I'll let some m4 advocates clean this up */
+ #if defined( M4_ERASE )
+  /**
+   * won't this remove the file used by various modules???
+   */
    if(!m4_debug)
      {
        sprintf(delete_string,"exec rm %s\n",tmp_file);
        SendInfo(fd,delete_string,0);
      }
+ #endif /* M4_ERASE */
  }
------------------------------------- cut -------------------------------------
-

Both of these will install from the top level directory via:

% patch -p < patch-aa; patch -p < patch-ab

Note that the first patch to fvwm.c is quite GROSS, but it does work.  Perhaps
it will create insite for a more X literate programmer to find a correct
solution.  I have NOT attempted to use these patches with cpp, and am just
assumming that the same problem might exist.  So look expecially hard at them
b4 using with FvwmCpp.

--
Steve Passe		| powered by
[email-masked]	|            FreeBSD

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].