[Coco] new problem with unpack

[Wayne Campbell]

On Oct 30, 2013 9:57 PM, "Greg Law" <glaw at live.com> wrote:
> There are a few other things you might try to split the modules into
> physically separate processes without resorting to using temporary files
for
> intermediate output.

> 1. Have the first part of the application (decode?) write all output to
> standard input and the secondary/tertiary applications read from standard
> input and write standard output. This way you can deocde ! unpack ! split
!
> prettyprint >module.bas via fast pipes without touching disk for the
> intermediate results.

First, to make sense of the program and its organization, decode is a
stand-alone version of what in unpack is now called readCode. The program
flow is as follows:

          getHeader --------- unpack
                                |
              +--------+--------+--------+--------+
              |        |        |        |        |
          readCode  linNums  defVars  buildSrc instruction
                       |     |     |     |        |    |
                     lSort  vSort fSort dsSort   hex$ DRPN

For decode, the flow is different, as each module is CHAINed from the
previous:

          decode -> defVars -> buildSrc -> instruction
             |         |          |          |     |
           lSort     vSort      dsSort     hex$  DRPN
                     fSort

Both versions are disk intensive, in that the module (decode) or
merged-module file (unpack) is read from disk, and the tables in the I-Code
are read directly from the file. There are pre-created data files stored in
the DATA directory (/DD/DATA) that decode and unpack both use to hold
various data, like the line references, the variable references, and
internal data used by the program.

Due to the problems I still have with DIMension statements (TYPE statements
and STRINGs) three "work files" are generated by both programs. Until now,
the output of source to stdout was for the user to see what the program is
doing, as a source code file is generated in decode, and until yesterday
was being generated in unpack. This file is created first in buildSrc
(PROCEDURE statement and DIM statements), then instruction adds the source
statements to the file. In unpack, this is now changed so that the utility
will work as expected, you redirect output to save it to a file, using the
format "unpack <filepath> > <sourcefile>". It turns out that it will need a
memory modifier to work, so the actual command will be "unpack <filepath>
#16k > <sourcefile>".

That brings us up to the point of this post. The issue remains in
instruction because it and DRPN cannot run at the same time. According to
what you wrote above, I can use pipes to run both in separate spaces, and
have the data communicated between them. I think this means I use a SHELL
statement to run DRPN in it's own 64K block (I believe this is the way you
fork a process from within Basic09), then have instruction send its output
to DRPN through stdin, and DRPN can either print the resulting source
statement to stdout, or I can have DRPN send it back to instruction via
pipes (stdin) and let instruction print it to stdout. If I have
misunderstood anything here, please correct me.

> 2. If you need to feed a secondary app data and get decoded data back out
in a
> loop (e.g. for DRPN), set up a named pipe. I think (someone correct me if
I'm
> wrong here) named pipes were carried over into NitrOS-9, so you could open
> something like /pipe/dprn in read+write mode in both processes and
communicate
> via a predefined protocol over the pipe. This way the two functions are
> separate processes with their own 64K process space. Communicating over a
pipe
> this way is slower than calling a function, but it is significantly faster
> than disk.

If I understand this part correctly, I can definitely have DRPN send its
result back to instruction. This is the way it is currently coded (as in
DRPN just parses the string, then returns to instruction to print it out).
I think I can modify the existing code to work with pipes, but I may need
some help with the actual syntax for forking the DRPN process and having
the pipes setup to be bi-directional.

I will post when I have tried it, and hopefully I won't have issues.

Wayne