I could declare a package or import a package in Modelica models, but I am not sure if there is any difference between them, I tried the following code, both of them work fine.
My question is :
Is there anything I should pay attention to when using these two methods?
partial model A
package SI1=Modelica.SIunits;
import SI2=Modelica.SIunits;
SI1.Voltage u1;
SI2.Voltage u2;
end A;
You are doing two fundamentally different things here, which both work for this case:
package SI1=Modelica.SIunits; is called a short class definition.
You create a new package named SI1, which inherits everything from Modelica.SIunits.
Short class definitions are basically the same as writing
package SI1
extends Modelica.SIunits;
end SI1;
See chapter 4.5.1 Short Class Definitions in the Modelica spec for details.
import SI2=Modelica.SIunits on the other hand simply influences where the Modelica tool looks for class definitions - so no new class is defined here. The chapter 13.2.1.1 Lookup of Imported Names explains that in the Modelica spec.
If you just want to use the package, import it. That's what import was designed for. Declaring a new package only makes sense if you want to add functionality or change anything (which is very limited though, if you are using the short class definition).
Only the import clause seems to trigger the lookup on a package that is not already loaded. Using for example the Modelica_LinearSystems2 library:
import: it checks, and Modelica_LinearSystems2 is loaded
partial model A
import ls2=Modelica_LinearSystems2;
end A;
package: it checks, but Modelica_LinearSystems2 is not loaded
partial model B
package ls=Modelica_LinearSystems2;
end B;
I guess that can break your models if not all of their dependencies are loaded when trying to simulate.
It is nevertheless interesting to see how Dymola (or even Modelica, since pedantic check doesn't throw any error) does not seem to care much about the use of package instead of import, when it comes to packages already loaded. I wasn't expecting the following model to work:
model C
package SI1=Modelica.SIunits;
SI1.Voltage u1;
parameter SI1.Current R=1;
equation
u1=2*R;
end C;
It turns out that even auto-completion (Ctrl+Space) works:
Related
I'm a relative newbie to SystemVerilog.
I have a package with class A defined in it. This class uses a virtual interface, since
it's a driver (BFM) in a testbench. I'm using a package so I can use the same BFM in
other designs.
In my testbench, I import the A class and pass to it an instance of the virtual interface.
However, when a task in the class tries to assign a value to a signal in the interface, I'm getting a compilation error.
What am I doing wrong?
How can one package a BFM with a virtual interface?
Thanks,
Ran
SystemVerilog packages cannot include interfaces within the actual package. So your interface needs to be compiled along with you package source. The classes you define will reside in the package while the interface definition resides in the global scope where modules live.
Classes within packages can make references to virtual interfaces, but you need to make sure the interface is compiled and visible, apart from the package source.
Strictly according to the spec, I don't think this is possible since it adds an implicit external dependency:
Items within packages are generally type definitions, tasks, and
functions. Items within packages shall not have hierarchical
references to identifiers except those created within the package or
made visible by import of another package. A package shall not refer
to items defined in the compilation unit scope.
It doesn't say anything about the design element namespace, which is where interface declarations live, but accessing any member of an interface requires a hierarchical reference.
You should consider packages to be completely self-contained, other than pre-processor directives and import.
Generally the class declaration not present before its usage is resolved with the help of systemverilog typedef definition. For example "Class A uses Class B" and "Class B uses class A" then typedef is used to resolve the stalemate.
Now when you bring in the package with the above scenario then one needs to ensure both Class A and Class B have to be in same package. If they are not then the compile wont go through.
The reason being the SystemVerilog parser will need the definition of the classes indicated with the typedef at the end of the package parsing. This fails.
This issue needs to watched out that "typedef does not apply across package".
I come with the background in languages like Java or Python where modular programming is enabled by packaging system and import directive (aka namespace aliasing). Historically MATLAB's approach to resolve problems like naming conflicts boils down to setting/playing with MATLABPATH, renaming/extending identifiers with prefixes, etc. So far I have been successfully playing with native MATLAB packaging by prepending plus sign "+" before the folder name (MATLAB notation for package also see here). Obviously they are very long to type ;-) Basically I am back to the similar problem as discussed here with no solution. So let me paraphrased for my particular angle:
Assume I have folder +mypackage defined containing file myfun.m with the function code of the same name.
How to achieve aliasing for MATLAB function inside the user (non-java) package as illustrated by the following python code:
from mypackage import myfun
?
[EDIT] Please note that AFAIK import keyword works only for java classes (with jvm attached to MATLAB process). No, import is working perfectly fine for both functions and aliases for objects and function of both Java and MATLAB origin.
Possibly related but not the same.
[EDIT2]
python's
from mypackage import myfun as anotherfun
is equivalent to MATLAB's
anotherfun = #mypackage.myfun
Doesn't
import mypackage.myfun
work?
link to documentation
I have a directory with some helper functions that should be put into a package. Step one is obviously naming the directory something like +mypackage\ so I can call functions with mypackage.somefunction. The problem is, some functions depend on one another, and apparently MATLAB requires package functions to call functions in the very same package still by explicitly stating the package name, so I'd have to rewrite all function calls. Even worse, should I decide to rename the package, all function calls would have to be rewritten as well. These functions don't even work correctly anymore when I cd into the directory as soon as its name starts with a +.
Is there an easier solution than rewriting a lot? Or at least something self-referential like import this.* to facilitate future package renaming?
edit I noticed the same goes for classes and static methods, which is why I put the self-referential part into this separate question.
In truth, I don't know that you should really be renaming your packages often. It seems to me that the whole idea behind a package in MATLAB is to organize a set of related functions and classes into a single collection that you could easily use or distribute as a "toolbox" without having to worry about name collisions.
As such, placing functions and classes into packages is like a final step that you perform to make a nice polished collection of tools, so you really shouldn't have much reason to rename your packages. Furthermore, you should only have to go through once prepending the package name to package function calls.
... (pausing to think if what I'm about to suggest is a good idea ;) ) ...
However, if you really want to avoid having to go through your package and prepend your function calls with a new package name, one approach would be to use the function mfilename to get the full file path for the currently running package function, parse the path string to find the parent package directories (which start with "+"), then pass the result to the import function to import the parent packages. You could even place these steps in a separate function packagename (requiring that you also use the function evalin):
function name = packagename
% Get full path of calling function:
callerPath = evalin('caller', 'mfilename(''fullpath'')');
% Parse the path string to get package directories:
name = regexp(callerPath, '\+(\w)+', 'tokens');
% Format the output:
name = strcat([name{:}], [repmat({'.'}, 1, numel(name)-1) {''}]);
name = [name{:}];
end
And you could then place this at the very beginning of your package functions to automatically have them include their parent package namespace:
import([packagename '.*']);
Is this a good idea? Well, I'm not sure what the computational impacts will be if you're doing this every time you call a package function. Also, if you have packages nested within packages you will get output from packagename that looks like this:
'mainpack.subpack.subsubpack'
And the call to import will only include the immediate parent package subsubpack. If you also want to include the other parent packages, you would have to sequentially remove the last package from the above string and import the remainder of the string.
In short, this isn't a very clean solution, but it is possible to make your package a little easier to rename in this way. However, I would still suggest that it's better to view the creation of a package as a final step in the process of creating a core set of tools, in which case renaming should be an unlikely scenario and prepending package function calls with the package name would only have to be done once.
I have been exploring answers to the same question and I have found that combining package with private folders can allow most or all of the code to be used without modification.
Say you have
+mypackage\intfc1.m
+mypackage\intfc2.m
+mypackage\private\foo1.m
+mypackage\private\foo2.m
+mypackage\private\foo3.m
Then from intfc1, foo1, foo2, and foo3 are all reachable without any package qualifiers or import statements, and foo1, foo2, and foo3 can also call each other without any package qualifiers or import statements. If foo1, foo2, or foo3 needs to call intfc1 or intfc2, then that needs qualification as mypackage.intfc1 or an import statement.
In the case that you have a large set of mutually interdependent functions and a small number of entry points, this reduces the burden of adding qualifiers or import statements.
To go even further, you could create new wrapper functions at the package level with the same name as private functions
+mypackage\foo1.m <--- new interface layer wraps private foo1
+mypackage\private\foo1.m <--- original function
where for example +mypackage\foo1.m might be:
function answer = foo1(some_parameter)
answer = foo1(some_parameter); % calls private function, not itself
end
This way, unlike the intfc1 example above, all the private code can run without modification. In particular there is no need for package qualifiers when calling any other function, regardless of whether it is exposed by a wrapper at the package level.
With this configuration, all functions including the package-level wrappers are oblivious of the package name, so renaming the package is nothing more than renaming the folder.
I have a class uses the following lines, it works fine in a Google App Engine project:
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
But when I included this class in another project, it cause error :
package javax.jdo.annotations does not exist
What should I do to find javax.jdo.* ?
Add the JDO jar file to the class path.
The star notation for imports isn't working the way you think it does.
It's not recursive - it only applies the child classes in javax.jdo, not the child packages.
If you want all the classes in javax.jdo.annotations, you'll need to import javax.jdo.annotations.*, too.
I'd recommend not using the star notation. Better to type out the imports for every class individually. Use an IDE to help you. It's clearer for you and other programmers who come after you where those classes came from.
I want to import the entire weka.classifiers.functions package but dont want to import RBFNetwork class.
(ns com.wekatest
(:import (weka.classifiers Classifier Evaluation)
(weka.classifiers.functions)
(weka.core Attribute FastVector Instance Instances)))
Edit: (weka.classifiers.functions) doesn't import the entire package. How do I do that?
Clojure does not provide a way to import every class in a Java package without specifying each class explicitly. See here for Rich Hickey's response to essentially the same question: http://groups.google.com/group/clojure/browse_thread/thread/fa00a0ff4c264f9a
This does not preclude you from writing code that would add this functionality, but Rich also mentions why this could be difficult (Java packages are not enumerable, so you would have to walk the classpath to know what classes are inside each package).