I have added a modification reactor to my table. The reactor has a callout function in it's data. callout is a function am:trench-updated
(vlr-pers
(vlr-object-reactor
(list table)
(list (cons :am:dictionary dictionary)
(cons :am:modified callout))
(list (cons :vlr-modified 'am:table-modified))))
In the reactor I extract these callouts from the list:
(defun am:object-get (object field)
(cdr (assoc field object)))
(defun am:table-modified (reactor-object)
(setq reactor-data (vlr-data reactor-object)
callout (am:object-get reactor-data :am:modified))
(apply callout (list ...)))
It works fine until I save-load the drawing. After the load, callout contains the correct name, but nil value.
An AutoLISP function will only be defined within the scope of the document namespace and will therefore need to be redefined when the document (drawing file) is reopened. I'm unsure why such function would be undefined following a save operation however.
I would personally suggest that you avoid the use of persistent reactors in favour of rebuilding transient reactors on drawing startup. In my experience, persistent reactors are never truly persistent.
Related
In the HyperSpec entry for HANDLER-BIND, it says that a handler can decline to handle a signal.
However, the linked glossary entry for decline to handle a signal is not very enlightening:
decline v. (of a handler) to return normally without having handled the condition being signaled, permitting the signaling process to continue as if the handler had not been present.
This definition begs and does not answer the question of what constitutes not returning normally?
Is there a full list of actions that constitute "handling" a signal?
I know from hands-on experience that INVOKE-RESTART appears to fit this criterion. But is that the only way for a handler to "handle" a signal, or are there others?
I think to understand the true meaning of “handle”, you should consider how the condition system works under the hood. Kent Pitman's sample implementation, written during the standardization process, is a good place to start (even though it has kludgy stuff like essentially implementing an entire object system, since CLOS was not yet part of the language).
Roughly speaking, the action of handler-bind is to set up a special variable, which we will call *handler-clusters*, so that it holds lists of lists of (type . function) pairs, corresponding to the list of bindings. A possible definition is
(defmacro handler-bind (bindings &body forms)
`(let ((*handler-clusters* (cons (list (mapcar #'(lambda (x) `(cons ',(car x) ,(cadr x)))
bindings))
*handler-clusters*)))
,#forms))
The signal function, then, goes through the clusters; if it finds one for the correct condition type, it calls the associated function. Definition:
(defun signal (datum &rest arguments)
(let ((condition (coerce-to-condition datum arguments :default 'simple-condition))
(*handler-clusters* *handler-clusters*)) ; save current value
(when (typep condition *break-on-signals*)
(with-simple-restart (continue "Continue the signaling process")
(break "Break caused by *BREAK-ON-SIGNALS*")))
(loop for cluster := (pop *handler-clusters*) do
(loop for binding in cluster do
(when (typep condition (car binding))
(funcall (cdr binding) condition)))))
nil)
where coerce-to-condition is a function that deals with “condition designators”. A subtle point is that we can't simply (loop for cluster in *handler-clusters* do …), because if, during the call of a handler, a condition of the same type as that which is being handled is signaled, the handler would be called recursively, which is probably not desirable. Thus the previous value is saved and we destructively pop the cluster off.
Now, remember that Common Lisp allows closures over block names and tagbody tags. That is, after the definitions
(defvar *transfer-control*)
(defun weird (function)
(tagbody
(go :start)
:tag
(print 'transferred)
(return-from weird)
:start
(setf *transfer-control* (lambda () ; captures the tag :tag
(go :tag)))
(funcall function)))
a form like
(weird (lambda () (funcall *transfer-control*)))
is allowed, and will print 'transferred. The control transfer happens, in a sense, outside of the lexical scope of the tagbody; the ability to (go :tag) has “escaped” its enclosing scope. (It would be an error to funcall *transfer-control* after weird has returned, because the dynamic extent of the tagbody has been exited.)
All this is to say that calling an ordinary Common Lisp function can cause a transfer of control, instead of returning a value. Calling *transfer-control* does nothing but unwind the dynamic environment up to the point of the tagbody, and then jumps to :tag. The function doesn't “return” in the usual sense of the term, because the evaluation of the expression in which it is embedded will be abruptly stopped, never to resume. (With weird and *transfer-control*, we've defined a primitive substitute for catch and throw that simply transfers control but doesn't convey a value at the same time. To see definitions of tagbody, block, and catch in terms of each other, see Henry Baker's “Metacircular Semantics for Common Lisp Special Forms”.)
Therefore, when signal calls the handler for a condition, two things can happen:
The handler transfers control, aborting the evaluation of signal and unwinding the stack to the place to which control was transferred.
The handler does not transfer control, but returns a value. In this case, as the definition above shows, signal will continue looking for a handler until reaching the end of *handler-clusters* or until another handler transfers control. This is called “declining”.
(In a way, it can also do neither or both, by, for instance, calling signal on another condition. The specification calls this deferring.)
For example, the hyperspec gives a sample expansion for handler-case. The form
(handler-case form
(type1 (var1) . body1)
(type2 (var2) . body2) ...)
becomes (ignoring problems of variable capture)
(block return-point
(let ((condition nil))
(tagbody
(handler-bind ((type1 #'(lambda (temp)
(setq condition temp)
(go :handler-tag-1)))
(type2 #'(lambda (temp)
(setq condition temp)
(go :handler-tag-2)))
...)
(return-from return-point form))
:handler-tag-1
(return-from return-point (let ((var1 condition)) . body1))
:handler-tag-2
(return-from return-point (let ((var2 condition)) . body2))
...)))
(I've rewritten the hyperspec's code to be more readable, although unhygienic, and I also fixed an error in the original.)
As you can see, the handlers established by handler-case unconditionally transfer control if called. Thus handler-case handlers definitely “handle” conditions.
Restarts are implemented in a very similar way, by restart-bind setting up the dynamic environment and invoke-restart using it to call a function. Because restarts are just functions, they need not transfer control, and so calling invoke-restart is not always an act of “handling”, although it is if the restart was established by restart-case or with-simple-restart—or, of course, if the restart transfers control.
The glossary describes things exactly but tersely: if a handler returns normally, it has declined to handle the condition. In order to handle the condition, it must instead transfer control so that it never returns. In CL this means it must transfer control 'upwards'.
An example might be
(block done
(handler-bind ((error (lambda (c)
(return-from done c))))
(error "exploded")))
Here the handler for conditions of type error is handling the condition, since it never returns normally but rather returns from the done block.
A full description of this is here.
Apologies for any indentation / paren errors: my lisp machine has emitted smoke so I am typing this on a more primitive system.
Common Lisp is lexically scoped, but there is a possibility to create dynamic bindings with (declare (special *var*)). What I need, is a way to create a dynamically scoped structure slot, whose value is visible to all other slots. Here is an example:
(defun start-thread ()
*delay*) ;; We defer the binding of *delay*
This works for a usual lexical environment:
(let ((*delay* 1))
(declare (special *delay*))
(start-thread)) ;; returns 1
This does not work:
(defstruct table
(*delay* 0)
(thread (start-thread)))
(make-table) ;; => Error: *delay* is unbound.
My questions are
How to refer to the slot delay from other slots?
How to make the slot delay dynamically scoped, so that its value becomes visible
for the function (start-thread) ?
The first thing to realise that there's no good way to have a dynamically-scoped slot in an object (unless the implementation has some deep magic to support this): the only approach that will work is to use, essentially, explicit shallow-binding. Something like this macro, for instance (this has no error checking at all: I just typed it in):
(defmacro with-horrible-shallow-bound-slots ((&rest slotds) object &body forms)
(let ((ovar (make-symbol "OBJECT"))
(slot-vars (mapcar (lambda (slotd)
(make-symbol (symbol-name (first slotd))))
slotds)))
`(let ((,ovar ,object))
(let ,(mapcar (lambda (v slotd)
`(,v (,(first slotd) ,ovar)))
slot-vars slotds)
(unwind-protect
(progn
(setf ,#(mapcan (lambda (slotd)
`((,(first slotd) ,ovar) ,(second slotd)))
slotds))
,#forms)
(setf ,#(mapcan (lambda (slotd slot-var)
`((,(first slotd) ,ovar) ,slot-var))
slotds slot-vars)))))))
And now if we have some structure:
(defstruct foo
(x 0))
Then
(with-horrible-shallow-bound-slots ((foo-x 1)) foo
(print (foo-x foo)))
expands to
(let ((#:object foo))
(let ((#:foo-x (foo-x #:object)))
(unwind-protect
(progn (setf (foo-x #:object) 1) (print (foo-x foo)))
(setf (foo-x #:object) #:foo-x))))
where all the gensyms with the same name are in fact the same. And so:
> (let ((foo (make-foo)))
(with-horrible-shallow-bound-slots ((foo-x 1)) foo
(print (foo-x foo)))
(print (foo-x foo))
(values))
1
0
But this is a terrible approach because shallow binding is terrible in the presence of multiple threads: any other thread that wants to look at foo's slots will also see the temporary value. So this is just horrid.
A good approach is then to realise that while you can't safely dynamically-bind a slot in an object, you can dynamically bind a value which that slot indexes by using a secret special variable to hold a stack of bindings. In this approach the values of slots do not change, but the values they index do, and can do so safely in the presence of multiple threads.
A way of doing this this is Tim Bradshaw's fluids toy. The way this works is that you define the value of a slot to be a fluid, and then you can bind that fluid's value, which binding has dynamic scope.
(defstruct foo
(slot (make-fluid)))
(defun outer (v)
(let ((it (make-foo)))
(setf (fluid-value (foo-slot it) t) v) ;set global value
(values (fluid-let (((foo-slot it) (1+ (fluid-value (foo-slot it)))))
(inner it))
(fluid-value (foo-slot it)))))
(defun inner (thing)
(fluid-value (foo-slot thing)))
This often works better with CLOS objects because of the additional flexibility in things like naming and what you expose (you almost never want to be able to assign to a slot whose value is a fluid, for instance: you want to assign the value of the fluid).
The system uses a special variable behind the scenes to implement deep binding for fluids, so will work properly with threads (ie distinct threads can have different bindings for a fluid) assuming the implementation treats special variables sensibly (which I'm sure all multithreaded implementations do).
I don't think that this makes sense. Variables have scope and extent, but values just are, and slots are just parts of values. Additionally, threads do not inherit dynamic bindings.
If you want to have some kind of object that is dynamically changed (so to speak), you need to put it into a dynamic variable as a whole value, and do re-bindings with modified versions (preferably on the basis of some immutability, i. e. persistent datastructures, e. g. with FSet).
I'm doing a bit of guessing about what you need here, but I think using a class and initialize-instance will give you what you want. In the code below, I rewrote your struct as a class, and the object itself is passed to initialize-instance in a call to (make-instance 'table).
(defclass table ()
((delay :initform 5)
(thread)))
(defun start-my-thread (obj)
(print (slot-value obj 'delay)))
(defmethod initialize-instance :after ((obj table) &key)
(start-my-thread obj))
(make-instance 'table)
; above call will print 5
I want to define a function (not a macro) that can set a variable in the scope its called.
I have tried:
(defun var-set (var-str val)
(let ((var-interned
(intern (string-upcase var-str))))
(set var-interned val)
))
(let ((year "1400"))
(var-set "year" 1388)
(labeled identity year))
Which doesn't work because of the scoping rules. Any "hacks" to accomplish this?
In python, I can use
previous_frame = sys._getframe(1)
previous_frame_locals = previous_frame.f_locals
previous_frame_locals['my-var'] = some_value
Any equivalent API for lisp?
You cannot do that because after compilation the variable might not even exist in any meaningful sense.
E.g., try to figure out by looking at the output of (disassemble (lambda (x) (+ x 4))) where you
would write the new values of x.
You have to tell both the caller and the callee (at compile time!) that the variable is special:
(defun set-x (v)
(declare (special x))
(setq x v))
(defun test-set (a)
(let ((x a))
(declare (special x))
(set-x 10)
x))
(test-set 3)
==> 10
See Dynamic and Lexical variables in Common Lisp for further details on lexical vs dynamic bindings.
You can't. This is why it is called lexical scope: you have access to variable bindings if and only if you can see them. The only way to get at such a binding is to create some object for which it is visible and use that. For instance:
(defun foo (x)
(bar (lambda (&optional (v nil vp)
(if vp (setf x vp) x))))
(defun bar (a)
...
(funcall a ...))
Some languages, such as Python have both rather rudimentary implementations of variable bindings and a single implementation (or a mandated implementation) which allow you to essentially poke around inside the system to subvert lexical scoping. Some CL implementations may have rudimentary implementation of variable bindings (probably none do) but Common Lisp the language does not mandate such implementations and nor should it.
As an example of the terrible consequences of mandating that some kind of access to lexical variables must be allowed consider this:
(defun outer (n f)
(if (> n 0)
(outer (g n) f)
(funcall f)))
If f could somehow poke at the lexical bindings of outer this would mean that all those bindings would need to exist at the point f was called: tail-call elimination would thus be impossible. If the language mandated that such bindings should be accessible then the language is mandating that tail-call elimination is not possible. That would be bad.
(It is quite possible that implementations, possibly with some debugging declarations, allow such access in some circumstances. That's very different than the language mandating such a thing.)
What are you trying to achieve?
What about a closure? Write the defun inside the let, and create an accessor and a setter function if needed.
(let ((year "1400"))
(defun current-year ()
year)
(defun set-year (val)
(setf year val)))
and
CL-USER> (current-year)
"1400"
CL-USER> (set-year 1200)
1200
CL-USER> (current-year)
1200
That Python mechanism violates the encapsulation which motivates the existence of lexical scope.
Because a lexical scope is inaccessible by any external means other than invocations of function bodies which are in that scope, a compiler is free to translate a lexical scope into any representation which performs the same semantics. Variables named in the source code of the lexical scope can disappear entirely. For instance, in your example, all references to year can be replaced by copies of the pointer to the "1400" string literal object.
Separately from the encapsulation issue there is also the consideration that a function does not have any access at all to a parent lexical scope, regardless of that scope's representation. It does not exist. Functions do not implicitly pass their lexical scope to children. Your caller may not have a lexical environment at all, and there is no way to know. The essence of the lexical environment is that no aspect of it is passed down to children, other than via the explicit passage of lexical closures.
Python's feature is poorly considered because it makes programs dependent on the representation of scopes. If a compiler like PyPy is to make that code work, it has to constrain its treatment of lexical scopes to mimic the byte code interpreted version of Python.
Firstly, each function has to know who called it, so it has to receive some parameter(s) about that, including a link to the caller's environment. That's going to be a source of inefficiency even in code that doesn't take advantage of it.
The concept of a well-defined "previous frame" means that the compiler cannot merge together frames. Code which expects some variable to be in the third frame up from here will break if those frames are all inlined together due to a nested lexical scope being flattened, or due to function inlining.
As soon as you provide an interface to the parent lexical environment, and applications start using it, you no longer have lexical scoping. You have a form of dynamic scoping with lexical-like visibility rules.
The application logic can implement de facto dynamic scope on top of this API, because you can write a loop which searches for a variable across the chain of lexical scopes. Does my parent have an x variable? If not, does the grandparent, if there is one? You can search the dynamic chain of invocations for the most recent one which binds x, and that is dynamic scope.
There is nothing wrong with dynamic scope, if it is a separate discipline that is not entangled in the implementation of lexical scope.
That said, an API for tracing frames and getting at local variables is is the sort of introspection that is very useful in developing a debugger. Another angle on this is that if you work that API into an application, you're using debugging features in production.
(defvar *lexical-variables* '())
(defun get-var (name)
(let ((var (cdr (assoc name *lexical-variables*))))
(unless var (error "No lexical variable named ~S" name))
var))
(defun deref (var)
(funcall (if (symbolp var)
(or (cdr (assoc var *lexical-variables*))
(error "No lexical variable named ~S" var))
var)))
(defun (setf deref) (new-value var)
(funcall (if (symbolp var)
(or (cdr (assoc var *lexical-variables*))
(error "No lexical variable named ~S" var))
var)
new-value))
(defmacro with-named-lexical-variable ((&rest vars) &body body)
(let ((vvar (gensym))
(vnew-value (gensym))
(vsetp (gensym)))
`(let ((*lexical-variables* (list* ,#(mapcar (lambda (var)
`(cons ',var
(lambda (&optional (,vnew-value nil ,vsetp))
(if ,vsetp
(setf ,var ,vnew-value)
,var))))
vars)
*lexical-variables*)))
,#body)))
(defun var-set (var-str val)
(let ((var-interned (intern (string-upcase var-str))))
(setf (deref var-interned) val)))
(let ((x 1)
(y 2))
(with-named-lexical-variable (x y)
(var-set "x" 3)
(setf (deref 'y) 4)
(mapcar (function deref) '(x y))))
;; -> (3 4)
(let ((year "1400"))
(with-named-lexical-variable (year)
(var-set "year" 1388))
year)
;; --> 1388
In Racket, how do I execute a button's callback function, when the function is in another file?
I have a file GUI.rkt with my GUI code:
#lang racket/gui
(provide (all-defined-out))
(define main (new frame% [label "App"]))
(new button% [parent main] [label "Click"]
[callback (lambda (button event) (begin-capture)])
I have a main file, proj.rkt:
#lang racket
(require "GUI.rkt")
(define (begin-capture)
;do stuff
;...
)
The compiler gives an error saying that begin-capture is an unbound identifier.
I know it is an unbound identifier because I didn't define the variable in the GUI file. The Racket documentation shows how to set the callback function in the object definition, but not outside of the definition. Ideally, I would like to access functions in the other file from my GUI, so that all my GUI code is in the GUI.rkt file.
If "GUI.rkt" needs identifiers from "proj.rkt" then "proj.rkt" needs to provide them and "GUI.rkt" needs to require "proj.rkt", not the other way around. If the two modules need identifiers from each other then you almost certainly have a design problem.
If you want the GUI part of the program to be something that is required by other parts, then an obvious approach is for it to provide procedures to make things which take arguments which are things like callbacks:
(provide
...
make-main-frame
...)
(define (make-main-frame ... capture-callback ...)
(define main (new frame% [label "App"]))
(new button% [parent main] [label "Click"]
[callback (lambda (button event) (capture-callback))])
...
main)
Note, however that I don't know anything about how people conventionally organize programs with GUIs, let alone how they do it in Racket, since I haven't written that sort of code for a very long time. The basic deal, I think, for any program with modules is:
you want the module structure of programs to not have loops in it – even if it's possible for Racket's module system to have loops, their presence in a program would ring alarm bells for me;
where a 'lower' module in the graph (a module which is being required by some 'higher' module in the graph) may need to use functionality from that higher module it should probably do by providing procedures which take arguments which the higher module can provide, or equivalent functionality to that.
The above two points are my opinion only: I may be wrong about hat the best style is in Racket.
A possible example
Here's one way of implementing a trivial GUI in such a way that the callback can be changed, but the GUI code and the implementation code are isolated.
First of all the gui lives in "gui.rkt" which looks like this:
#lang racket/gui
(provide (contract-out
(selection-window (->* (string?
(listof string?)
(-> string? any))
(#:initial-choice string?)
(object/c)))))
(define (selection-window name choices selection-callback
#:initial-choice (initial-choice (first choices)))
;; make & show a selection window for a number of choices.
;; selection-callback gets called with the choice, a string.
(define frame (new frame% [label name]))
(new choice%
[parent frame]
[label "state"]
[choices choices]
[selection (index-of choices initial-choice)]
[callback (λ (self event)
(selection-callback (send self get-string-selection)))])
(send frame show #t)
frame)
So this provides a single function which constructs the GUI. In real life you'd probably want to provide some additional functionality to manipulate the returned object without users of this module needing to know about it.
The function takes a callback function as an argument, and this is called in a way which might be useful to the implementation, not the GUI (so in particular it's called with the selected string).
"gui.rkt" doesn't provide any way to change the callback. But that's OK: users of the module can do that, for instance like this:
#lang racket
(require "gui.rkt")
(define selection-callback-implementation
(make-parameter (λ (s)
(printf "selected ~A~%" s))))
(selection-window "foo" '("red" "amber" "green")
(λ (s) ((selection-callback-implementation) s))
#:initial-choice "green")
Now the parameter selection-callback-implementation is essentially the callback, and can be adjusted to change what it is. Of course you can do this without parameters if you want, but parameters are quite a nice approach I think (although, perhaps, unrackety).
How can I change or rename visibility states for a dynamic block in AutoCAD using VBA, similar to clicking RENAME in the Visibility State dialog box which appears when issuing the BVSTATE command in the Block Editor?
Thanks so much for your help.
In short, it is not possible to rename Dynamic Block Visibility States directly using the LISP or VBA API, without resorting to invoking standard AutoCAD commands, for example, using the AutoLISP command function, or sendcommand method.
Dynamic Block Parameters contained within a block definition are not exposed to the ActiveX object model and therefore cannot be modified using Visual LISP or VBA.
Such parameters are exposed to Vanilla AutoLISP by examining the DXF data stored within the Extension Dictionary of the BLOCK_RECORD entity, but such data cannot be modified using entmod, nor does it yield any relevant properties following conversion to an equivalent VLA-Object representation.
For what it's worth, you can access the Dynamic Block Parameter DXF data using the following route through the AutoLISP API:
First, obtain the BLOCK entity:
(setq bl (tblobjname "block" "YourBlockName"))
Then obtain the parent BLOCK_RECORD entity:
(setq br (cdr (assoc 330 (entget bl))))
Now obtain the Extension Dictionary from DXF group 360 (additional checks for the presence of "{ACAD_XDICTIONARY" against DXF group 102 should be used in production code):
(setq d1 (cdr (assoc 360 (entget br))))
Now search this dictionary for the ACAD_ENHANCEDBLOCK entry:
(setq d2 (dictsearch d1 "acad_enhancedblock"))
This will yield the DXF data for the ACAD_EVALUATION_GRAPH entity.
You can then iterate over the DXF group 360 within the DXF data to obtain the DXF data for each Dynamic Block Parameter found within the block definition, e.g.:
_$ (foreach dxf d2 (if (= 360 (car dxf)) (print (cdr (assoc 0 (entget (cdr dxf)))))))
"BLOCKPOLARPARAMETER"
"BLOCKPOLARGRIP"
"BLOCKGRIPLOCATIONCOMPONENT"
"BLOCKGRIPLOCATIONCOMPONENT"
"BLOCKPOLARSTRETCHACTION"
"BLOCKFLIPPARAMETER"
"BLOCKFLIPGRIP"
"BLOCKGRIPLOCATIONCOMPONENT"
"BLOCKGRIPLOCATIONCOMPONENT"
"BLOCKGRIPLOCATIONCOMPONENT"
"BLOCKFLIPACTION"
"BLOCKVISIBILITYPARAMETER"
"BLOCKVISIBILITYGRIP"
"BLOCKGRIPLOCATIONCOMPONENT"
"BLOCKGRIPLOCATIONCOMPONENT"