Zugg Software :: View topic

Novice Joined: 25 May 2003 Posts: 37

Zmud seems to skip lines if a trigger is computationally expensive or just slow. Right?

Example:
I get a block of text with up to 10 Lines. This trigger colors the entire block and prints all Lines twice:
#TRIGGER {(*)} {#CO red;#SAY %1;} ""

This is the same trigger, but it has a FORALL loop, which needs a lot of computing time.
This Trigger processes JUST THE FIRST LINE of the Text-Block and skips the rest.
#TRIGGER {(*)} {#CO red;#SAY %1;#FORALL %replace( %1, " ", "|") {}} ""

The same Result if you replace the "FORALL-Loop" with "#WAIT 1"
#TRIGGER {(*)} {#CO red;#SAY %1;#WAIT 1} ""

The Question is how to force zmud to process every line .. (e.g. line buffering)??

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

You can't. Anytime you clog up a system so much that its inflow exceeds its outflow it will eventually overflow. This is just as true of computer programs as it is of sinks. The fix is also the same -- remove the clog.

LightBulb
Advanced Member

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Enclose whatever you want to be executed before any other lines are processed in a #PRIORITY command.

Kjata

Newbie Joined: 27 May 2003 Posts: 4 Location: USA

There are actually multiple solutions. Getting a bigger sink is one. So how does one increase the buffer size? It doesn't sound like a cyclical buffer overflowing. It sounds more like there is no buffer (or only a one line one).

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

mrdark's trigger is designed to run on EVERY line. His post clearly states that he receives additional lines faster than his trigger can process them. This being the case, he must eventually exceed the capacity of ANY buffer. The only realistic solutions are to reduce the amount of processing per line (simpler script) or to reduce the number of lines being processed (more specific pattern).

Personally I can't see any value in his trigger and suspect it's something he made up to exaggerate the situation rather than something he actually uses.

1. If every line is to be colored red, just change the colors used in Preferences. No trigger is needed.

2. #TR will trigger on the output of #SAY, so all these triggers create trigger loops. His claim that the first one works is highly doubtful, I've been unable to get it to work in actual tests (but it's nice for testing the Disable Triggers option Zugg added to the trigger loop detector).

3. Running a #FORALL loop to take no action on every character in the line is clearly just a waste of time.

A larger buffer (or sink) just delays the problem but doesn't solve it. As I said above, "Anytime you clog up a system so much that its inflow exceeds its outflow it will eventually overflow." (emphasis added)

LightBulb
Advanced Member

Novice Joined: 25 May 2003 Posts: 37

thank you LightBulb!
the triggers above are just test samples. I wouldn't neither color every line by triggers nor use a "(*)" to match lines. It's just a test to explain the problem.
And all the triggers above have a "notrig" option, of course. (to avoid trigger loops)

I have found a solutions to process many lines which come faster then I can process.
This solves the problem:

Just CAPTURE all lines to a String-List buffer (#ADDI is much faster than parsing on the fly)! .. and process them later .. e.g. on prompt.
works fine now .. thanx @ all

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Ah, didn't think of using "notrig". I'm glad you did find a solution.

LightBulb
Advanced Member