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
