How can find what is included in the #containment annotation? - rascal

How can find what is included in the #containment annotation? I can not find that in the documentation online, that refers only to grammar-spec and nothing more? I'm talking about trying to obtain information/facts from the M3 model..
As an example:
scheme=="java+variable" or some other condition is used in a comprehesion to filter, how do you know what can be used to find certain thing??
Thanks

The documentation is not complete, but these pages are relevant:
http://tutor.rascal-mpl.org/Rascal/Libraries/lang/java/m3/m3.html#/Rascal/Libraries/analysis/m3/Core/Core.html
http://tutor.rascal-mpl.org/Rascal/Libraries/lang/java/m3/m3.html
I would also have a look at the code in these files:
https://github.com/cwi-swat/rascal/blob/master/src/org/rascalmpl/library/lang/java/m3/Core.rsc
https://github.com/cwi-swat/rascal/blob/master/src/org/rascalmpl/library/lang/java/m3/AST.rsc
They can be found in the rascal navigator view in Eclipse as well. In particular the core file contains all to know about the relations and locations in the java m3 model.

Related

How can I programmatically set the value inside a complex Map/List by a given path in Dart?

Here is an example on DartPad.
The example has the commentary but let me explain anyway. Suppose we have a quite complex Map<String, dynamic> or a List<dynamic>, e.g. it might contain an integer inside a map inside a list inside another map inside another list...
I get a path, which I called targetPath and is a List<dynamic>, defining where the target value is inside this complex data.
I'd like to change the value referred by this targetPath but have no idea how to do that.
How can I change a value inside a List/Map given by a path?
Thanks in advance.
Troubleshooting
I have looked up some solutions on the internet which have not been applicable in my situation but I'd like to put them here and state why they did not work in my case.
Merging Two Maps
Combine/merge multiple maps into 1 map
I have come across this while looking for it but my case has targetPath which is not applicable to this situation. The question has many answers but none of it covers my case.
Environment
Dart 2.15.1
Flutter 2.8.1 (if relevant)
Actually, I have found a package called deeply, which addresses the same issue I have at hand.
All the examples adress Maps though. However, I took a quick look at the implementation, which seems to be friendly with List type at the first glance.

Cache XMLProvider generated model(s)

Using XMLProvider from the FSharp.Data package like:
type internal MyProvider = XmlProvider<Sample = "C:\test.xml">
The test.xml file contains a total of 151,838 lines which makes up 15 types.
Working in the same project as the type declaration MyProvider is a pain, as it seems the XmlProvider is triggered everytime I hit CTRL+SPACE (Edit.CompleteWord) - and therefore regenerates all the models, which can take up to 10sec.
Is there any known work around, or setting to cache the generated models from XmlProvider?
I'm afraid F# Data does not currently have any caching mechanism for the inferred schema. It sounds like something that should not be too hard to add - if anyone is interested in contributing, please open an issue on GitHub to start the discussion!
My recommendation for the time being would be to try to simplify the sample XML, so that it is shorter and contains just a few representative records of all the different kinds.

The benefit of libraries over object files

I have been reading topic regarding linux libraries
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
it mentions:
"The benefit is that each and every object file need not be stated when linking because the developer can reference the individual library"
I am not following this statement. I wonder if someone could have a further explanation or an example please?
Thanks
It's not the best phrasing in the world, IIUC, and is a bit misleading. IMHO, instead of
The benefit is that each and every object file need not be stated when linking because the developer can reference the individual library
it should say
The benefit is that each and every object file need not be stated when linking because the developer can reference the entire library (as a named entity)
Basically, it means the following. In the absence of libraries, the author of what is now a library, could simply build a list of object files, like this:
a0.cpp -> a0.o
a1.cpp -> a1.o
...
and then she could write in the documentation "if you want functions x, y, and z", then you need to link with a3.o (because it contains x and z), a42.o (for y), but also a23.o, a15.o, and a72.o, because they contain necessary underlying parts.
This is of course unwieldy. A saner approach, as your link explains, is to create a single library from a state of common-purpose functions and classes. The instructions become "if you want the functionality of shooting up foo aliens, link with the foo_alien_shooting library".

Where is the source code for Apache Ant "Apply" task?

I am looking for the source code that implements the apply task in ant. I have been search through the sources at:
http://svn.apache.org/repos/asf/ant/ant-core/trunk/
Alas, grep and find have not revealed its whereabouts! I must be looking in the wrong place. Anyone know where this source file is?
The file org/apache/tools/ant/taskdefs/defaults.properties gives the mapping between XML element names and the implementing classes. In the case of apply it looks like the class is Transform, which in turn is a no-op subclass of ExecuteOn (as execon is a deprecated alias for apply).

ZF2 Directory/Namespace Model Object Location

In the zf2 database and models tutorial a path such as this leads to a directory containing my model classes:
module/Album/src/Album/Model
I have created two more classes at:
module/Album/src/Album/Model/AlbumRelatedClass.php
module/Album/src/Album/Model/AlbumRelatedTable.php
I would like to put these classes at
module/Album/src/AlbumRelated/Model/
I have created duplicates of the model classes there for the purposes of this test, unfortunately, my module config for Album tells me that it cannot find the classes at the AlbumRelated location. I have tried changing the namespaces in the AlbumRelated location to AlbumRelated\Model and directly referring to the class location (\Album\Model\AlbumRelated()) without success.
Does anyone know how I can do this? If I shouldn't be doing this, can somebody explain why? I'm also interested to know why the folder structure is Album/Model/Album (it seems redundant, and I wasn't clear on the explanation in the tutorial).
Any help given would be great, thanks :)
The short answer is that it can't find the class because you probably didn't set up the autoloader config to know about a new "AlbumRelated" namespace. Look at what happens in \Album\Module::getAutoloaderConfig(). You probably want to add a key/value pair to namespaces like 'AlbumRelated' => __DIR__ . '/src/AlbumRelated'. That will tell the autoloader where to look for classes under the AlbumRelated namespace.
That said,
If I shouldn't be doing this, can somebody explain why?
You probably shouldn't be doing it that way. You've got a top-level namespace called \Album. Then you have \Album\Model namespace under it. Any models related to Albums ought to live there. Imagine you had an entity in your system for Record Labels, so you could associate an Album with the label that released it. The ZF2 expectation is that you'd create a class called \Album\Model\RecordLabel that lived in module/Album/src/Album/Model/RecordLabel.php. As long as we assume that RecordLabels are primarily related to albums, that all makes perfect sense.
Of course, you could stick RecordLabel in it's own module as well, if you had a lot of workflow around managing them.
I'm also interested to know why the folder structure is Album/Model/Album
I assume you mean Album/src/Album. That redundancy is to keep a nice clean PSR-0 setup. So, the first Album is identifying the module, and the second is the top-level of the Album namespace. This provides maximum flexibility, but isn't a hard and fast rule. See Rob Allen's recent blog post about alternative module layouts in zf2 for an exploration.

Resources