Revolution and Task (handler) Overlap

[Gary Dennis]

Thank you

Except for the few comments below, see other response.

----- Original Message -----
From: "Heather Williams" <heather at runrev.com>
To: <use-revolution at lists.runrev.com>
Sent: Saturday, February 09, 2002 4:06 AM
Subject: FW: Revolution and Task (handler) Overlap


>
> --
> Heather Williams <heather at runrev.com> <http://www.runrev.com/>
> Runtime Revolution Ltd.
> Tel: +44 (0) 131 7184333 Fax: +44 (0)1639 830707
> Ten Thumbs Typing Tutor Teach your Fingers to Dance
>
> ------ Forwarded Message
> From: David Vaughan <drvaughan55 at mac.com>
> Date: Sat, 9 Feb 2002 16:02:36 +1100
> To: use-revolution at lists.runrev.com
> Subject: Re: Revolution  and Task (handler) Overlap
> Resent-From: David Vaughan <drvaughan55 at mac.com>
> Resent-To: use-revolution-admin at lists.runrev.com
> Resent-Date: Sat, 9 Feb 2002 17:27:05 +1100
>
> I concur with all of Scott's comments (including his PS) and have added
> a couple.
> It actually sounds like a task that may need some pre-processing in
> something like sed to filter requisite data into the Rev management app.
>
> On Saturday, February 9, 2002, at 03:31 , Scott Raney wrote:
>
> > On Fri, 8 Feb 2002 "Gary Dennis" <gary.dennis at mantissa.com> wrote:
> >
> >> Please forgive the minutiae [get your Latin right :-)] that follows
> >> but I am looking at developing
> snip
> >> The test case application receives console output from multiple IBM
> >> mainframe systems and filters the console data to call operator
> >> attention to
> >> high priority messages.    Because some of these mainframes have up to
> >> 800
> >> active tasks the volume can be substantial  (on the order of 5000
> >> messages
> >> per minute).  The average length of  each message is approximately 300
> >> bytes.
> >
> > Multiplying those together and you end up with just log files that are
> > growing by 2GB *per day*.  My first thought is that it might be worth
> > investigating having those systems spew out a little less garbage ;-)
> >
> snip
> >> At this point in the development, all the test case product actually
> >> did was
> >> a.) get the message buffer, b.) break the buffer down into lines (crlf
> >> delimited message lines, the lf corresponds to the Rev RETURN, the cr
> >> part
> >> of the message is discarded)
> Why? Rev knows what a line is in the different environments, and it
> seems to be lines you want to process.

We let REV do that already, we are not looking byte -byte to determine where
the line ends.


>
> >>  and c.) place the  message lines AFTER a
> >> scrollable field defined on a card.  After a  line limit is reached
> >> (set at
> >> 3000 lines), the handler would delete the FIRST line in the field.
> >
> > Another suggestion: if you're really dealing with a lot of rapidly
> > changing data, don't even put all of it in fields.  Just put the part
> > you need displayed in there and keep the rest in a variable.  Use a
> > scrollbar object to allow the user to select what part is shown.
> Emphatic agreement. Variables are much faster than fields.
> However, if your limit is 3000 lines then why ask for the Number of
> Lines in the field/variable? When the process starts, count up from one
> (increment a variable) until you get to 3000 and thereafter always
> discard the first line when you add another.
> >
We don't ask for the number of   lines in the field.  we actually count sdo
we know when to delete then

> >>  I
> >> discovered that in  I was using a replace for the mainframe cr
> >> referencing
> >> the entire buffer rather than the last character of each line. Causing
> >> the
> >> replace to reference the last character of each line rather than the
> >> entire
> >> buffer made some difference but not enough.
> >
> > I don't follow this part, but the "replace" command is very fast and
> > shouldn't be a bottleneck unless you're doing it unecessarily (e.g.,
> > do it on a section *before* appending it, rather than appending and
> > then doing the replace on the whole buffer again).
> Eh? I don't follow you here Scott. Surely Replace on each line as it
> arrives would be faster than appending the line to the variable and then
> doing a Replace which you **know** needs to work on only the second-last
> character in the entire 3000 lines. Of course, it is not clear to me why
> the cr is being replaced at all on that platform.
> >

We receive buffers which contain lines or partial lines.  Partial lines are
snipped off and saved as buffer fragments which are suppended to the next
buffer.  Replace is done only for the last character in each line.

The buffer content may be selectively echoed to n connected clients where N
would usually be less than 20.


> snip
> >> Question 3.  Is there some way to cause Rev to execute one handler at a
> >> higher priority than other handlers?
> >
> > No.
> One way or another, if you are going to use one CPU to handle everything
> then that is what the CPU has to do and straight through processing will
> be more efficient than fiddling with priorities. Priorities = assumed
> willingness to lose data/function in the lower priority tasks.
> >
> >> Question 4. Does the Number of lines function actually examine the
> >> content
> >> of the object to make the determination or is the value an attribute
> >> of the
> >> object?
> >
> > It's calculated, and so is not something you want to do a lot of.
> ...and you don't need to in this case. See my earlier comment.
> >
> >>
> snip
>
> regards
> David
>
>
> ------ End of Forwarded Message
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution