Another way is to keep a running jhs, and send request to it using wget/curl. It also uses sockets but you need zero knowledge of socket programming. On Nov 10, 2015 10:51 PM, "Ian Clark" <[email protected]> wrote:
> > The problem with the daemon approach is making sure the daemon is alive > > Too right, @Joe. > > As I said in my (discarded) reply to Raul: > > …with all the attendant problems for the client of finding out: have > you finished yet? -- are you alive? -- are you actually installed? -- > and package it all up for general release, with no requirement for > customer customization, and be transparent to the user. The "user" in > this case being a novice J programmer, who is basically a novice in > any form of programming. > > Why are you and I the only J-ers who see this? :-) > > On Tue, Nov 10, 2015 at 2:45 PM, Joe Bogner <[email protected]> wrote: > >> 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''" > >> > > > > Thanks for elaborating > > > > Looks like a solid, simple solution to me. I wouldn't touch the > > sockets unless there was too much overhead in getting J back to the > > state desired to execute against (e.g. loading a large file) > > > > I've also used the 'silly' solution with J in a webapp awhile back to > > avoid mucking around with sockets and threads. > > > > The problem with the daemon approach is making sure the daemon is alive > > ---------------------------------------------------------------------- > > 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
