I currently have a function being checked every so often by an event block. However, I keep receiving the error 'the method function(Patient) in the type Main is not applicable for the arguments ()' when I try to run the simulation.
If your method requires an argument myPatient of type Patient, you must provide that if you call the method.
So you cannot call function(). You MUST call function(somePatient) where somePatient is an agent of type Patient. It is your responsibility to provide that.
If you call the function from a flow-chart block and it should be used for some Patient flowing through the block, you may use function(agent), but only if this key-word agent is available and if the agent flowing through is of type Patient.
Check the fundamentals of functions in the help, this is crucial in getting functions to work for you :)
Related
I think the correct description for what I'm trying to do is be able to pass an expression or function/handler into another handler as a parameter/argument. Some code to be evaluated inside the receiving handler. Similar to Javascript callbacks, I think.
For example, something like this:
on waitFor(theConditionExpression)
timeout_start(5) -- start a 5 second timer
repeat until (theConditionExpression or timeout_isExpired())
delay 0.1
end repeat
return theConditionExpression
end waitFor
theConditionExpression should be some expression or function that evaluates to a boolean result.
not really relevant to the question, but just FYI, timeout_start(…) and timeout_isExpired() are two simple handlers I've written that do exactly what they say. (…start() doesn't return anything, …isExpired() returns a boolean).
Of course, typically if I pass in some boolean expression, it will evaluate that expression once, at the time I pass it in. But I want it to evaluate it every time it's referenced in the code inside the handler.
Some languages (not sure about AS) have some kind of eval() function that you can pass it some code as a string and it will execute that string as code. Theoretically that could solve this, but: (a) I don't know if AS has anything like that, but even if it does, (b) it's not desired for various reasons (performance, injection risks, etc.)
So I'm thinking something more like eg. JavaScript's ability to pass in a function (named or anonymous) as function parameter/argument that can be re-evaluated every iteration in a loop, etc. (eg. like the compareFn argument in JS's Array.sort(compareFn)).
Can AS do anything like this, and if so how?
Thanks!
I'm going to suggest (pro forma) that an AppleScript application with an on idle handler is generally a better solution for wait conditions than a repeat/delay loop. It's more efficient for the system, and doesn't freeze up the script. But that would involve reconceptualizing your script, and I'm not certain it would work in this case, given the way you formed the problem.
There's an old but good site called AppleScript Power Handlers that shows a bunch of nifty-neato tricks for sophisticated use of AppleScript handlers: passing handlers as values or parameters; creating Script Objects within handlers; making closures and constructors. I'm pretty sure the answer to your request is in there. aLikely you'll want to set up a bunch of handlers that serve as condition expressions, then pass them as parameters to the evaluating handler. Or maybe you'll want to set up a script object containing the condition handlers and call it as needed?
At any rate, see what you can do with it, and ask more specific questions if you run into problems.
I'm trying to figure out how to set a callback for for every instance of a specific MATLAB object type and not a single instance. In my case the object type is either a SimuLink Block, Subsystem, or ModelReference.
After having read
http://se.mathworks.com/help/matlab/creating_plots/callback-definition.html
I tried
function openCallback(src, evt)
disp('here');
end
set(groot, 'defaultBlockOpenFcn', #openCallback);
but it fails as
Error using matlab.ui.Root/set
blockopenfcn is an invalid class name
Is this possible, somehow?
Simulink block callbacks are set using set_param function on a block handle. You would need to set it for a single instance of the block. I do not think it is possible to set it for every instance of a block. If you have a model you can find all the blocks of a type and set their callbacks in a loop.
You can see help for block callbacks at http://www.mathworks.com/help/simulink/ug/block-callbacks.html. You would call set_param as
set_param(gcb, 'OpenFcn', 'disp(''open fcn'')')
where gcb is a function that returns currently selected block in a model.
After browsing a bit through the UVM source code, I noticed that singletons for each phase exist. For the run phase this can be accessed by calling uvm_run_phase::get().
I tried calling uvm_run_phase::get() from both the run_phase and the end_of_elaboration phase and as expected both calls returned a handle to the same object. I am a bit puzzled as the object returned by this method is not the same object that is passed to the run_phase(...) task as it's phase argument.
I've created an example on EDA Playground: http://www.edaplayground.com/x/2PL
Does anyone know exactly what the phase argument getting passed to phase methods is and why it's not the singleton?
After asking the question on the UVM forum, I've found out that there are multiple instances of uvm_phase for each phase that get created, one being used for scheduling and the other being used as the actual implementation.
Calling uvm_run_phase::get() will return the implementation node for the run phase, whereas the argument being past to run_phase(...) is the scheduling node. To get the scheduling node from any other phase, one can use phase.find_by_name("run",0).
Here is the link to the original thread in the UVM forum: http://forums.accellera.org/topic/1769-uvm-phase-singletons/
I have been wondering for a couple of days if NSInvocation should need the NSMethodSignature.
Lets say we want to write our own NSInvocation, my requirements would be as so:
I need a selector SEL
The target object to call the selector on
The argument array
Then i would get the IMP out from the target and the SEL, and pass the argument as parameters.
So, my question is, why do we need an NSMethodSignature to construct and use an NSInvocation?
Note: I do know that by having only a SEL and a target, we dont have the arguments and return type for this method, but why would we care about the types of the args and returns?
Each type in C has a different size. (Even the same type can have different sizes on different systems, but we'll ignore that for now.) int can have 32 or 64 bits, depending on the system. double takes 64 bits. char represents 8 bits (but might be passed as a regular int depending on the system's passing convention). And finally and most importantly, struct types have various sizes, depending on how many elements are in it and each of their sizes; there is no bound to how big it can be. So it is impossible to pass arguments the same way regardless of type. Therefore, how the calling function arranges the arguments, and how the called function interprets its arguments, must be dependent on the function's signature. (You cannot have a type-agnostic "argument array"; what would be the size of the array elements?) When normal function calls are compiled, the compiler knows the signature at compile time, and can arrange it correctly according to calling convention. But NSInvocation is for managing an invocation at runtime. Therefore, it needs a representation of the method signature to work.
There are several things that the NSInvocation can do. Each of those things requires knowledge of the number and types (at least the sizes of the types) of the parameters:
When a message is sent to an object that does not have a method for it, the runtime constructs an NSInvocation object and passes it to -forwardInvocation:. The NSInvocation object contains a copy of all the arguments that are passed, since it can be stored and invoked later. Therefore, the runtime needs to know, at the very least, how big the parameters in total are, in order to copy the right amount of data from registers and/or stack (depending on how arguments are arranged in the calling convention) into the NSInvocation object.
When you have an NSInvocation object, you can query for the value of the i'th argument, using -getArgument:atIndex:. You can also set/change the value for the i'th argument, using -setArgument:atIndex:. This requires it to know 1) Where in its data buffer the i'th parameter starts; this requires knowing how big the previous parameters are, and 2) how big the i'th parameter is, so that it can copy the right amount of data (if it copies too little, it will have a corrupt value; if it copies too much, say, when you do getArgument, it can overwrite the buffer you gave it; or when you do setArgument, overwrite other arguments).
You can have it do -retainArguments, which causes it to retain all arguments of object pointer type. This requires it to distinguish between object pointer types and other types, so the type information must include not only the size.
You can invoke the NSInvocation, which causes it to construct and execute the call to the method. This requires it to know, at the very least, how much data to copy from its buffer into the registers/stack to place all the data where the function will expect it. This requires knowing at least the combined size of all parameters, and probably also needs to know the sizes of individual parameters, so that the divide between parameters on registers and parameters on stack can be figured out correctly.
You can get the return value of the call using -getReturnValue:; this has similar issues to the getting of arguments above.
A thing not mentioned above is that the return type may also have a great effect on the calling mechanism. On x86 and ARM, the common architectures for Objective-C, when the return type is a struct type, the calling convention is very different -- effectively an additional (first) parameter is added before all the regular parameters, which is a pointer to the space that the struct result should be written. This is instead of the regular calling convention where the result is returned in a register. (In PowerPC I believe that double return type is also treated specially.) So knowing the return type is essentially for constructing and invoking the NSInvocation.
NSMethodSignature is required for the message sending and forwarding mechanism to work properly for invocations. NSMethodSignature and NSInvocation were built as a wrapper around __builtin_call(), which is both architecture dependent, and extremely conservative about the stack space a given function requires. Hence, when invocations are invoked, __builtin_call() gets all the information it needs from the method signature, and can fail gracefully by throwing the call out to the forwarding mechanism knowing that it, too, receives the proper information about how the stack should look for re-invocation.
That being said, you cannot make a primitive NSInvocation without a method signature without modifying the C language to support converting arrays to VARARGS seeing as objc_msgSend() and its cousins won't allow it. Even if you could get around that, you'd need to calculate the size of the arguments and the return type (not too hard, but if you're wrong, you're wrong big time), and manage a proper call to __builtin_call(), which would require an intimate knowledge of the message sending architecture or an ffi (which probably drops down to __builtin_call() anyhow).
Is it a function?
Is it a function being called from the source?
Or, is it a function being returned from the destination?
Or, is it just executing a function at the destination?
Or, is it a value returned from a function passed to the destination?
A callback is the building block of asynchronous processing.
Think of it this way: when you call someone and they don't answer, you leave a message and your phone number. Later on, the person calls you back based on the phone number you left.
A callback works in a similar manner.
You ask an API for a long running operation and you provide a method from within your code to be called with the result of the operation. The API does its work and when the result is ready, it calls your callback method.
From the great Wikipedia:
In computer programming, a callback is
executable code that is passed as an
argument to other code. It allows a
lower-level software layer to call a
subroutine (or function) defined in a
higher-level layer.
Said another way, when you pass a callback to your method, it's as if you are providing additional instructions (e.g., what you should do next). An attempt at making a simple human example follows:
Paint this wall this shade of green (where "paint" is analagous to the method called, while "wall" and "green" are similar to arguments).
When you have finished painting, call me at this number to let me know that you're done and I'll tell you what to do next.
In terms of practical applications, one place where you will sometimes see callbacks is in situations with asynchronous message passing. You might want to register a particular message as an item of interest for class B.
However, without something like a callback, there's no obvious way for class A to know that class B has received the message. With a callback, you can tell class B, here's the message that I want you to listen for and this is the method in class A that I want you to call when you receive it.
Here is a Java example of a callback from a related question.