-- Heather Williams <[EMAIL PROTECTED]> <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 <[EMAIL PROTECTED]> Date: Sat, 9 Feb 2002 16:02:36 +1100 To: [EMAIL PROTECTED] Subject: Re: Revolution and Task (handler) Overlap Resent-From: David Vaughan <[EMAIL PROTECTED]> Resent-To: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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. >> 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. > >> 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. > 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 [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
