[Coco] new problem with unpack

[Wayne Campbell]

I was thinking about this earlier this evening.

I was thinking if I knew how to use pipes, that might make the difference.
I have never seen a Basic09 procedure that made use of them before.
Tomorrow I will reread this post and see what I can do. 1 question. Is it
possible to leave the forked process running and re-access it as needed
during processing, and end the process in cleanup after processing?

Wayne
 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.
>
> 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.
>
> -----Original Message----- From: Wayne Campbell
> Sent: Wednesday, October 30, 2013 5:42 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] new problem with unpack
>
> I have been able to get unpack to work more reliably, but there is still a
> major malfunction. I split readCode into two procedures, readCode and
> lineNums. I also removed the code for all the counters I was tracking in
> decode. This got around the problem as far as beginning the unpack is
> concerned. Now I can run it with a #16k modifier and it will go all the way
> to instruction before bombing.
>
> The problem with instruction is that it and DRPN (currently) are both in
> memory at the same time, and DRPN is being called for each instruction line
> being built by instruction. Because the data memory requirements for each
> call for a 8K block each, there isn't sufficient memory left to allocate
> enough for both procedures. I am still thinking about what to do. I did
> remove the code for creating the .B09 source code file. When unpack works
> completely, you will be required to redirect stdout to a file.
>
> DCom 1.0 provides a possible solution. I don't have that code anymore, but
> what it did was simple. DInstr (the equivalent of instruction) wrote all of
> it's output to a file. DRPN read that file and parsed it so the resulting
> output would be source code. It worked as a standalone procedure. I
> modified it in DCom2.0 to work within DCom as a part of DInstr. Those two
> files and hex$ were all packed and loaded together, and it worked. I think
> it is the bug-fixes I have made to DRPN as a result of decode that may be
> part of the reason it won't work now.
>
> I may try separating DRPN out to work apart from instruction. It will mean
> adding the output file back in, but with changes, and then changes to DRPN
> to handle opening the file and reading it's input from there. I do not know
> how much this will increase the time it takes unpack to do its thing.
>
> Wayne
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>