Sent from phone, thus brief. Am 25.10.2013 13:13 schrieb "Rainer Gerhards" <[email protected]>: > > On Fri, Oct 25, 2013 at 1:07 PM, David Lang <[email protected]> wrote: >> >> On Fri, 25 Oct 2013, Rainer Gerhards wrote: >> >>> On Fri, Oct 25, 2013 at 11:55 AM, Pavel Levshin <[email protected] >wrote: >>> >>>> 25.10.2013 13:30, Rainer Gerhards: >>>> >>>> >>>>> And, indeed, it will work as expected. Each message will get it's number >>>>> in shadow copy. >>>>> >>>>> But what if a user tries this (to retain previous value, for example): >>>>> >>>>> set $.local = $/var; >>>>> set $/var = $/var + 1; >>>>> >>>>> $/var will be shadowed at first statement, but modified AND propagated at >>>>> second one. >>>>> >>>>> This would violate restriction 1 ("no update after initial access") and >>>>> lead to a runtime error. But I guess you looked at the pseudocode, and >>>>> indeed it was missing the reset of the modifiable attribute (which >>>>> enforces >>>>> that restriction). >>>>> >>>>> Do you agree? >>>>> >>>>> >>>> Yes, it will work. >>>> >>>> Overall, it is almost the same restriction as I have proposed earlier. >>>> Difference is in that there is a shadow, which lets user read the same >>>> value many times from cached copy. But he still can access the state >>>> variable only once. >>>> >>> >>> Yes, of course. But he doesn't need to care about this (actually not even >>> know), as it is hidden by the system. And we can issue a warning message >>> easily if the user tries to do that. We wanted to prevent user errors and >>> make it look more "natural". With read-only variables, we also have a good >>> vehicle for keeping config-values (the use case was on the list yesterday). >>> >>> Also, we may remove some of the restrictions as the engine evolves -- with >>> the ultimate goal of morphing state vars back into global vars, now with >>> the expected semantics assigned to them. All of this without the need to >>> change anything in existing configs. I would also think that what is >>> currently written for global vars will just continue to work fine with >>> state vars. The same hopefully holds for the articles David has written and >>> other docs/snippets. So I think there is great value in trying to preserve >>> the syntax. >> >> >> the one functionality that is really problematic with the old global variables is doing math on them (counter functionality) >> > > any set operation is counter-intutive. > > If you have e.g. > > set $/prevtag = $tag > if $tag == "this" and $prevtag == "that" then ... >
Of course you need to swap the lines ;) > you get far from the expected result. > > Rainer >> >> I am thinking that if we remove that capability (or at least, strongly discourage it, something like "rsyslog makes very heavy use of out-of-order execution, and as a result, doing math with global variables will lead to very unintuitive results"), the rest of things can stay as-is. My article didn't describe doing math on them. We can log a warning if someone does math on a global variable (rate limited, or only the first time per execution/thread) >> >> yes, it will change some of the other documentation, but only the examples in them >> >> David Lang >> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. > > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
