Re: [Logs-devel] fixing (removing) dynamically bound variables

[Jim Prewett]

> On 1/7/07, Jim Prewett <address@hidden> wrote:
> > 
> > > How would we pass the ENVIRONMENT to the actions?
> > 
> > I was thinking of modifying run-actions in rule.lisp in partiucular to
> > remove the IN-GIVEN-ENVIRONMENT references and instead funcall the action
> > functions with an additional argument: This is the simplest thing I can
> > think of to do.
> 
> I'm not sure this is exactly possible.  In cases where the action is
> specified as a function (as in your example to Aashish), we would have
> to do something like
> 
> ((lambda (message environment)
>   (declare (ignorable environment))
>   (funcall action message))
> message
> environment)

I'm not quite sure what you mean.

I do believe I was originally underestimating the amount of work required 
:)  I think for what I'm proposing, you would have to *CHANGE THE API* for 
all rule and ruleset match functions, rule action functions, rule and 
ruleset delete rule functions so that they all accepted the environment as 
an argument.  All(?) of the functions that interact with those match, etc. 
functions would also have to be changed.

> which, I think, is inefficienct.  I think we can still use
> IN-GIVEN-ENVIRONMENT and i've given an example below.

I think that given an API change, we won't need to jump through the hoops 
you specified.  I think our confusion here is due to my original 
oversimplification :)

> > I've done a little playing with this and I think the modifications should
> > be pretty small.

LOL!  Let me restate that as: the modifications shouldn't touch /every/ 
line of code and will *only* require a serious API change :P :)

> Here is one way I can think of using IN-GIVEN-ENVIRONMENT but the
> bound variables are not available in sub-actions.
> 
> (defmacro in-given-environment (env action &rest args)
>  (let ((body-result (gensym "BODY-RESULT"))
>        (environment (gensym "ENVIRONMENT")))
>    `(let ((,environment ,env))          ; <-- not GENSYM'd
>      (flet ((getvar (var) (cadr (assoc var ,environment))))
>        (let ((,body-result ,action))
>          (if (functionp ,body-result)
>              (funcall ,body-result ,@args)
>              ,body-result))))))
> 
> CL-USER> (in-given-environment '((a "one") (b 'ii))
>           #'(lambda (arg)(defmacro in-given-environment (env action &rest 
> args)
>               (list (getvar 'a) (getvar 'b) arg))
>           3)
> ("one" 'II 3)
> 
> So A and B of this ENVIRONMENT will not be available below.  But as we
> discussed earlier, that is possible only with dynamic variables.

> 
> Of course, the above macro won't work in real application code.  It
> needs a slight modification.  We cannot write (flet ((GETVAR (var)...)
> It would have to be (flet ((,(intern "GETVAR") (var) ...) so that
> GETVAR is available in the current package.
> 
> Or we could have ORG.PREWETT.LOGS export GETVAR, I think.
> 
> What do you think, Jim?

I'm not sure there is actually a whole lot of point :)

Imagine if we had an exported function, getvar, that possibly looked like 
this:

(defun getvar (variable-name environment)
  (cadr 
   (assoc variable-name environment)))

Also imagine that the API has been changed as per above.  If we want a 
rule that matches ssh login messages and, in response, prints a 
message indicating the name of the user and the host the login 
occurred on (a horribly contrived example :), we could write a rule like 
this (for clarity, without using RDL macros):

(make-instance
 'rule
 :match
 (lambda (message environment)
   (multiple-value-bind
         (matches sub-matches)
       (scan-to-strings
        "(\\S+) sshd\\[\\d+\\] session opened for user (\\S+)"
        (message message))
     (when matches
       (values matches
               `((host ,(aref sub-matches 0))
                 (user ,(aref sub-matches 1)))))))
 :actions
 (list
  (lambda (message environment)
    (format t "Saw user: ~A login on host: ~A~%"
            (getvar 'user environment)
            (getvar 'host environment)))))

Then, not only can we call sub-actions (which, could, in my dreams, come 
from a vendor who provides only pre-compiled Lisp files) as long as we 
remember to propogate the environment to them, we can also, as a user (and 
without mucking with any of the internals of LoGS) modify that environment 
for the purposes of calling these sub-actions (which, frankly, I'm not 
sure how it could ever be used :) .

I think the macro you're proposing, while possibly quite useful when 
writing our action functions, doesn't really solve the problem.  the 
current codebase expects in-given-environment to work with not only code 
snippets, but references to actual functions like #'foo; I think the API 
change is the only way to sensibly remove the dynamic variables and still 
keep the same functionality.

am I making any sense? :)

Jim