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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
