@Joe - thanks for drawing my attention to the existence of this addon. I'd forgotten about it, and was planning to start down the same route after revisiting the lab: Socket Driver Server, which exercises the lower level sd* verbs.
> make client calls using NSTask presumably by invoking jconsole with the jssc > client to make calls to the server Yes, I agree. > You mentioned wanting to avoid sockets but didn't elaborate …you're inviting me to elaborate? I did, in a draft of an earlier reply. Then realized I was just telling war-stories. So I just said "The result will be oh-so-robust, because there's so little to go wrong." Anyway, things might have moved on in 12 years. But AFAICS they haven't. It's not sockets that stick in my craw so much as toy daemons. What's available in JAL are the tools for a promising solution, not a solution. It hasn't escaped my attention that jss stands for "J simple socket server" – which says to me that something more complicated might be needed in practice. As Radio Shack used to say: "Some Soldering Required". That shouldn't trouble a seasoned J jock. But for the present thread I've got a different hat on: as an Apple developer using Xcode for a shrinkwrapped product that calls J as a daemon for its services. What's currently *not* on offer from Jsoftware – correct me if I'm wrong – is a robust off-the-shelf daemon (from a registered Apple developer! – but that's another story) – with plenty of flying-hours behind it – that can be called like this (say): $ jconsole -server However, my "silly" solution (suggested earlier) is indeed robust – and I've just been doing experiments on this: $ jconsole -js a=.23 b=.3 "echo a*b" "exit''" quoting the example directly from http://jsoftware.com/help/user/cmdline.htm So that's the way I'm going to go, to the point of a demonstrable prototype. Only then should I delve into J running as a daemon to achieve better performance. (If it's needed). Ian On Tue, Nov 10, 2015 at 4:47 AM, Joe Bogner <[email protected]> wrote: > Hi Ian, > > Have you looked at the clientserver addon? > http://jsoftware.com/wsvn/addons/trunk/net/clientserver/jssc.ijs > > You could run the server as the daemon and then make client calls using > NSTask presumably by invoking jconsole with the jssc client to make calls > to the server > > You mentioned wanting to avoid sockets but didn't elaborate > On Nov 9, 2015 10:22 PM, "Ian Clark" <[email protected]> wrote: > >> That's exactly what I'm going to do, @Don. >> It's the "silly solution" I proposed in my original post, but after a >> few trials, I've decided it's not so silly after all. >> >> There will only be one call of jconsole needed following each user >> interaction with my proposed Xcode-written top-end. Not one per J >> statement. >> >> The time to setup up and teardown the J environment several times in a >> typical session (of which saving and reloading a script of the changed >> variables is normally only a small proportion) seems tolerable in >> practice, indeed hardly noticeable. Gotchers may emerge farther into >> the project, but for now I can proceed with building a prototype >> without having to work out how to converse with a long-running J >> daemon. The result will be oh-so-robust, because there's so little to >> go wrong. >> >> (But it would be nice to know how to do it the daemon way.) >> >> Ian >> >> On Mon, Nov 9, 2015 at 9:25 PM, Don Guinn <[email protected]> wrote: >> > You could write out pertinent data to a file before ending the J session >> to >> > read back in when you run jconsole again. >> > >> > On Mon, Nov 9, 2015 at 1:20 PM, Ian Clark <[email protected]> wrote: >> > >> >> > You should think of each terminal command line as simulating a >> separate >> >> run of the program you are modeling. >> >> >> >> That is my understanding too. Therefore I guess the only way I can >> >> communicate sensibly via Terminal with a daemon listening on a port is >> >> via something like netcat. As per your example, or one of the examples >> >> given by: man nc. This is precisely where the usage of NSTask is hazy >> >> to me, and the documentation doesn't seem to help (or else I can't >> >> read it properly). I'm going to look for more sample code. >> >> >> >> On Mon, Nov 9, 2015 at 8:10 PM, Raul Miller <[email protected]> >> wrote: >> >> > On Mon, Nov 9, 2015 at 3:04 PM, Ian Clark <[email protected]> >> wrote: >> >> >> However I don't yet know how to converse via NSTask with a daemon >> >> >> through a port. I need to find a tame daemon that will talk to me >> >> >> nicely via Mac Terminal, which I can then try to handle via NSTask. >> >> >> Then I'll feel more confident about conversing with a long-running >> >> >> jconsole process. >> >> > >> >> > I think you have conflicting (internally inconsistent) requirements >> here. >> >> > >> >> > You should think of each terminal command line as simulating a >> >> > separate run of the program you are modeling. >> >> > >> >> > Thanks, >> >> > >> >> > -- >> >> > Raul >> >> > ---------------------------------------------------------------------- >> >> > For information about J forums see >> http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> >> For information about J forums see http://www.jsoftware.com/forums.htm >> >> >> > ---------------------------------------------------------------------- >> > For information about J forums see http://www.jsoftware.com/forums.htm >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
