octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Win 98 support patch


From: Paul Kienzle
Subject: Win 98 support patch
Date: Fri, 25 Jul 2003 03:56:10 -0400
User-agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3) Gecko/20030312

The attached patch removes some major inconveniences when running
under Windows 9x.  Simple commands like ls or help would freeze
the computer for 7 sec then give a series of dire warnings about
each loaded oct-file.

As far as I can tell, the patch doesn't remove any useful functionality.
The correct status is still returned function calls.  Interrupts still
break the piped application rather than killing octave.  Killing the
pager still leaves the keyboard echo turned off in the console, only to
be fixed by system('reset').  Octave still responds appropriately if it
detects that gnuplot has been killed (which BTW it may not since pgnuplot
doesn't die when the gnuplot console is closed).  This is despite the
fact that SIGCHLD isn't being handled correctly (SIGCHLD should use
default signal handling rather than doing it's own waits if popen is
in effect according to the docs --- this may not be the case for
octave_iprocstream under unix), and despite that fact that the
buffered child cleanup function is not being called (though I didn't
look in detail at what child cleanup is needed for pager/gnuplot).

I haven't removed the fork in system('cmd','async').  In practice,
users can say system('cmd &') instead, so it isn't too much of an
issue.  If I ever get the time to do a proper mingw port this will
have to change since the windows command processor doesn't support
backgrounding in that way.

I've done tests on both Windows ME and to a lesser extent, Windows 2000.


Paul Kienzle <address@hidden>
       * Makefile.in: don't need special system for cygwin
       * oct-procbuf.cc: use popen rather than fork/exec for WIN32

The following patch removes some major inconveniences when running
under Windows 9x.  Simple commands like ls or help would freeze
the computer for 7 sec then give a series of dire warnings about
each loaded oct-file.

As far as I can tell, the patch doesn't remove any useful functionality.
The correct status is still returned function calls.  Interrupts still
break the piped application rather than killing octave.  Killing the
pager still leaves the keyboard echo turned off in the console, only to
be fixed by system('reset').  Octave still responds appropriately if it
detects that gnuplot has been killed (which BTW it may not since pgnuplot
doesn't die when the gnuplot console is closed).  This is despite the
fact that SIGCHLD isn't being handled correctly (SIGCHLD should use
default signal handling rather than doing it's own waits if popen is
in effect according to the docs --- this may not be the case for
octave_iprocstream under unix), and despite that fact that the
buffered child cleanup function is not being called (though I didn't
look in detail at what child cleanup is needed for pager/gnuplot).

I haven't removed the fork in system('cmd','async').  In practice,
users can say system('cmd &') instead, so it isn't too much of an
issue.  If I ever get the time to do a proper mingw port this will
have to change since the windows command processor doesn't support
backgrounding in that way.

I've done tests on both Windows ME and to a lesser extent, Windows 2000.


Paul Kienzle <address@hidden>
        * Makefile.in: don't need special system for cygwin
        * oct-procbuf.cc: use popen rather than fork/exec for WIN32

diff -cp octave-2.1.50-orig/src/Makefile.in octave-2.1.50/src/Makefile.in
*** octave-2.1.50-orig/src/Makefile.in  Wed May 28 16:10:28 2003
--- octave-2.1.50/src/Makefile.in       Fri Jul 25 02:28:26 2003
*************** DIST_SRC := Cell.cc c-file-ptr-stream.cc
*** 129,135 ****
        oct-strstrm.cc oct-lvalue.cc pager.cc parse.y \
        pr-output.cc procstream.cc sighandlers.cc \
        siglist.c strcasecmp.c strncase.c strfns.cc symtab.cc \
!       syscalls.cc sysdep.cc system.c token.cc toplev.cc \
        unwind-prot.cc utils.cc variables.cc xdiv.cc xpow.cc \
        $(OV_SRC) \
        $(PT_SRC)
--- 129,135 ----
        oct-strstrm.cc oct-lvalue.cc pager.cc parse.y \
        pr-output.cc procstream.cc sighandlers.cc \
        siglist.c strcasecmp.c strncase.c strfns.cc symtab.cc \
!       syscalls.cc sysdep.cc token.cc toplev.cc \
        unwind-prot.cc utils.cc variables.cc xdiv.cc xpow.cc \
        $(OV_SRC) \
        $(PT_SRC)
diff -cp octave-2.1.50-orig/src/oct-procbuf.cc octave-2.1.50/src/oct-procbuf.cc
*** octave-2.1.50-orig/src/oct-procbuf.cc       Thu Jan  2 17:55:58 2003
--- octave-2.1.50/src/oct-procbuf.cc    Fri Jul 25 03:22:38 2003
*************** static octave_procbuf *octave_procbuf_li
*** 56,62 ****
  octave_procbuf *
  octave_procbuf::open (const char *command, int mode)
  {
! #if defined (HAVE_SYS_WAIT_H)
  
    int pipe_fds[2];
  
--- 56,76 ----
  octave_procbuf *
  octave_procbuf::open (const char *command, int mode)
  {
! #if defined (__WIN32__)
!   if (is_open()) 
!     return 0;
! 
!   f = popen(command, (mode & std::ios::in) ? "r" : "w");
!   if (!f)
!     return 0;
! 
!   // Oops... popen doesn't return the associated pid, so fake it for now
!   proc_pid = 1;
!   open_p = true;
!   if (mode & std::ios::out) ::setvbuf (f, 0, _IOLBF, 0);
!   return this;
!   
! #elif defined (HAVE_SYS_WAIT_H)
  
    int pipe_fds[2];
  
*************** octave_procbuf::open (const char *comman
*** 144,150 ****
  octave_procbuf *
  octave_procbuf::close (void)
  {
! #if defined (HAVE_SYS_WAIT_H)
  
    if (f)
      {
--- 158,172 ----
  octave_procbuf *
  octave_procbuf::close (void)
  {
! #if defined (__WIN32__)
!   if (f) {
!     wstatus = ::pclose(f);
!     f = 0;
!   }
!   open_p = false;
!   return this;
!   
! #elif defined (HAVE_SYS_WAIT_H)
  
    if (f)
      {

reply via email to

[Prev in Thread] Current Thread [Next in Thread]