#Using PIPE:
7 messages in this thread
What's the deal with PIPE:
It seems like a good way to send files between programs, but it doesn't seem to
work too well in practice. i.e Save to PIPE: from one program, then Load from
PIPE: in another.
DPaintIV says "Not a valid device", DPaintV seems to like saving to it, but
PageStream says "file format not recognized" when importing, PgS will send to
Pipe:, but DPaintV wontn't load the PgS pic from Pipe:. etc, etc. Works good
between CLIs, but that's about it!
Any "enlightenment" would be appreciated???
Thanks,
/ / / //ANDRE
The thing about PIPE: is that it has a limited capacity, deliberately. Send
a long document or file to it, and it will quickly become full and tell the
sender to hold back further data.
As data is taken out of the PIPE: space becomes available and then sender is
allowed to send more to "top up" the data area.
So it operates generally this way: if the sender is FASTER than the
receiving program, the sender is slowed. On the other hand, if the sender is
not faster, it can always send at full speed.
Example: say you have a program that produces HUGE output, from which you
wanted to extract only certain data. If the program just put its output to RAM
disk, it might run you out of memory. If the program put its output to hard
disk, you'd likely have space, but you might slow things down more than you
would be comfortable with (and need to clean up the HD file later). So .. you
send the program's output to PIPE: and have your extracting/scanning program
read that file.
–Jim
Thanks Jim,
That explains How it works, but not why it doesn't seem to be practical between
regular applications. I usually save/read from RAM: but thought PIPE: would be
a little easier/faster.
I also notice APIPE: is that an improved version or something? Nothing in the
docs about it.
/ / / //ANDRE
APIPE: .. don't know it, but perhaps somebody who uses it can respond here.
About practicality: it depends on the usage. The program sending to a PIPE:
file won't terminate until it gets rid of all its data, so it may give the
impression of "hanging". Or, if the next program in line is doing something
like a sort, it will need ALL the data before it can do useful sorting work; in
that case, the pipe file's function as a flow control and buffer doesn't do
much for you.
–Jim
> About practicality: it depends on the usage.
Guess I'll keep on using RAM: or STAT-RAM: instead.
Thanks,
/ / / //ANDRE
Andre,
PIPE: is a streaming device, like SER: is. There is no filesystem attatched to
PIPE:, so a program cannot do a Seek() in the PIPE: nor can it look for
directories and that stuff (although you can open different `channels' in PIPE:
by attatching different `filenames', like PIPE:file.1).
RAM: is file system driven, so it can be used like a disk or any other random
access device.
If the output from a programm is, say, in IFF format, and the second program
wants to read this file using the iffparse.library, this will probably fail
with PIPE:, because the iffparse.library wants to Seek() in the file.
– wkc – … via AP from Hamburg, Germany
Thanks Werner,
That explains things a little more clearly as to why I can't use PIPE: as I
wanted to. It seemed like a good idea at the time!
/ / / //ANDRE