> I tried both with "CLIENT=: 0" and there wasn't a hard crash but both > seemed to freeze until they were done (w/o updating each other's windows).
Interesting behavior. On my Mac both processes appear to work correctly, but as if the sister process wasn't running. Freezing is what I frequently encounter when using a hard-looping duty cycle, which is why I always prefer to use a soft one. My original version had a soft duty cycle, as in: http://www.jsoftware.com/jwiki/IanClark/YellowJ but I replaced it with a hard loop because it complicated the demo: I didn't think people would appreciate the reason for going to the extra effort of having a soft duty cycle. The verb: duty_cycle won't work in J7 as it stands, because of the use of wd'timer'. But Eric showed in a recent thread how to replace it with an ajax-based timed callback -- and that works just fine for me. I now have all the components I need, in bits here and there. But can't spend any more time on it for a few days. But over the weekend I'll put it all together into a meaningful demo to post on the wiki. It will demonstrate "are-you-alive" between two processes, a J7 server and a J6 client running a jwd UI (...not just a curio: I do actually have a use for that). And with a bit of luck, I should have my Windows laptop back by then, so I can test it. On Mon, Jan 9, 2012 at 12:52 PM, Devon McCormick <devon...@gmail.com> wrote: > I tried both with "CLIENT=: 0" and there wasn't a hard crash but both > seemed to freeze until they were done (w/o updating each other's windows). > > On Mon, Jan 9, 2012 at 7:46 AM, Devon McCormick <devon...@gmail.com> wrote: > >> Actually, the first change I'd make would be to get rid of the "wd" stuff >> since I almost only use jconsole these days. This would also allow me to >> test it in J7. >> >> On Mon, Jan 9, 2012 at 7:09 AM, Ian Clark <earthspo...@gmail.com> wrote: >> >>> That's great. Thanks for the information, Devon. >>> >>> I guess you spotted that the number after: start is the number of >>> cycles you want it to do before stopping. If you want it to run >>> forever: >>> >>> start _ >>> >>> Then you can start and stop the other process for limited periods, and >>> watch the "die" and "resurrect" messages appear at will. >>> >>> I'm interested to know what happens under Windows if you run both >>> processes with CLIENT=0 by mistake. The detection algorithm won't work >>> of course, but since the two processes will then be asynchronously >>> updating the mapped noun CTL0 -- with no locking (unless jmf provides >>> it?) -- I'd guess there's a tiny chance of a hard crash? >>> >>> It's only a demo. In an operational app, with 3 or more processes, >>> each process as it starts should maybe look for the first CTL<n> >>> that's keeping a constant value, seize it and set CLIENT=n . >>> >>> ...Or you can ditch my simple scheme and use sockets. :) >>> >>> On Mon, Jan 9, 2012 at 5:17 AM, Devon McCormick <devon...@gmail.com> >>> wrote: >>> > It looks like it works OK: the "CLIENT=: 0" window gets its title bar >>> > updated until the "CLIENT=: 1" session ends, then it reports >>> > +---+-+------+------+--+ >>> > |die|0|778555|778553|88| >>> > +---+-+------+------+--+ >>> > duty: end. >>> > >>> > On Sun, Jan 8, 2012 at 10:39 PM, Ian Clark <earthspo...@gmail.com> >>> wrote: >>> > >>> >> aha... a word I've forgotten to include. Can you try adding this to >>> >> the script please?... >>> >> >>> >> jmf=: ] , ('.jmf' (#~) ([: -. ('.' e. ]))) >>> >> >>> >> (I've just fixed the script in the wiki.) >>> >> >>> >> On Mon, Jan 9, 2012 at 3:22 AM, Devon McCormick <devon...@gmail.com> >>> >> wrote: >>> >> > I get the following error attempting this under Windows XP: >>> >> > >>> >> > start 10 >>> >> > duty: starts... >>> >> > |value error: jmf >>> >> > | fi=.jpath'~temp/', jmf tolower y >>> >> > >>> >> > On Sun, Jan 8, 2012 at 8:32 PM, Ian Clark <earthspo...@gmail.com> >>> wrote: >>> >> > >>> >> >> Following Bill's warning, I've just corrected the downloadable >>> script: >>> >> >> alivedemo.ijs at: >>> >> >> http://www.jsoftware.com/jwiki/Scripts/AliveDemo >>> >> >> The "server" now accesses its jmf file using map_jmf, but the client >>> >> >> uses share_jmf_. >>> >> >> >>> >> >> Can somebody please verify it works under Windows and tell me? (I >>> >> >> don't currently have a windows machine). >>> >> >> >>> >> >> >>> >> >> On Sun, Jan 8, 2012 at 1:06 PM, Ian Clark <earthspo...@gmail.com> >>> >> wrote: >>> >> >> > I've just noticed that if IFUNIX then share_jmf_ calls map_jmf_ >>> to do >>> >> >> > the job. But if IFUNIX=0 then the code for share and map are >>> >> >> > different. Quite likely it won't work as it stands under Windows. >>> The >>> >> >> > workaround is for mapex to check the value of CLIENT and use >>> map_jmf_ >>> >> >> > if CLIENT=0, else share_jmf_ . >>> >> >> > >>> >> >> > On Sun, Jan 8, 2012 at 7:17 AM, bill lam <bbill....@gmail.com> >>> wrote: >>> >> >> >> Ian, >>> >> >> >> >>> >> >> >> I have not study the source carefully, but at the first glance, >>> it >>> >> >> seemed >>> >> >> >> that two running J processes accessing the same mapped file. Why >>> >> >> >> share_jmf_ was not needed? Please correct me if I missed >>> anything. >>> >> >> >> >>> >> >> >> Вск, 08 Янв 2012, Ian Clark писал(а): >>> >> >> >>> This is my eventual solution to the "are you alive?" problem: >>> >> >> >>> >>> >> >> >>> http://www.jsoftware.com/jwiki/Scripts/AliveDemo >>> >> >> >>> >>> >> >> >>> It doesn't use sockets, but a couple of mapped files instead. >>> The >>> >> >> >>> (identically coded) processes use them to play pat-a-cake. >>> >> >> >>> >>> >> >> >>> For demo simplicity I've coded a 'hard' duty cycle (a >>> while.-loop.) >>> >> >> >>> rather than one I find much more convenient: a "soft" duty cycle >>> >> that >>> >> >> >>> posts an event calling itself again after a given interval. >>> >> >> >>> >>> >> >> >>> A "soft" duty cycle has a lot of advantages. You have to play >>> with >>> >> the >>> >> >> >>> alternatives to appreciate them, but the main ones are that it >>> dies >>> >> >> >>> gracefully if there's a code error, and it doesn't lock the >>> session >>> >> >> >>> window and any UI which the duty cycle happens to be managing. >>> >> Indeed >>> >> >> >>> the duty cycle runs in the background, keeping all displays >>> >> up-to-date >>> >> >> >>> and leaving you (almost) full use of J facilities. >>> >> >> >>> >>> >> >> >>> I'll place a "soft" duty cycle code sample on the wiki in a day >>> or >>> >> two. >>> >> >> >>> >>> >> >> >>> On Mon, Jan 2, 2012 at 6:51 PM, Ian Clark < >>> earthspo...@gmail.com> >>> >> >> wrote: >>> >> >> >>> > Please forgive these questions I post to the list to which I >>> know >>> >> the >>> >> >> >>> > answer. Or rather: *an* answer. I learn a lot from others' >>> >> responses. >>> >> >> >>> > Even if it's "my way is best after all" -- that's a valuable >>> >> thing to >>> >> >> >>> > know. >>> >> >> >>> > >>> >> >> >>> > I have two separate J processes running (assume Linux / >>> Darwin, >>> >> >> though >>> >> >> >>> > I'm keen on cross-platform solutions). They communicate by >>> each >>> >> >> >>> > writing a text file which is read by the other >>> >> >> >>> > (keep-it-simple-stupid). Is there a neat, robust way of one >>> >> process >>> >> >> >>> > asking the other: "are you there?" or "are you still alive?" >>> >> >> >>> > >>> >> >> >>> > I'm au-fait with how the yellow-J works, all the solutions >>> >> involving >>> >> >> >>> > timer-driven duty-cycles, timeouts, and reading files written >>> by >>> >> the >>> >> >> >>> > sister process, Or the files' timestamps, or permissions. But >>> >> these >>> >> >> >>> > all seem so clunky. I guess what I want is something that was >>> so >>> >> easy >>> >> >> >>> > in the 1970s but is so awkward on today's machines: just >>> reserve a >>> >> >> >>> > pair of bits in absolute memory -- or a pair of pixels on the >>> >> screen >>> >> >> >>> > -- or some inessential system flags -- and play pat-a-cake >>> with >>> >> them. >>> >> >> >>> > >>> >> >> >>> > Once upon a time there was such a thing as "common memory". >>> >> >> >>> >>> >> ---------------------------------------------------------------------- >>> >> >> >>> For information about J forums see >>> >> http://www.jsoftware.com/forums.htm >>> >> >> >> >>> >> >> >> -- >>> >> >> >> regards, >>> >> >> >> ==================================================== >>> >> >> >> GPG key 1024D/4434BAB3 2008-08-24 >>> >> >> >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >>> >> >> >> >>> >> ---------------------------------------------------------------------- >>> >> >> >> For information about J forums see >>> >> http://www.jsoftware.com/forums.htm >>> >> >> >>> ---------------------------------------------------------------------- >>> >> >> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Devon McCormick, CFA >>> >> > ^me^ at acm. >>> >> > org is my >>> >> > preferred e-mail >>> >> > >>> ---------------------------------------------------------------------- >>> >> > For information about J forums see >>> http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >>> >> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> >>> > >>> > >>> > >>> > -- >>> > Devon McCormick, CFA >>> > ^me^ at acm. >>> > org is my >>> > preferred e-mail >>> > ---------------------------------------------------------------------- >>> > For information about J forums see http://www.jsoftware.com/forums.htm >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> >> >> >> -- >> Devon McCormick, CFA >> ^me^ at acm. >> org is my >> preferred e-mail >> >> > > > -- > Devon McCormick, CFA > ^me^ at acm. > org is my > preferred e-mail > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
