Robo_Pi
Posts: 85
Joined: Fri Jun 19, 2015 1:18 am

Passing Data and Commands between programs

Thu Oct 22, 2015 7:29 pm

Hi everyone,

I have a few questions about writing programs to talk to each other. Currently I'm writing programs on a Notebook computer using C# and these programs will be exchanging two-way data and commands with programs written in Python on a Raspberry Pi. The precise languages I'm using may change over time as I am currently also learning C and C++. Right now I'm just looking for ideas on how best to implement the exchange of data.

Using Text Files
The connection between the Notebook and the Raspberry Pi is WiFi. I also have file sharing set up. So I've currently been having these programs exchange data and commands by simply using shared text files. This method is currently working, although it would be nice to see examples of how other people have used file sharing as a means of communicating between programs. So if anyone can offer experience in this area, or point to links that describe this method of exchanging data between programs that could prove to be helpful.

Alternative Methods
I guess this is the real reason I'm posting here. I imagine there are other methods for having programs exchange data over WiFi perhaps by directly talking to each other through a common port or socket of some sort? I'm thinking that methods along these lines would have other advantages like possibly allowing one program to "tap" the other program on the shoulder when it wants to communicate with it. Currently with my file sharing method the programs aren't really in direct communication with each other. One program can't really get the attention of the other program until the other program just happens to read a text file.

So I'm open to Alternative Methods of having these programs directly communicate with each other. Obviously even in that situation they would still be able to share text files too. So that can only be an improvement over sharing text files alone.

So I'm open to all possibilities.

Just as a final note. I'm pretty lame, and my experience with programming in general is lacking. So, if possible, it would be very helpful if code examples or links to code examples could be included. And so far I only have a rudimentary understanding of Python, C#, C, and C++. On the bright side I just bought "pocket references" for all of these languages, and I'm determined to learn them all. Every program I write, I try to write it in all four of these languages. :D

User avatar
PeterO
Posts: 5159
Joined: Sun Jul 22, 2012 4:14 pm

Re: Passing Data and Commands between programs

Thu Oct 22, 2015 7:41 pm

Sockets are the way to go....
Python example code here :
https://wiki.python.org/moin/TcpCommunication
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
topguy
Posts: 5967
Joined: Tue Oct 09, 2012 11:46 am
Location: Trondheim, Norway

Re: Passing Data and Commands between programs

Fri Oct 23, 2015 4:10 pm

If you dont want to learn all the ins and outs of socket-programming it might be worth looking at existing solutions for messaging between programs. ZeroMQ and MQTT are libraries that has support for the languages you describe (and many more) and is suitable if there is small and frequent exchanges of information between the programs.

If your needs are to transfer long continous streams of data or larger (megabytes) data buffers then sockets probably if fine.

If you can describe what kind of data that is going to be exchanged between your programs and if there is some specific logic to it.
( example: one program is a slave and the other a master that always tells the slave to do something )
Then we can give better recommendations.

Trailing Dots
Posts: 3
Joined: Tue Jul 05, 2016 8:34 pm

Re: Passing Data and Commands between programs

Tue Jul 05, 2016 8:42 pm

An easy to use python library for Raspberry Pi communications is at
https://github.com/TrailingDots/easy_py_messaging.git

This library is targeted to noobies that in python programming.
It uses ZeroMQ as a basis for this code.
A somewhat extensive set of documentation and tutorials
assist in using this in your programs.

Heater
Posts: 13930
Joined: Tue Jul 17, 2012 3:02 pm

Re: Passing Data and Commands between programs

Wed Jul 06, 2016 4:52 am

MQTT is a good idea for simple messaging between programs. Saves a lot of messing around with socket programming.

I use msquitto as the MQTT message broker. Install on the Pi like so:

$ sudo apt-get install mosquitto

Now you can test it works from the command line.

In one terminal window and listen for messages (subscribe):

$ mosquitto_sub -h localhost -t myMessage -v

In another terminal window send messages (publish) to mosquitto:

$ mosquitto_pub -h localhost -t myMessage -m "Hello world"

Notes that there can be many subscribers to the same message topic and they will all get the message published on that topic.

With that working you just need to get an MQTT library for your language of choice and do all the above from your programs.

