I have two grammars A and B and two files a and b (using grammars A and B respectively). The file a specify variables names, b specify the filename of a.
In b using the the file a want to:
reference variables defined in a
during code generation of b I want to include the contents of the file created generated for a.
How can this be done in xtext?
Update 1
Example grammar B
Model:
ref_model=RefModel
ref_vars+=[Vars]+
;
RefModel:
'reference' 'file' name=ID
;
Where RefModel define where the file a can be located and Vars are defined in a.
In the past we used to use importURI for that, but you can do that through scoping on your own also.
If you for instance want to use the simple name of the file, you should make the name in B a reference to the root element of A.
Model:
ref_model=RefModel
ref_vars+=[Vars]+
;
RefModel:
'reference' 'file' name=[ModelA]
;
Then you need to index the root element of A models using the simple file name of the resource URI.
Related
It's a common methodology to keep assertions, cover points, etc. separate from the design by putting them in a separate module or interface, and use bind to attach them to the design, e.g.,
module foo (input a);
wire b = a;
endmodule
interface foo_assertions (input a, b);
initial #1 assert (b == a);
endinterface
bind foo foo_assertions i_foo_assertions(.*);
One problem with this is that it requires maintenance of the port list in foo_assertions. However, if foo has a bar submodule, signals inside bar can be accessed conveniently using hierarchical references in the assertions file relative to foo, e.g., assert (i_bar.sig == a).
Is there a way to use the hierarchical path syntax for accessing variables declared directly in foo as well, eliminating the need for the port list in foo_assertions? Note that foo is not necessarily the top-level module, so $root.b will not work. It looks like foo.b works, however is this safe when multiple instances of foo exist at the top level?
Verilog has always had upwards name referencing which is why foo.b works (See section 23.8 in the IEEE 1800-2017 SystemVerilog LRM). It does not matter how many instances of foo there are, as long as you only bind foo_assertions into a module named foo. Each upward reference applies to the specific instance that reference is underneath.
When referring to the top-level module in a hierarchical path, you have been using an upwards reference without necessarily realizing it.
I have got a big audio file foo and a hash file h with h = sha256sum(foo);
Third parties can check the integrity of foo provided h is published somewhere.
I now want the third party only to have parts of foo. However they shall be able to verify these parts being a subset of (the unpublished) foo.
Generally speaking:
Considering File foo = foo0.concat(foo1).concat(foo2).....concat(fooN);
Exists a Function where func(sha256sum(foo)) == func(sha256sum(foo0),....,sha256(fooN)) ?
How do I use Simulink.Bus.createMATLABStruct inside a function? I'm loading some bus definitions in the function's scope but createMATLABStruct doesn't see those. If I load the bus definitions in the global workspace then the function works.
Doesn't work:
function test()
load('someBuses.mat');
s = Simulink.Bus.createMATLABStruct('aBus');
end
Works:
load('someBuses.mat');
% ...
function test()
s = Simulink.Bus.createMATLABStruct('aBus');
end
Any ideas?
Simulink.Bus.createMATLABStruct accepts a 4th (undocumented) input -- open the file in the editor to see the 4th input -- which can either be 'base' (the default) or a Data Dictionary object.
The default is 'base', which is why the version you have that loads from the Base Workspace works.
Have a look at this link to find out about creating Data Dictionaries.
I have a problem with imported xsd's.
i have 3 xsd service.xsd, header.xsd and inputmessage.xsd
inputmessage.xsd contains the root element.
service.xsd imports header.xsd and inputmessage xsd.
while generating sample xml of service.xsd in eclipse i get the following error "No root element exists since the scheme provided has no global elements".
The error you are seeing is typically due to use of schema documents which do not declare an outer element (a 'root element'). The schemas with which you are working may define only complex types (likely with enclosed elements). The significance of the element w.r.t. file creation is that an element defines the concrete implementation of a type in an xml file (i.e. the name of the element from the schema becomes the tag name in the xml file). The complex type defines the structure that would apply to an element which is of that type.
In your service.xsd file, try inserting the following (you may need to work with the prefix binding to be consistent with your schema file):
<element name="rootElement" type="tns:LocallyDefinedType" />
where 'tns' is bound to the schema target namespace and 'LocallyDefinedType' is the name of a complex type defined in the schema document (the type you are hoping to see in the generated xml document).
If this does not help, post your schema documents (or some appropriate dummied-up examples) and a more targeted element declaration can be provided.
I'm a bit confused about interfaces vs. signatures in OCaml.
From what I've read, interfaces (the .mli files) are what govern what values can be used/called by the other programs. Signature files look like they're exactly the same, except that they name it, so that you can create different implementations of the interface.
For example, if I want to create a module that is similar to a set in Java:
I'd have something like this:
the set.mli file:
type 'a set
val is_empty : 'a set -> bool
val ....
etc.
The signature file (setType.ml)
module type Set = sig
type 'a set
val is_empty : 'a set -> bool
val ...
etc.
end
and then an implementation would be another .ml file, such as SpecialSet.ml, which includes a struct that defines all the values and what they do.
module SpecialSet : Set
struct
...
I'm a bit confused as to what exactly the "signature" does, and what purpose it serves. Isn't it acting like a sort of interface? Why is both the .mli and .ml needed? The only difference in lines I see is that it names the module.
Am I misunderstanding this, or is there something else going on here?
OCaml's module system is tied into separate compilation (the pairs of .ml and .mli files). So each .ml file implicitly defines a module, each .mli file defines a signature, and if there is a corresponding .ml file that signature is applied to that module.
It is useful to have an explicit syntax to manipulate modules and interfaces to one's liking inside a .ml or .mli file. This allows signature constraints, as in S with type t = M.t.
Not least is the possibility it gives to define functors, modules parameterized by one or several modules: module F (X : S) = struct ... end. All these would be impossible if the only way to define a module or signature was as a file.
I am not sure how that answers your question, but I think the answer to your question is probably "yes, it is as simple as you think, and the system of having .mli files and explicit signatures inside files is redundant on your example. Manipulating modules and signatures inside a file allows more complicated tricks in addition to these simple things".
This question is old but maybe this is useful to someone:
A file named a.ml appears as a module A in the program...
The interface of the module a.ml can be written in file named a.mli
slide link
This is from the OCaml MOOC from Université Paris Diderot.