Viewer for $ADDLST logs?

[Arne]

Hi there
but you got to admit it is kind of cool anyway. See how we love this! It might even inspire you to make a function that does this for us, who knows? So, while we get ourselves into lots of trouble, you might get an idea about how to save us from it LOL.

Best wishes
Arne
Imici username= Arne

[sidki3003]

I will keep an eye on resulting errors or decreasing memory.
If this happens i remove $ADDLST from frequently triggered filters.
I just like stats (even chained another local proxy just for CLF logging)

sidki

 

[Arne]

Me too. I love numbers and figures, graphs and all. I better keep it out of the P-FAQ then, so we keep our troubles to ourselves and not spread them out to everybody else as well

Best wishes
Arne
Imici username= Arne

[TEggHead]

quote:Scott R Lemmon wrote:
Please - ADDLST should not be used as a make-shift log file. It's very likely to cause problems and eat up memory. Remember, it's parsing everything you give it as a matching command.

? isn't this exatly what it's purpose is? to add something to a file? so it would be logical to expect that the matching has already been done, and only variables present that need expanding?

Might be strictly W98/ME related problems, am running on 2K and have not yet noticed any memory drain...

FWIW, I've been using $ADDLST as logger a while already before I posted the tip and never have had a problem AAR of using it (yet . In fact, I got about 12 logs defined between 27 filters using them, all using the same format

$ADDLST(<ListName>,[$DTM(d T)] | <what matched> | u | <optional data> )

and almost all are active simultaneously (meaning switched on, not triggering)

as a side note, given the above formatline added to ACR, ACR produces a file of over 100Kb in less than a day...it takes out a LOT, you'd be surpised...

JarC




Edited by - TEggHead on 18 Jun 2002  04:24:20

Edited by - TEggHead on 18 Jun 2002  04:30:17

[Scott Lemmon]

quote:
? isn't this exatly what it's purpose is? to add something to a file? so it would be logical to expect that the matching has already been done, and only variables present that need expanding?

No more than the purpose of a chainsaw is to be used as a butterknife - they both slice don't they?  Blocklists are designed to match things.  Every line is a matching expression - you know that.  Every line is also parsed and stored in memory - not *just* placed in a file. Otherwise how do you expect the blocklists to work as blocklists?  

quote:
Might be strictly W98/ME related problems, am running on 2K and have not yet noticed any memory drain...

Every line you add to a blockfile uses up some memory. It's strictly a fact of life. Using it as a log file will drain memory as the log grows.  I'm not saying this to just rain on your parade. In fact, I'm really tired of having to always argue with people about stuff like this.  Popularizing the incorrect use of commands just causes trouble for everyone later on.

quote:
FWIW, I've been using $ADDLST as logger a while already before I posted the tip and never have had a problem AAR of using it (yet . In fact, I got about 12 logs defined between 27 filters using them, all using the same format

Yes, and by giving this kind of bad advice you're just hurting others. As your "logs" grow in size they *will* consume more and more memory.  Also if something like an unmatched paren is added to the log it will generate an error. On your system it may take awhile before it causes trouble, but others may not be so lucky.  At rail-road crossings, people play chicken with oncoming freight trains all the time and most make it across the tracks in time. That doesn't make it a smart thing to do. Nor would it be a responsible thing to encourage others do the same.