https://mosquitto.org/
Memory in C++ is a leaky abstraction .

mattmiller
Posts: 2138
Joined: Thu Feb 05, 2015 11:25 pm

Re: Passing Data and Commands between programs

Wed Jul 06, 2016 5:59 am

I'm also big fan of MQTT - using it to send msgs between Pi around my house

I'm using the paho python library

https://pypi.python.org/pypi/paho-mqtt/1.1#installation

I'm hosting the broker on my main WinPC as its always on but you can use any computer inc Pi to host one

I also use plain sockets but the small overhead/learning of MQTT is well worth it (you can ignore using threading for instance)
Matthew

richrarobi
Posts: 271
Joined: Sun Feb 08, 2015 1:13 pm

Re: Passing Data and Commands between programs

Sat Aug 27, 2016 8:58 pm

I liked mqtt, but not the need for a broker. Have returned to zmq after not liking that thefirst time round. Wrote python classes libraries for Req/Reply and Pub/Sub that I can use thru' multiprocessing Python 3.4 without rewriting code on each machine. I very much like zmq in that that I can update individual systems code without having to restart all the world. No nasty errors, zmq just waits to reconnect and continue....Pub/Sub gives you asynch data distribution, Req/Rep gives you close to remote function calls.
Again using zmq also to send messages between pi's and other systems around the house. Next challenge is getting the pictures from "window" pi.....
p.s. other languages supported, too...

richrarobi
Posts: 271
Joined: Sun Feb 08, 2015 1:13 pm

Re: Passing Data and Commands between programs

Tue Sep 06, 2016 6:26 pm

here is my simple/compact (almost) understandable rpc system using zmq:-
reply server to run on each "server" (note I use Python 3.4):-

Code: Select all

#!/usr/bin/python3
# Filename: zrep.py
#
from time import sleep
import pickle
import zmq
import zlocal
import importlib

class Reply:
    def __init__(self):
        self.functions = { }

    def wait(self, sock):
        try:
            [func, args, kwargs] = pickle.loads(sock.recv())
            try:
                module = importlib.import_module('zlocal')
                fn = getattr(module, func)
                if callable(fn):
                    reply = fn(*args, **kwargs)
                sock.send(pickle.dumps(reply))
            except Exception as e:
                sock.send(pickle.dumps(e))
        except zmq.Again as e:
            pass

if __name__ == "__main__":
# zmq port on system f
    port="5562"
    context = zmq.Context()
    sock = context.socket(zmq.REP)
    sock.bind("tcp://*:%s" % port)
    rp = Reply()

    try:
        while True:
            try:
                rp.wait(sock)
            except:
                pass
            sleep(1)
#            print("looping")
    except KeyboardInterrupt:
        sleep(2)
        print ("program stopped")
        sleep(2)

note the port (assigned to each system).....
the functions look like this:

Code: Select all

#!/usr/bin/python3
# zlocal.py on d
#functions used by zrep

import datetime
from time import sleep

def test_1(a, b, c):
    reply= "a={}, b={}, c={}, total={}".format(a,b,c,a+b+c)
    return reply

def test_2(a, b, c, n):
    reply = "a={}, b={}, c={}, n={}".format(a,b,c,n)
    return reply

def takePic():
    import picamera
    import os
    with picamera.PiCamera() as camera:
        camera.resolution = (640, 480)
        camera.vflip = True
        camera.hflip = True
        camera.start_preview()
# Camera warm-up time
        sleep(5)
        camera.capture('foo.jpg')
        sleep(2)
    return "Picture taken"

def sendPic():
    import os
    f = open('foo.jpg', 'rb')
    data = bytearray(os.path.getsize('foo.jpg'))
    f.readinto(data)
    print(len(data))
    return data

def getTmp():
    import subprocess
    tmp = subprocess.check_output(["/opt/vc/bin/vcgencmd", "measure_temp"])
    tmp = tmp.decode("utf-8")
    tmp = "on d: {}".format(tmp).rstrip("\n")
    return tmp

calling routine looks like this:

Code: Select all

#!/usr/bin/python3
# zrpc on f

from time import sleep
import zmq
from multiprocessing import Process
import pickle
import random
from zlocal import savePic

