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 ... 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://lists.adiscon.net/mailman/listinfo/rsyslog> > http://www.rsyslog.com/**professional-services/<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.
