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