class ZProxy:
    def __init__(self, url):
        context = zmq.Context()
        self.sock = context.socket(zmq.REQ)
        self.sock.connect("tcp://{}".format(url))
        
    def __getattr__(self, name):
        def rpc(*args, **kwargs):
            try:
                self.sock.send(pickle.dumps((name, args, kwargs)))
            except zmq.ZMQError as e:
                print(e)
            reply = pickle.loads(self.sock.recv())
            if isinstance(reply, Exception):
                raise reply
            return reply
        return rpc

def getT(url):
    zp = ZProxy(url)
    while True:
        print (zp.getTmp())
        sleep(60)

def BgetBrng(url):
    zp = ZProxy(url)
    while True:
        print (zp.getBearing())
        sleep(10)

def Btests(url):
    zp = ZProxy(url)
    while True:
        print(zp.test_1(random.randint(1, 50),
                        random.randint(1, 50),
                        random.randint(1, 50)))
        print(zp.test_2(b=3,a=5,c=7, n="hello b"))
        sleep(15)

def EgetSns(url):
    zp = ZProxy(url)
    while True:
        print(zp.getSenses())
        sleep(300)

def pict(url):
    zp = ZProxy(url)
    while True:
        x=zp.takePic()
#        print(x)
        sleep(2)
        pic = zp.sendPic()
        fh = open("foo.jpg", "wb")
        fh.write(bytearray(i for i in pic))
        fh.close()
        print("pic saved")
        sleep(60)

if __name__ == "__main__":
    process=Process()
    burl="b.local:5556"
#    curl=
    durl="d.local:5558"
    eurl="e.local:5560"
    furl="f.local:5562"

    try:
        Process(target=getT, args=(burl,), daemon=True).start()
        Process(target=getT, args=(durl,), daemon=True).start()
        Process(target=getT, args=(eurl,), daemon=True).start()
        Process(target=getT, args=(furl,), daemon=True).start()
        Process(target=EgetSns, args=(eurl,), daemon=True).start()
        Process(target=BgetBrng, args=(burl,), daemon=True).start()
        Process(target=pict, args=(durl,), daemon=True).start()
        Process(target=Btests, args=(burl,), daemon=True).start()
        while True:
            sleep(15)
#            print("looping")

    except KeyboardInterrupt:
        sleep(2)
        print ("program stopped")
        sleep(2)

You need a different port number for each system and setup a different proxy name....
note that for keyboardInterrupt exception to work nicely, each multiprocess needs the try / except for keyboardInterrupt
output looks like something this:

Code: Select all

on f: temp=39.7'C
55
on e: temp=32.0'C
on b: temp=33.1'C
{'bearing': 319.95, 'z_out': 462.76, 'y_out': -140.76, 'x_out': 167.44}
{'humi': 67, 'tmpr': 18, 'baro': 1008}
a=5, b=3, c=7, n=hello b
Picture taken
on d: temp=34.7'C
saved pic
pic saved?
{'bearing': 320.13, 'z_out': 462.76, 'y_out': -139.84, 'x_out': 167.44}
109
a=5, b=3, c=7, n=hello b
{'bearing': 319.98, 'z_out': 463.68, 'y_out': -139.84, 'x_out': 166.52}
{'bearing': 320.13, 'z_out': 462.76, 'y_out': -139.84, 'x_out': 167.44}
101
a=5, b=3, c=7, n=hello b
{'bearing': 320.1, 'z_out': 462.76, 'y_out': -140.76, 'x_out': 168.36}

There is no reason you can't run a whole bunch of systems, cooperating simply with this....Only issue so far is that if one system is down it will wait... therefore need to use threading, etc to separate connections. (AS UPDATED CODE ABOVE)
Last edited by richrarobi on Thu Nov 03, 2016 11:56 pm, edited 8 times in total.

User avatar
DougieLawson
Posts: 36578
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Passing Data and Commands between programs

Wed Sep 07, 2016 7:56 am

Use MQTT it's much easier than anything else.

I get my version from http://mosquitto.org/2013/01/mosquitto- ... epository/ to keep up to date with Roger Light's latest development and enhancements. My version includes websockets which aren't in the ancient Jessie version.

Calling a simple messaging API is easier than any sockets or rpc programs.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

Heater
Posts: 13930
Joined: Tue Jul 17, 2012 3:02 pm

