How can I enable Velocity engine to honor #macro signatures so that if I try calling a macro in templates Example:
#myTestMacro($arg1 $arg2)
that has a different signature when defined Example:
#macro(myTestMacro $arg)
Velocity will be smart enough to throw an error, so I can catch invalid number of arguments in the example above?
In the configuration, set velocimacro.arguments.strict=true.
Related
I am trying to inject with a function objects from a population into a source block.
In the function I used this inject() function:
for (mp_lkw mp : mplkws)
{
if (dateToTime(mp.ankunft) <= time()) {
remove_mplkws(mp);
source1.inject(mp);
}
}
Now my source should accept that injection, but an error occurs, that it is only applicable for Integers
Unresolved compilation problem:
The method inject(int) in the type Source<mp_lkw> is not applicable for the arguments (mp_lkw)
I wonder why it doesnt accept my agent type even though the settings in source for "New agent:" and "Agent type:" are set to my agent "mp_lkw"
This is not how the inect() method works. It only lets you specify the number of agents that the Source block creates when you call it. But the details of the agents themselves are set by the Source block.
In your case (where an agent already exists and just needs to start a new flow chart), you replace the Source block with an "Enter" block.
In the code, you call myEnterBlock.take(mp);
A function receives a figure or axis object object as parameter.
I want to test this as shown in the FIXME line.
Which test should be used here in order to allow all valid objects for exportgraphics?
% myexportgraphics.m
function myexportgraphics(f)
arguments
f (1,1) {}; % FIXME add a test here
end
exportgraphics(f,...);
end
This full list of validation functions is documented here:
https://uk.mathworks.com/help/matlab/matlab_prog/argument-validation-functions.html
The only relevant one for checking the input type (other than ones for specific types like "double") is mustBeUnderlyingType
You can check which types are valid using underlyingType on example objects you want to accept.
underlyingType( figure() ); % 'matlab.ui.Figure'
underlyingType( axes() ); % 'matlab.graphics.axis.Axes'
So this would check for figures
function myexportgraphics(f)
arguments
f (1,1) {mustBeUnderlyingType(f,'matlab.ui.Figure')};
end
end
However, that doesn't allow multiple variable types, so per the docs you probably want to make your own validation function
function myexportgraphics(f)
arguments
f (1,1) {mustBeExportGraphicsType(f)};
end
end
function mustBeExportGraphicsType(g)
if ~ismember( class(g), {'matlab.ui.Figure','matlab.graphics.axis.Axes'} )
eidType = 'mustBeExportGraphicsType:notExportGraphicsType';
msgType = 'Input must be a figure or axes object';
throwAsCaller(MException(eidType,msgType));
end
end
These are the requirements for a custom validation function, emphasis mine:
Functions used for validation have these design elements:
Validation functions do not return outputs or modify program state. The only purpose is to check the validity of the input value.
Validation functions must accept the value being validated as an input argument. If the function accepts more than one input argument, the first input is the value to be validated.
Validation functions rely only on the inputs. No other values are available to the function.
Validation functions throw an error if the validation fails. Using throwAsCaller to throw exceptions avoids showing the validation function itself in the displayed error message.
Creating your own validation function is useful when you want to provide specific validation that is not available using the MATLAB validation functions. You can create a validation function as a local function within the function file or place it on the MATLAB path.
As an aside, you could use ishghandle within the custom validation function which returns true for figure and axes inputs. If you didn't use the arguments validation syntax, you could instead use ishghandle with the slightly older inputParser approach to input validation, or a simple assert near the start of your function, but that's probably beyond the scope of this question.
When I create a custom type summary using a Python script, it is possible to access ivars using value.GetChildMemberByName("<child-name>"). However, this does not work for computed properties or functions.
With the frame variable command, the script that generates the summary can evaluate expressions in the current frame (e.g. value.GetFrame().EvaluateExpression(value.GetName() + ".description"))
However, this will not work when using p <some-expression>/expression -- <some-expression> as there is no frame, so the above statement will fail to produce any results.
Is there a way to call functions or evaluate computed properties in a type summary when using p (expression --)?
You might what to use SBValue.CreateValueFromExpression instead of either the frame or the target EvaluateExpression calls for data formatters.
SBValues remember the context they were defined in, and SBValue.CreateValueFromExpression funnels that context back to the expression evaluator. Since the Variable formatters always receive the SBValue that they are acting on, CreateValueFromExpression allows a simple way to forward that context to the new expression.
The EvaluateExpression function is available on the target as well as on frames. Try value.GetTarget().EvaluateExpression(...).
This is not a question about implicit in general - I know how it works. It's about one specific construct. Here comes a quite common patten in myBatis for Scala:
manager.readOnly { implicit session => {
//Code block: Do some DB operations in session
}
}
Definition of readOnly can be found here: https://github.com/mybatis/scala/blob/master/mybatis-scala-core/src/main/scala/org/mybatis/scala/session/SessionManager.scala
How I read it: Call a readOnly method on manager with its argument being a function that takes session as an argument.
My question is: Where implicit session value is taken from? Which context? I do not have to define any session object by myself.
Implicit parameters provide a way to allow parameters of a method to be "found". This means that if a parameter value is not supplied then the compiler will search for an "implicit" value defined within scope according to resolution rules:
Variable has to be marked implicit to be considered as a candidate
Explicit definitions override implicits
Local scope is looked first
Classes companion object is searched if it exists
Scala documentation puts it this way:
First, eligible are all identifiers x that can be accessed at the
point of the method call without a prefix and that denote an implicit
definition or an implicit parameter. Second, eligible are also all
members of companion modules of the implicit parameter’s type that are
labeled implicit.
It seems there's also a bunch of edge cases and not a whole lot of good documentation so I don't encourage to go crazy with implicits or you might be in for a surprise.
My question is: Where implicit session value is taken from? Which
context? I do not have to define any session object by myself.
In this example, implicit session is a formal parameter declaration for the function literal it begins. Thus the actual value is supplied by the code in readOnly that will invoke that function in carrying out its operation.
Making it implicit here means the code in the function body (which I presume to be a Slick query) wants / needs / prefers an implicit parameter for the sake of notational convenience. (Implicit formal parameters may always have their actual parameter passed explicitly).
Incidentally, the inner braces are unnecessary and should be omitted.
I'm using Doxygen to document a Fortran code and I have variables declared such as:
REAL(KIND=8), PARAMETER :: myParam = 1.0_8
but Doxygen gets confused and seems to think REAL is a function and throws:
warning: documented function `real' was not declared or defined.
I have OPTIMIZE_FOR_FORTRAN set to YES so that's not the issue.
Is there a way to rectify this without having to wrap some pre-processor guard around my variables to declare them as REAL without the KIND parameter when building documentation?