🚀 go-pugleaf

Thanks to those who responded to my protocol request.  Looks like I was
tilting at yet another windmill, as what I wanted to do can't yet be
done (occam3 ?).  Roger Peel in particular provided some useful
information.

I couldn't use CHAN OF ANY as there are lots of other things going on
over the channel.  I quite liked Alastair's idea of declaring a new
protocol once I knew what nrows & ncolumns were, but I have to talk to
an external, and this clashes with the debugger.

You CAN send 2-d arrays.  The current version of the code has a variant
protocol (ALICE.LINK) which includes

          CASE
            frame; [256][256]REAL32

and the code includes

      CHAN OF ALICE.LINK from.pipe :

      [256][256]REAL32 data.frame :
      SEQ
        from.pipe ? CASE frame; data.frame

Chris O Byrne came closest, using a loop to read sub-rows;  I had
thought of this approach; I just wanted to be lazy and do it as a single
message.

However, the problem has temporarily gone away as, for this application
at least, the author of the Fortran process (!) with which I have to
communicate is content to get the data as a 1-d vector and deal with
pixel placement in the Fortran code.  Now, the variant protocol
declaration includes
            frame; INT[]::REAL32

and my code has
            [max.pxls]REAL32 data.frame :
            INT num.pxls :
            .
            .
            SEQ
              in ? CASE frame; num.pxls::data.frame

     Cheers,
     Magnus.

   **************************************************************************
   * Magnus J Paterson  | mjp@uk.ac.roe.star     | We are all in the gutter *
   * ALICE Project      | revaxd::mjp            |  but some of us          *
   * Royal Observatory  |                        |    are looking up        *
   * Edinburgh          | ph  +44 (0)31 668 8247 |      at the stars.       *
   * SCOTLAND           | fax +44 (0)31 668 8264 |       (Oscar Wilde)      *
   **************************************************************************