Re: Passing Data and Commands between programs

Wed Sep 07, 2016 9:53 am

I second Dougie's MQTT suggestion. I just use the version of mosquito in Jessie. It's so simple.
Memory in C++ is a leaky abstraction .

richrarobi
Posts: 271
Joined: Sun Feb 08, 2015 1:13 pm

Re: Passing Data and Commands between programs

Thu Sep 15, 2016 7:18 am

I did a search for RPC style solutions. Apparently :
MQTT is a PUB/SUB system and doesn't lend itself well to RPC. While you could possibly shoehorn something on top of MQTT to simulate the synchronicity required, you are probably better off looking for a system which provides real RPC semantics.
I would be very interested in how your use of MQTT provides a RPC style solution, where one or more active systems may transparently 'make use of' functions (Functions?) located on peer systems. Any simple examples available? Certainly others would be interested, too?
ZMQ (pyZMQ) seems to suit my purpose better. My implementation originally included PUB/SUB, for a 'lazy' loosely coupled transfer of data, however this uses more resources because the publisher is active constantly even when the 'user' is idle. RPC is active when needed and not otherwise. (Also I kept getting confused with everything happening at once, so removed the code to let my brain cool down!!)
RichR
p.s. As I have said before, I liked MQTT, but not the need for a broker.
p.p.s. I updated my code example in previous post in case anyone wants to try this stuff. It is now even simpler.
n.b. Always check with HTOP that your multiprocessing code isn't going awry....If multiprocessing is a bit 'step too far' you can always write individual code for each "job" (i.e. one checking all the system states, etc...)

