From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!sdcsvax!ucbvax!NTSUVAX.BITNET!ie53
From: ie53@NTSUVAX.BITNET (HAERIM LEE)
Newsgroups: comp.lang.ada
Subject: Help me to solve this problem!
Message-ID: <8708241839.AA01159@ucbvax.Berkeley.EDU>
Date: Mon, 24-Aug-87 15:06:40 EDT
Article-I.D.: ucbvax.8708241839.AA01159
Posted: Mon Aug 24 15:06:40 1987
Date-Received: Tue, 25-Aug-87 04:28:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

with text_io; use text_io;

procedure imore is      -- Intelligent 'more'

  key : character;

  task mon_user is      -- monitor user
    entry do_comm(key : character);
  end mon_user;

  task body mon_user is

    d_time : duration := 60.0;  -- pause this amount before printing next page
    frozen : boolean := FALSE;  -- true if user temporarily freeze printing

    procedure print_next is

    begin -- print_next

      put_line("Next screen");    -- simulation of printing next screen

    end print_next;

    procedure do_it(key : character) is

    begin -- do_it

      case key is
        when ' '       => print_next;           -- print next screen
        when 'f' | 'F' => frozen := TRUE;       -- freeze to read more carefully
        when 't' | 'T' => frozen := FALSE;      -- thaw (release) the freeze
        when 'c' | 'C' => d_time := 30.0;       -- change delay time
        when others    => null;                 -- ignore
      end case;

    end do_it;

  begin -- mon_user

    print_next;         -- print first page

    -- The following loop will keep printing next page every
    -- 'd_time' second, if user does not enter any command
    -- during 'd_time' seconds, or if user already has frozen
    -- automatic printing.  If he hits <space bar>, the next
    -- page is printed IMMEDIATELY, and the current printing
    -- mode is preserved.

    loop

      select
        accept do_comm(key : character) do
          do_it(key);
        end;
      or when not frozen =>
        delay d_time;           -- (roughly) suspension point 1
        print_next;
      end select;
    end loop;

  end mon_user;

begin -- imore

  -- The following loop keeps waiting for user to enter
  -- a command.  If he does, it will call the entry 'do_comm'
  -- and passes that command to it.  If no command is given
  -- within 'd_time' seconds, the next page will be automatically
  -- printed.

  loop
    get(key);                   -- suspension point 2
    mon_user.do_comm(key);
  end loop;

end imore;


-- problems statement:
--
--    This program is similar to 'more' on Unix except its more
--    clever default behavior; that is, it keeps printing each
--    page and delaying some amount of time so that user can
--    read it.  User doesn't have to hit <space bar> at all unless
--    he/she wants to wait for the next page.  It automatically
--    prints the next page after some amount of time (of cousrse,
--    user can change this value on the fly).  This is quite useful
--    if the file contains many pages which do not require careful
--    reading.  When it begins printing pages which need some
--    attention (say, need reading twice), user can freeze this
--    automatic print-pause sequence temporarily, and then use the
--    <space bar> as in the normal 'more'.  Once this portion is
--    over, he/she can resume the automatic mode printing.  With
--    this automatic printing feature and existing ones in 'more'
--    one can think about whole bunch of new functions.  It would
--    be something like a marriage of 'more' and 'cat' on Unix.
--
--    I started writing some lines of code shown above.  I expected
--    this small program would keep printing "next line" every 60
--    second if I don't hit any key after invoking this program.
--    The result, however, was quite different; only  the first
--    "next screen" is printed, and it was sitting idle until I hit
--    the <space bar>.  I noticed that this is because the 'get'
--    statement in the main body does not return its control to
--    the task 'mon_user' when it is suspended (Is it?) by this input
--    operation, while the task 'mon_user' was already in a suspended
--    state and possibly in a ready state if the specified delay time
--    had passed.  In this case, the control should be given 'mon_user'
--    so that the procedure call 'print_next' after the delay state-
--    ment can be executed.  Actually, I found that the task 'mon_user'
--    did NOT become suspended when the 'get' was invoked, but remained
--    as a 'running' state.  This can be shown using the VAX/VMS Symbolic
--    Debugger.
--
--         Shouldn't the state of the task 'mon_user' become
--    'suspended' when the 'get' is called, if there are any 'ready'
--    tasks?  If not, how do we easily implement such time-bombs for
--    input operations?  What is the relationship between task states
--    and i/o operations?  In Ada, are i/o operations done synchronously
--    or asynchronously?  Seems to be 'synchronous' in the Vax Ada V1.3.
--
--         Any comments would be appreciated.
--
--    Haerim Lee (IE53@NTSUVAX)