The following gives bad theory import "Multivariate_Analysis"
imports Multivariate_Analysis
Importing Main works fine, how do I import modules?
For theory imports, you usually have to specify the full or relative path to the theory file. So for Multivariate_Analysis, this is <path to isabelle distrib>/src/HOL/Multivariate_Analysis/Multivariate_Analysis. The path may be only omitted if the theory is already part of the session image. So as Main is part of the default image HOL, you can import it without a path. Opinions diverge whether it is better to import theories from session images with or without paths.
The path may also contain environment variables like $ISABELLE_HOME or $AFP, which users can set in their local settings file such that the theories work across different installations. For everything from the Isabelle distribution, it is custom to use ~~ for the path of the Isabelle distribution folder.
In summary, your import should read as follows:
theory My_Theory
imports "~~/src/HOL/Multivariate_Analysis/Multivariate_Analysis"
begin
As Multivariate_Analysis is a fairly large module, it might be sensible to change the default session image, though, such that all these theories are not loaded at every start of Isabelle/jEdit afresh. You can do so by specifying -l HOL-Multivariate_Analysis at the command line upon invocation or by selecting this session in the theory panel and restarting Isabelle/jEdit.
Update: Since Isabelle2017, it is preferable to import theories from other sessions via session names instead of relative path names. That is, the
theory Multivariate_Analysis would be imported as
theory My_Theory
imports "HOL-Multivariate_Analysis.Multivariate_Analysis"
begin
Related
What is the difference between resource and library file in robot framework?
I searched google but couldn't able to find the answer
The resource file content is in the Robot Framework syntax. When it's imported in a suite, you can use all its keywords and variables, defined in the corresponding sections. Also all its imports (other Resource and Library it defines in the Settings section) are now available for usage.
The libraries on the other hand are (usually) written in the Python language. They can be ones installed through pip, or standalone scripts or modules. In the simplest case, all public functions of a module (more specifically - not-hidden) are available as keywords to be used in the suite. For more advanced usage (scope, state upkeep), they have to follow specific structure (usually accomplished through classes, and using identifiers/decorators expected by RF).
There is a third type of import, for which you haven't asked but I'm adding for completeness - the Variables files. Their format is once again Python code, which makes them quite versatile and powerful compared to vars defined in RF syntax (you can set the variables' content through complex programming constructs).
One caveat to keep in mind with them - the framework expects every attribute of the module to be a variable, and makes it accessible in your suite; this includes even other modules the file imports :). Thus you have to hide them through the _ name suffix (or, abuse this side effect for silent imports in some exotic cases :)).
I've included links to the relevant sections of the user guide, for further information.
I understand that you can create a separate yang file (Something like a textual Convention to store syntax values for MIBS)and import it into another yang file to make the data more organised and structured, but I can't seem to understand what the include statement does differently?
Does it "import" the entire file into the file that's including it - and if so would this be read before the file including it...?
Please help :)
YANG relies heavily on a concept known as "namespaces", which stems from XML naming conventions. Each namespace has a unique resource identifier and allows definitions (in different namespaces) to have same names at same definition levels while avoiding name clashes. When you define a YANG module, you are actually defining a namespace.
An import statement is used to access definitions from a foreign namespace (another module), while an include statement introduces a mechanism that allows a single namespace (single module) to be logically split into several files, conveniently named module and submodules. For includes, there is always exactly one module file, which includes all submodule files that belong to it. A submodule may only belong to a single module and may not be imported (directly). To an importing module, a module that includes submodules, looks like a single entity. Submodules may include eachother, but with YANG version 1.1, this has become unnecessary, since a submodule immediately gains access to all definitions in all submodules and the module they all belong to. In YANG version 1 you had to explicitly include a submodule to use definitions from it in another submodule, while never being able to access definitions in the module to which they belonged.
An import does not "inline" definitions into the importing module, while an include does exactly that. Importing a module gives you access to its top-level definitions (typedefs, groupings, idenitites, features and extensions) and allows you to use schema node identifiers that identify nodes in the imported module (for the purpose of augmentation and deviation, for example).
Definitions from a foreign namespace are always accessed via a prefix, which are part of an import statement's definition. Definitions that come from includes do not need to be prefixed when used, and if they are, are prefixed with the including module's (or submodule's) prefix.
YANG "compilers" usually process these files when they hit either an import or an include statement. They need to process them in order to be able to resolve definitions in body statements of the defining module. That is why these statements are required to appear in a module's header section.
There is an entire section in YANG specification dedicated to modules and submodules, where you can read more on the topic.
I'm new Isabelle/Hol user and I have some confusion regarding using the existing definitions in Isabelle. I have to define a Complete lattice structure and Complete Partial Order (CPO) structure in my model. I found that those defintion already exists as Classes in the HOLCF Porder.Thy and Lattice.thy. So If I wanted to include those definitions in my model how should I proceed ? Like I copy paste all the definition or there is a specific command for that ?
Thanks
In the header of your own theory, you can import other theories. Complete lattices already exist in the Main theory (which you would usually import anyway if you're using HOL). Other theories can be referenced using ~~/src/HOL/... (Isabelle automatically substitutes ~~ for the home path of your Isabelle installation).
For the precise syntax, I recommend reading through prog-prove, especially ยง2.1.
I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:
FooLibrary.Bar
FooLibrary.Qux.Rumps
FooLibrary.Qux.Scrooge
..
Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.
First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
This is my main issue.
However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "#export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:
goog.requireRecursively('FooLibrary')
in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.
I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.
You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.
If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.
First, I need closurebuilder.py to send the full list of files to the closure compiler. ...
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.
What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.
My GeolocationMarker library has an example of this strategy.
is there a simple way to generate a JAR file, that contains only the classes that depend transitive from a certain "main" class (reflection omitted of course).
I want to provide a little part of my application to someone else but do not want to export the whole application.
Thanks,
M.
Probably the easiest approach is using a tool like yGuard which "...provides elaborate code shrinking functionality through dependency analysis." This would also solve the same problem where you give it an entry point, and it performs dependency analysis to work out which classes can be excluded from the Jar.
However, I have throught about this problem myself a few times and fancied having a go at it myself for the challenge. All it would take would be to parse the import statements of Java source files and build a dependncy graph of how the classes interact with each other. Each reference from the main class should be recursively scanned until a complete graph is assembled. Then once the graph is assembled it would be a case of outputting this in a way that some packaging logic could process (or if you are feeling daring, the JDK has its own built in Jar creating/modifying code to do it yourself). Granted, this approach would require writing this custom utility and would also miss fully qualified class references in the code.