(P.S. I just remembered the "error message in match" thread you started at Yahoo.  Guess what's probably causing this error? The error only happens when adding something to a list, so it seems your use of this hasn't been as trouble free as you're saying).

quote:
as a side note, given the above formatline added to ACR, ACR produces a file of over 100Kb in less than a day...it takes out a LOT, you'd be surpised...

You might be surprised how much less CPU time it might use with a little code clean-up too.  

-Scott-



Edited by - Scott Lemmon on 18 Jun 2002  14:17:12

[sidki3003]

I don't want to promote this prox log thing any further,
but i can't resist to mention a log viewer i stumbled over.
It displays the changes in any number of logs (local or remote) in realtime
http://66.31.61.166/flogviewer/
Only downside is it tries to connect home at startup (getting a 302 Object moved reply).

sidki


 

[TEggHead]

Scott,

quote:
by giving this kind of bad advice you're just hurting others.

thank you...

quote:
(P.S. I just remembered the "error message in match" thread you started at Yahoo.  Guess what's probably causing this error?

rest assured, this was not the cause...I'm alsmot afraid to say it, but if nothing else, the command also is very helpfull in debugging during use instead of only in the test window...sorry, can't help it for using it to the max of it's potential...

quote:

quote:
as a side note, given the above formatline added to ACR, ACR produces a file of over 100Kb in less than a day...it takes out a LOT, you'd be surpised...

You might be surprised how much less CPU time it might use with a little code clean-up too.  

uhoh...now you have awoken sleepy dogs, please tell...?

JarC



 

[Scott Lemmon]

quote:

quote:
(P.S. I just remembered the "error message in match" thread you started at Yahoo. Guess what's probably causing this error?

rest assured, this was not the cause...I'm alsmot afraid to say it, but if nothing else, the command also is very helpfull in debugging during use instead of only in the test window...sorry, can't help it for using it to the max of it's potential...

Rest assured it is. The error dialog with that message exists only one place in the program - the list item add function. (edit: more accurately it's in the list load function, so it'll appear the next time the log is reloaded).  It's your debugging that's causing the bugs. Try inserting an unmatched paren or bracket into the "log" and see what happens...  

quote:
uhoh...now you have awoken sleepy dogs, please tell...?

Well for one thing stuff like...

   (?++|)1

Consider...

    ?++ = *  (just much slower)

   (*|) = *  (since * already matches "nothing" too)

   (*)1 = 1

    so "(?++|)1" = "1" via a the scenic route






Edited by - Scott Lemmon on 25 Jun 2002  02:28:50

Edited by - Scott Lemmon on 25 Jun 2002  02:37:33

[Scott Lemmon]

BTW: Just to let everyone know - the next version of Proxomitron will include a setting to allow blockfiles to be safely used as logs (by adding a "LOGFILE" keyword at the top).  So just be a little patient.





 

[sidki3003]

Wow!

 

[TEggHead]

quote:
Try inserting an unmatched paren or bracket into the "log" and see what happens...  

Ok, so the command is the one reporting the error, but that could only occur because that what is put in the list is the result of an error in the matchexpression...since the variable added is filled by the match...I readily accept the message was produced by ADDLST, but the error itself was not...it merely made it visible...

quote:
    ?++ = *  (just much slower)

I did not realize you were talking about these constructs...(btw. if they exisited in previous incarnations of ACR, then they do nolonger now, apart from ?++ in some places)

but you also do know why this construct was used and not just a plain asterisk? it is simply the result of having encountered too many situations where * and a larger bytelimit caused a filter matching <TAG*</TAG> to extend the match over the ending tag to the next ocurance of </TAG>, ?++ stops at the first occurance, * does not if the bytelimit is large enough...

As I recall, I encountered such situations myself sometimes...using ?++ in these cases made sure it did not overshoot even if there were more possible endtag matches fitted in the buffer...

the other ones I have however not encountered in the latest incarnation of ACR.

quote:
   (*)1 = 1

I must admit that I have been forced to use this exact form a couple of times myself because otherwise the 1 would take up what was before the parenthesis.

suppose the following  $AVQ( ("|') 1 ("|'))

in this case either (1) or (*)1 is the only way that any possible text between the quotes ends up in 1 instead of the quote itself...

quote:
    so "(?++|)1" = "1" via a the scenic route

so there's purpose to the above afteral, the parenthesis serve to prevent the variable receiving that which is matched in front of the parenthesis...

JarC

 

[Scott Lemmon]

quote:
Ok, so the command is the one reporting the error, but that could only occur because that what is put in the list is the result of an error in the matchexpression...

No. You're not putting "the result of an error" into a list (I don't even know what that means).  You're just placing an invalid expression into a list.  Lists contain matching expressions not plain text - if you stick something in there that's not parsable you'll get the error. That's all there is to it.

quote:
I did not realize you were talking about these constructs...(btw. if they exisited in previous incarnations of ACR, then they do nolonger now, apart from ?++ in some places)

but you also do know why this construct was used and not just a plain asterisk? it is simply the result of having encountered too many situations where * and a larger bytelimit caused a filter matching <TAG*</TAG> to extend the match over the ending tag to the next ocurance of </TAG>, ?++ stops at the first occurance, * does not if the bytelimit is large enough...

No they both work *exactly* the same in the case you describe.  Both will accept the first match they find as long as what follows in the match is also true. if not they'll both keep looking for other matches. If anything ?++ is the one more likely to be flakey.

quote:
As I recall, I encountered such situations myself sometimes...using ?++ in these cases made sure it did not overshoot even if there were more possible endtag matches fitted in the buffer...

Can you provide any evidence of this (like a simple, to the point example)?  My guess is it was something else in the expression causing that.

quote:

quote:
   (*)1 = 1

I must admit that I have been forced to use this exact form a couple of times myself because otherwise the 1 would take up what was before the parenthesis.

suppose the following  $AVQ( ("|') 1 ("|'))

in this case either (1) or (*)1 is the only way that any possible text between the quotes ends up in 1 instead of the quote itself...

Well in many cases you can just place a space between the parens and the 1, but  even doing (foo)11 would still be faster than (foo)(*)1 . Also ("|') is another example of an unneeded check.  A single " will always match both (")  and (') - and before you say it, yes ALWAYS, it's not affected by smart quotes or anything else.

quote:
so there's purpose to the above afteral, the parenthesis serve to prevent the variable receiving that which is matched in front of the parenthesis...

There's no purpose - except maybe to warm up your CPU on a cold day. Many of your statements about the way things work simply aren't true, or if they are you need to provide an actual isolated example (since it's probably a bug).