I have included the extension [nw] at the beginning of the netlogo programme. But when I use "nw:clustering-coefficient", the error "Nothing named nw:clustering-coefficient has been defined" jumps out.
This error might mean that you are using an older release candidate of the NW extension. The nw:clustering-coefficient has been added right before the release of NetLogo 5.1.0.
I would suggest making sure that you are using NetLogo 5.1.0 and the version of the extension that comes bundled with it.
You can see which version of NetLogo you are using in the Help / About ... menu. And the nw:version primitive will return the current version of the NW extension (which as of NetLogo 5.1.0 still shows "1.0.0-RC4").
Related
I am struggling to understand why the below code is throwing an error when it ran seamlessly about a year back. The code snippet is from a popular Coursera course. Does the Music21 package has some recent changes around stream.Voice?
data_fn = 'data/original_metheny.mid'
midi_data = converter.parse(data_fn)
melody_stream = midi_data[5] # For Metheny piece, Melody is Part #5.
melody1, melody2 = melody_stream.getElementsByClass(stream.Voice)
The error thrown is ValueError: not enough values to unpack (expected 2, got 0), which means there is no output for stream.Voice class when previously there were outputs for the same data (midi file). melody_stream.getElementsByClass('Measure') does show outputs.
Can you guide how to debug this?
Yes, one of the improvements in music21 v.7 is that files imported from MIDI now have a similar representation to files imported from MusicXML and other formats. Specifically, Parts now have Measures, which may or may not have Voices, rather than Parts directly containing Voices. Code should not depend on finding Voices directly contained in Parts, which is what this example was doing.
Instead, use this code to find all the measure-voices:
melody_stream.recurse().getElementsByClass(stream.Voice)
Or, equivalently, use the shortcut syntax in v.7:
melody_stream[stream.Voice]
Or, if you don't want the measures at all, call flatten() or chordify() depending on your use case.
What worked for me was downgrading music21 package to a version older than 7.x. So if you already have a newer version of music21 package installed, remove it using pip uninstall music21, Then install the 6.7.0 version using pip install music21==6.7.0.
I am currently analysing movement data using the script provided by Lascelles et al (2016) in their paper "Applying global criteria to tracking data to define important areas for marine conservation". I have made some changes and additions to the script and now face the problem that the different packages needed do not work within the same version of R.
I am using the package "trip" which from what I can see works with >=3.2.5 but depends on spatstat which works with >=3.3.0. The script also uses the overlay function from the "sp" package, however this function has been deprecated, thus in order to run needs an older version of R (I have previously used version 3.0.3.
Is there a way to use multiple versions of R within the same project, or would I have to rewrite the script to avoid using functions that do not work within the same R version?
If you don't need any of the new functions/features introduced in the later versions of trip and spatstat I think you can just use the checkpoint package and install the versions from an earlier date. There is a nice vignette you can have a look at, but basically you just do something like:
install.packages("checkpoint")
library(checkpoint)
checkpoint("2016-01-01")
I recently obtained a license to use Embedded Coder with an existing Simulink model that we have developed. In attempting to generate C code for the first time from the model, I am working through several errors. At first, we had no code generation templates (.cgt) files defined in the model parameters. After some hunting, I found the default template that comes with MATLAB (matlabroot/toolbox/rtw/targets/ecoder/ert_code_template.cgt).
The latest is that I get errors on nearly every token in this default code generation template.
Since I'm just trying to get something to build, at first I commented out the offending lines (things like RTWFileVersion, etc), but now I am noticing that it's giving me errors for things that are mandatory (ie. Types). Types is one of several required items that must be in the .cgt file, so what's wrong that causes MATLAB to not recognize these tokens? I'm guessing something may be messed up with my installation, such as a path.
Other details:
Simulink R2013A x32
Target is a Freescale device
Thanks to Matthias W for getting me to check other configuration options. Turns out I had selected a .tlc file that was probably incompatible with Embedded Coder.
In Code Generation for "System target file" I have selected the ert.tlc file and now I am able to build the parts of my model I'm interested in.
In Eclipse CDT, I would like to create syntax highlighting and a error parser for a custom filetype, lets say *.xy.
Those files do not contain C-Code, so i cannot use any existing parsers.
What kind of plugins would I have to create?
For the error parser, I think I have to use Codan? (have not tried it yet)
https://www.ibm.com/developerworks/java/library/j-codan/
The CDT is the wrong start for your journey, if your language is not related to the CDT supported languages and workflows. Implement an xtext based language editor instead.
Maybe this is a simple solution for you:
colorEditor plugin
You can simply add a new language by unpacking the jar archive, then adding a xyz.xml file for your .xyz files.
Pakc together again, and copy into your Eclipse "plugins" dir.
You need to introduce a new "language" - this is the extension point: http://help.eclipse.org/helios/topic/org.eclipse.cdt.doc.isv/reference/extension-points/org_eclipse_cdt_core_language.html
Codan is not an "error parser" it is a static analysis framework. Error parser processes output of the command-line tools you use to build the application (e.g. compiler, linker) to identify errors that happened during the build and filling their attributes, e.g. source file name and line number.
Codan analyzes the source code in the editor to identify errors. E.g. it checks if the variable used in the expression was declared beforehand. Note that same check can be performed by a compile at a build time and then captured by error parser and shown in the editor/problems view - the goal of Codan is to detect problems sooner, before the build is even ran. Codan can also perform some checks that compiler doesn't.
I have an Eclipse plugin and I am aiming for 3.1 or 3.2 as a minimum version to support. The problem is that some of my code only works in version 3.5 and above (see my other question: Is there an alternative to CaretListener in Eclipse?).
Now that I have code that works in the older versions and different code that works in the newer versions, is there a way that I can call the newer code only if my plugin is running in version 3.5 or above and then revert to the old code if running anything older?
As a test, I've created two plugins that have the same class within it (just doing slightly different things). I have marked the org.eclipse.ui dependency as a minimum of 3.5 in one plugin and 3.1 as a minimum in the other but I can't get the one that relies on 3.5 to be ignored in older versions...
Can anyone help?
Thanks,
Alan
You could use org.eclipse.core.runtime.Platform to get the org.eclipse.ui Bundle and check the version.
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
// then do something with that
Register MyListener if >=3.5, and OldMyListener otherwise.
EDIT:
Right, the above is only good for capturing differences in runtime behaviour.
Eclipse supports a couple of tricks for only loading some classes.
The easiest from a development point of view is the trick that #ShiDoiSi mentioned.
Bundle myBundle = org.osgi.framework.FrameworkUtil.getBundle(this.class);
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
Version cutOff = new Version(3,5,0);
final Executable processListener;
if (ui.compareTo(cutOff)<0) {
Class pc = myBundle.loadClass("my.pkg.OldListenerProcess");
processListener = (Executable) pc.newInstance();
} else {
Class pc = myBundle.loadClass("my.pkg.ListenerProcess");
processListener = (Executable) pc.newInstance();
}
processListener.execute(targetObject);
Another option that uses more of the eclipse framework would be defining your own extension point so that contributions from other bundles can decide which version to use. Basically it's the same pattern as above, except the version checking is done by the dependency ranges on the plugin the contributes the Executable to run. Depend on org.eclipse.ui [0.0.0,3.5.0) for the old way, and simply specifying org.eclipse.ui 3.5.0 (that's an open ended range on 3.5.0) for the current way. Then you can read your extension and instantiate the class provided.
If you were creating extra plugins for this (a little heavy weight for the 2 differences) you could define a command in your main plugin, and have the extra plugins provide the equivalent handler. The plugins would still have to have dependency ranges so that only one would load for the <3.5 or >=3.5 case. Then using the command API you could execute the command (and the correct handler would run).
ICommandService cmdS
= (ICommandService) workbenchWindow.getService(ICommandService.class);
Command process = cmdS.getCommand("my.pkg.ListenerProcess");
ParameterizedCommand cmd = new ParameterizedCommand(process, null);
IHandlerService handlerS
= (IHandlerService) workbenchWindow.getService(IHandlerService.class);
IEvaluationContext ctx = handlerS.createContextSnapshot(false);
ctx.addVariable("toAddListener", targetObject);
handlerS.executeCommandInContext(cmd, null, ctx);
Then your implementation of handler would use HandlerUtil.getVariable(event, "toAddListener") to extract the object you need from the ExecutionEvent.
It sounds to me that you should be supplying two plugins, one supporting version 3.1 to "just below" 3.5, and the other one from 3.5 upwards. So you don't really get to choose, it's basically the Eclipse plugin layer choosing the right one based on your version ranges.
Or if you provide just the compiled class files, then of course you could load the required class dynamically based on testing the version of the running Eclipse.