p.ppp.s I found that using the above to tell another pi take & transfer pictures was VERY slow. After some research I have changed from demjson to pickle. It is now "instantaneous" with pickle, even across wifi.
Updated the code in case anyone wants it! (Note that savePic is run on the calling system (see pict)

tdarrah
Posts: 3
Joined: Wed Sep 28, 2016 9:20 pm

Re: Passing Data and Commands between programs

Thu Oct 06, 2016 8:04 pm

I followed this https://mosquitto.org/2013/01/mosquitto ... epository/ for installing mqtt as well as this one http://www.instructables.com/id/Install ... /?ALLSTEPS and still getting error connection refused. I am simply trying to get two raspberry pis to read and write to the same topic. They are both on the same network. thanks for the help.

PS

I have also read your posts here viewtopic.php?f=28&t=97422 and somewhere else. When I ran the ps ... grep grep command I got nothing. My interfaces file is fine.

raspberryPi ~$ mosquitto_sub -d -t topic --> Error: connection refused
raspberryPi ~$ mosquitto_sub -h 192.168.1.11 -t topic (other raspberry pi) --> No route to host
raspberryPi~$ mosquitto_sub -h 192.168.1.10 -t topic (this raspberry pi) --> Error: connection refused

Im running jessie on one pi and wheezy on the other (shouldn't matter tho)

Thanks again

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 4:30 am

As you are asking about exchanging information over a TCP/IP network, forget attempting to make it WiFi specific.

Just use the Sockets library to create a connection listen()+accept()/connect() and send()/recieve(). Just about all platforms provide the sockets library, in some cases extended though you can ignore the exensions as they are often platform specific, just use the core sockets library.

That is the easy way around it, no need to use files of any kind.

It does not matter what protocal is used on the physical level (802.3 ethernet, 802.11 WiFi, PPP, SLiP, etc) if you are on a TCP/IP network the Sockets library makes it easy to communicate over the connection.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13930
Joined: Tue Jul 17, 2012 3:02 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 6:14 am

tdarrah,

Can you ping from each Pi to the other on your local network? For example:

$ ping 192.168.1.11

Does it work? If not you have a network configuration problem that needs to be fixed first.

I it works then can you see mosquitto running on whichever Pi it should be?

$ ps -A | grep mos

If so can you publish and subscribe to mosquitto localy, on the same Pi

$ mosquitto_sub -h localhost .....
$ mosquitto_pub -h localhost .....

If that works then you should be able to do the same form the other Pi

$ mosquitto_sub -h whateverAddress .....
$ mosquitto_pub -h whateverAddress .....

If not do you have some firewall rules in place?
Memory in C++ is a leaky abstraction .

Heater
Posts: 13930
Joined: Tue Jul 17, 2012 3:02 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 6:20 am

Using raw sockets is not the easy way around.

You have to take care of all the connecting, reconnecting, error checking business. Oh and dns lookup.

You have to invent your own protocol to format the data in. For example when using a TCP/IP stream you have to know when meaningful lumps of data start and end. You have to parse the stream somehow.

All of which is a lot more work than using MQTT for example:

Code: Select all

var client  = mqtt.connect(someAddressOrDomainName);
...
... 
   client.subscribe('presence')
...
...
   client.publish('presence', 'Hello mqtt')
...
...
client.on('message', function (topic, message) {
    console.log(message.toString())
}
Memory in C++ is a leaky abstraction .

mattmiller
Posts: 2138
Joined: Thu Feb 05, 2015 11:25 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 7:31 am

Sockets is they way for propriety point to point or when you have to talk to an existing proprietary protocol

But you'd have to be some sort of masochist to want to use them for a simple application nowadays when such things as MQTT exist :)

zmq looks like a reasonable candidate for making sockets easier to work with if you need/want to avoid using an MQTT broker

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 4:44 pm

Really using something that is an extra layer?

The TCP protocal gives the packet sequence information, that is one of the advantages of TCP over just strait IP.

The header of a TCP packet for IPv4 is (big endian format, packed struct):

Code: Select all

typedef struct {
 uint16 srcport,dstport;
 uint32 seqnum;
 uint32 ackn;
 uint8  offset, flags;
 uint16 window;
 uint16 chksum;
 uint16 urgentptr;
 uint32 opt;
} _TCP_HEADER_;
You will note that the 3rd item is sequence number, and that the 5th item is offset. So what is all this about using some other protocal to make it easier than simply using TCP/IP over the sockets interface? You have the crc for error checking built in, you have the packet sequence built into TCP, you need only have the size of the stream in your first packet (at the beggining of the transmitted data) and then pay attention to the header, it is all done for you.

Managing connections is not hard, on the receiving end start a thread to listen on the port you are using, then once a request is received on that port accept the connection and do receive as long as needed. On the sending end just open a connection to the destination on the needed port then send as long as needed.

If you included a the stream size in the beginning of the data stream as an integer type value, you need only use a simple for loop to manage the receive (4 line for loop at that).

So why not do it the easy way.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13930
Joined: Tue Jul 17, 2012 3:02 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 5:04 pm

The whole point of TCP/IP is that when you get a connection the data your receive is in the right order. Don't forget that IP packets sent across the net can take different routes and arrive at different times, perhaps out of order. You have to chop your data into packets because IP has packets with a limited size. That is a problem.

TCP/IP takes care of all that and delivers your application all the bytes as a stream in the order they were sent.

If you don't care about the order of messages and your messages fit in an IP packet then don't use TCP/IP, use UDP.

Your TCP/IP packet information is nice and all. But don't forget the packets I send may not be the same as the packets your receive. Routers along the way can chop packets up as they see fit.

In your scheme, David, if I want send a long message then I have to do all the packet reassembly at the receiving end, and make sure I have things in the right order. Everything that TCP/IP does very well already.

Finally,
If you included a the stream size in the beginning...
Like I said, you have to invent your own protocol.

Why do that? Why not just use a protocol that others have spent a long time getting to work properly already?

And finally, finally...

Your code listing of a packet header is already longer than the code required to do the job using MQTT or whatever. And what happens when you want to use IPV6 instead?
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 5:16 pm

Heater wrote:The whole point of TCP/IP is that when you get a connection the data your receive is in the right order. Don't forget that IP packets sent across the net can take different routes and arrive at different times, perhaps out of order. You have to chop your data into packets because IP has packets with a limited size. That is a problem.

TCP/IP takes care of all that and delivers your application all the bytes as a stream in the order they were sent.

If you don't care about the order of messages and your messages fit in an IP packet then don't use TCP/IP, use UDP.

Your TCP/IP packet information is nice and all. But don't forget the packets I send may not be the same as the packets your receive. Routers along the way can chop packets up as they see fit.

In your scheme, David, if I want send a long message then I have to do all the packet reassembly at the receiving end, and make sure I have things in the right order. Everything that TCP/IP does very well already.

Finally,
If you included a the stream size in the beginning...
Like I said, you have to invent your own protocol.

Why do that? Why not just use a protocol that others have spent a long time getting to work properly already?

And finally, finally...

Your code listing of a packet header is already longer than the code required to do the job using MQTT or whatever. And what happens when you want to use IPV6 instead?
The struct is only to illistrate how the header is formated, yes routers will change things though everything will still be correct when it reaches its destination (regardless of the order it is recieved). Yes multiple routes are common, do to TCP/IP being designed explicitly to survive a nuclear holocaust (hence why no one location can ever disable the internet).

You would never use the packet header explicitly, the sockets implementation takes care of that part for you. So you never need to know about the details that I posted above (other than how to quickly set up a connection).

And sockets handles DNS look up for you as well, so that is not an issue.

So why recommend a newer protocol that may or may not end up widely adopted, just because there are those that use it now does not mean it will last (remember our talks about Pascal). Also there is no way to be sure how many systems will support the newer protocol. So I guess it is good if you do not mind extra coding and not knowing if your code is future proof.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

richrarobi
Posts: 271
Joined: Sun Feb 08, 2015 1:13 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 5:38 pm

David, Are you really suggesting that people researching such things as:
e.g. swarm robotics https://en.wikipedia.org/wiki/Swarm_robotics
should eschew the excellent third party tools such as mqtt and zmq, and all the facilities included therein, in order to avoid adding another layer to the computing environment?
Next, you will be suggesting we all write our own i/o environment, such as keyboard and teleprinter output? Hollerith cards?
Surely, the whole point of layered functionality is that the combined expertise is greater than that provided by a single linear personality?
Pull away from bits and bytes and look to the future.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 6:15 pm

richrarobi wrote:David, Are you really suggesting that people researching such things as:
e.g. swarm robotics https://en.wikipedia.org/wiki/Swarm_robotics
should eschew the excellent third party tools such as mqtt and zmq, and all the facilities included therein, in order to avoid adding another layer to the computing environment?
Next, you will be suggesting we all write our own i/o environment, such as keyboard and teleprinter output? Hollerith cards?
Surely, the whole point of layered functionality is that the combined expertise is greater than that provided by a single linear personality?
Pull away from bits and bytes and look to the future.
I did not say that.

I said use the simplest method for the job. That is the method that will take the least design and coding.

In some cases it makes since to use extended libraries, in other cases it is easier to use the main library for a given task.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
topguy
Posts: 5967
Joined: Tue Oct 09, 2012 11:46 am
Location: Trondheim, Norway

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 6:28 pm

You guys are still arguing in a thread that is 1 year old that someone just happened to hijack with an almost completely different problem.
Don't you have better things to do ? ;)

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 8:21 pm

topguy wrote:You guys are still arguing in a thread that is 1 year old that someone just happened to hijack with an almost completely different problem.
Don't you have better things to do ? ;)
Just attempting to help the OP.

And through friendly disagreement we all learn, it is all part of the cycle of things. You ask 100 Software Engineers (read programmers) for a solution to a problem you will get 10000 answers :) .
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13930
Joined: Tue Jul 17, 2012 3:02 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 8:55 pm

topguy,
Don't you have better things to do ?
No.

I have finished my days work.

What better use of my time could there be than correcting misinformation on the net so that millions of readers don't get confused?

robo_pi never bothered to check back here so anything goes.

OK, perhaps you are right. I should just crack open a beer and watch telly.
Memory in C++ is a leaky abstraction .

stderr
Posts: 2178
Joined: Sat Dec 01, 2012 11:29 pm

Re: Passing Data and Commands between programs

Fri Oct 07, 2016 11:07 pm

mattmiller wrote:But you'd have to be some sort of masochist to want to use them for
In a bit of possible braggadocio, he points to the cheap seats over in left field, that's where it's going, he says. Can he deliver, is it hubris, an idle boast? He waits for the wind up, now the pitch, he swings, bang, it's high enough, yes, it's far enough, it's a home run! The crowd goes wild, it's going into a seventh game, the 10th inning, something surely. All gentle readers wait in quiet repose for David's retort. It better be good, said the adman, we need a ratings boost.

Return to “General programming discussion”