The only use of 'wd' is in the verb: cycle_caption, used to write a
running trace message to the window caption. I wanted to avoid using
smoutput. But why not just try running it in jconsole after having
entered:
cycle_caption=: smoutput
On Mon, Jan 9, 2012 at 12:46 PM, 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
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
