How to ignore an example when running tests with cargo? - testing

I'm making a proc_macro crate where I have 2 examples in the directory examples/.
When I run cargo test, the 2 examples are compiled but one of the examples is failing on purpose and it prevents the test from running. I want to make an example that fails to compile to show the user how it works.
According to the doc this behavior is intended:
They must compile as executables (with a main() function) and load in the library by using extern crate <library-name>. They are compiled when you run your tests to protect them from bitrotting.
This is fine but how can I disable the compilation for my failing example?

I found it!
You can disable the automatic discovery of examples by adding autoexamples = false to [package]
Then you can enumerate all the examples yourself in the following way:
[package]
...
autoexamples = false
[[example]]
name = "basic"
path = "examples/basic.rs"

Related

scenarios of openflow in omnet are not working properly

I download openflow. It successfully been built. However, only scenario_Small is correctly working, when try to run other scenarios error runtime appears such as that:
Cannot add statistic 'numOutOfOrderArrivals' to module MultiController.Vancouver.client[0].pingApp[0] (NED type: openflow.apps.PingAppRandom): Error in source=numOutOfOrderArrivals: Signal 'numOutOfOrderArrivals' is not declared on type 'openflow.apps.PingAppRandom' (you can turn off this check by adding checkSignals=false to the #statistic property in the NED file) -- in module (PingAppRandom) MultiController.Vancouver.client[0].pingApp[0] (id=161), during network setup
when trying to run "szenario_Domains_multiController"
I tried to fix the error following the hint mentioned in error, but another errors appeared. How to fix those endless errors.
It seems that the codebase of this openflow project is already old and does not correspond to the new builds of OmNET++ and the INET framework.
I was success to build and run test scenarios from this project on Win 10 and OmNET++ 5.6.2 and INET 3.6.6.

Load debug version of pre-built module via npm/webpack

There is a javascript library, pre-built and available on npm, that I wish to develop with/debug. In my case, it is openlayers.
In the classic way of requiring a javascript file and wanting to debug, one would just switch the script url from the production version to the debug version, ie:
to
However, when using webpack and then importing via npm:
import openlayers from 'openlayers'
Gets you the production distribution of the library, the same as the ol.js script from above.
On a side note, to stop webpack trying to parse a prebuilt library and throw a warning about that you must include something like this:
// Squash OL whinging
webpackConfig.module.noParse = [
/\/dist\/ol.*\.js/, // openlayers is pre-built
]
Back to the problem at hand: how can I conditionally load a different entry-point for a module prebuilt and imported like this?
Of course, I can do it in a hacky way. By going into the node_modules/openlayers/package.json and switching the browser field from
"browser": "dist/ol.js",
to
"browser": "dist/ol-debug.js",
Is there a way I can request a different entry point via webpack or by using a different import syntax? Do I first have to petition the library maintainers to update the browser field to allow different entry point hints to browsers, according to the spec? https://github.com/defunctzombie/package-browser-field-spec
Thoughts on a more effective way to make this happen? Yearning to be able to programmatically switch loading of the production and debug versions of a library based on env variables.
Webpack has configuration options for replacing a module into a different path: https://webpack.github.io/docs/configuration.html#resolve-alias
This resolves the openlayers import to use the debug version:
webpackConfig.resolve.alias: {
openlayers: 'openlayers/dist/ol-debug.js'
}
In my build system I have a function that takes the environment type and returns the matching webpackConfig. Based on the parameter I include the above snippet or not.
Full code: webpack-multi-config.js
I have two different (gulp-) tasks for development and production. For example the production task: webpackProduction.js
Line 1 imports the config script with production as type.
My build system is based on gulp starter.

Jython does not resolve python imports from bundled Lib files/folders on Weblogic 10.3.5

I am new to Jython and Python, trying to build a prototype that makes use of Python code to be called from within Java. The code I am developing works in Jetty and in standalone mode (running java -jar from the command line), but not when deployed to weblogic.
How can I make weblogic(10.3.5) server/Jython recognize the Lib folder within jython-standalone-2.5.4-rc1.jar?
My Java code uses the JythonObjectFactory to invoke python modules as outlined in the Jython book:
http://www.jython.org/jythonbook/en/1.0/JythonAndJavaIntegration.html
The Python modules are using external libraries like csv, logging etc. that are not packaged with jython.jar, hence I am using jython-standalone jar.
The java code includes an interface that would define the class type of the first invoked py module from within java. The interface and the input and output (to python modules) type classes are in a package structure as com.abc.xpackage. and the py modules exist at the root of this package. A controller layer calls the objectfactory and in turn executes the python code thus:
JythonObjectFactory calFactory = new JythonObjectFactory(CalcType.class, "Calculate", "Calculate");
CalcType engine = (CalcType)calFactory.createObject();
output = engine.execute(input);
The entire code is bundled as a jar file which would become part of a web application deployed on weblogic. The code was compiled with maven (with jython dependencies included in the repository) and runs fine on the included Jetty runtime within eclipse.
When deployed on weblogic, however, I get a "ImportError: no module named csv" error.
To analyze what is happening, I tried printing the Jython system state path on weblogic and the standalone environment/Jetty. What I found is,
on Jetty, the system path consists of the following:
C:\.m2\repo\org\python\jython\jython-standalone-2.5.3-rc1.jar\Lib, ____classpath__, ____pyclasspath__
on Weblogic, printing the system path by default shows the following:
____classpath__, ____pyclasspath__
I tried forcing the inclusion of the missing path using the code as follows:
public JythonObjectFactory(PySystemState state, Class interfaceType, String moduleName, String className) {
String pathToAppend = new File(state.getClass().getProtectionDomain().getCodeSource().getLocation().toURI().getPath()).getAbsolutePath()+"\\Lib";
state.path.insert(0, new PyString(pathToAppend));
state.path.append(new PyString(pathToAppend));
System.out.println("Jython sys path: "+state.path);
Please note, I prepended as well as appended the path in different trials. The sys path on weblogic now displays the following:
Jython sys path: ['C:\\wldomain\\wls135\\servers\\cgServer\\tmp\\app-1\\war\\WEB-INF\\lib\\jython-standalone-2.5.4-rc1.jar\\Lib', '__classpath__', '__pyclasspath__/', 'C:\\wldomain\\wls135\\servers\\cgServer\\tmp\\app-1\\war\\WEB-INF\\lib\\jython-standalone-2.5.4-rc1.jar\\Lib']
I am still getting ImportError despite this forcing of sys path. Please help why this works in a local environment, and not on weblogic, and if there is any configuration I am missing. Apologize for the rambling long post, I did not know how to explain the problem better. I will try and include any code/artifacts as needed.
Based on a comment(by Lassi) on the blog post below:
http://www.petervannes.nl/files/e1c3c56d15d25dcfd4adb5397a9ef71e-53.php
The jython issue was resolved after explicitly adding the Lib folder python.path to the weblogic startup script as a JAVA_OPTION.
In my case I added the exploded Lib folder to the domain server lib, but based on my test this works also from within the jython jar. Both the following JAVA_OPTIONS worked:
-Dpython.path=C:\wldomain\wls135\lib\Lib
-Dpython.path=C:\wldomain\wls135\lib\jython-standalone-2.5.4-rc1.jar\Lib
The programmatic way of sys.path.append worked for the local environment(jetty) but did not seem to work for weblogic.

Viability of running noflo.js in another javascript engine (not node.js platform)

We're evaluating noflo to be executed on an embedded linux box using an simple javascript engine, being an interpreter (no JIT). In our case, the Node.js engine (with embedded V8 engine) might be too resource intensive.
The immediate question is the how to run the noflo runtime in there. Checking out the GitHub repository (https://github.com/noflo/noflo) and using grunt, we have generated the noflo for the browser using grunt build:browser.
As simple example to actually try and run the generated browser/noflo.js file, I used the d8 shell (V8 engine shell) for an isolated Javascript engine outside the Node.js universe, and appended the following code to the noflo.js generated file:
var fbpData = "<some FBP language connections>";
var noflo = require('noflo');
noflo.graph.loadFbp(fbpData, function(graph) {
print("Graph loaded");
});
Then,
d8 noflo.js
on the Linux shell, which reports
rtm.js:9559: TypeError: undefined is not a function
noflo.graph.loadFbp(fbpData, function(graph) {
^
TypeError: undefined is not a function
at rtm.js:9559:13
Without knowing further, leads me to believe that the noflo.js is not self-contained with all core noflo runtime functionality.
What necessary steps are missing here, for me to get noflo library running in an isolated JS engine (V8 is just an example - it could be any engine the is ECMA V5 compliant)
All code examples on the noflo project web site are tailored for Node.js...
PS: I tried as an alternative to build a browser-based noflo from http://noflojs.org/download/, however this always returns "server error".
Best regards
Gunther Strube
The NoFlo-Gnome project contains a browser build of the noflo-runtime-base repository (https://github.com/noflo/noflo-runtime-base) which itself embeds NoFlo.
You might need to add some aliases because the browser build doesn't necessarily fit your engine : https://github.com/noflo/noflo-gnome/blob/master/src/noflo.js#L89
noflo-gnome runs NoFlo in GJS, which is based on Spidermonkey and GLib/GObject.
It has some minimal require() compatibility which allows pulling in NoFlo. There is a checked in build of noflo (+ noflo-runtime-base) in ./src/libs but I did not immediately find how this is created.
If you're considering using a browser build to speed up the startup time, you might also want to look at : https://github.com/djdeath/noflo-iot
At some point I tried to run NoFlo on a board with very slow I/O. It turned out that a single file compacted build of NoFlo (including all the needed components) was significantly faster.

Yii CAssetManager.basePath is invalid on PHPUnit test

i have a problem to run test. My model use extension Yii mail and then i run test its fail with wrong assert path. Another test runs finaly (model dont use any extensions). Preloading is only log.
I had a similar error and I explicitly set the basePath in config/test.php.
'components'=>array(
...
'assetManager'=>array(
'basePath'=>dirname(__FILE__).'/../../assets',
)
)
Im solved problem
public function setUp(){
Yii::app()->assetManager->basePath = '../../asserts';
}
Im dont know why this error throw only in one model...
PhpUnit runs primary in CLI mode and therefore some of environmental variables are missing. Yii's AssetManager uses one of such variable to determine webroot and since the variable does not exist, it will either throw error or set up invalid assets path on first attempt.
In my opinion, this issue is (indirectly) caused by PHPUnit because it only supports CLI testing mode, which makes some things really more difficult to test than it would be in HTTP request mode. Some guys therefore wrote tools to run unit tests via standard web GUI with whole native HTTP environment (e.g. https://github.com/NSinopoli/VisualPHPUnit). Eventually, you may use HTTP clients like Selenium to run your tests as if clicking over the page (see http://phpunit.de/manual/3.7/en/selenium.html).
Nevertheless, it's a matter of subjective opinion - somebody may argue, that testing in CLI mode has advantages, some guys will hate it. But the fact is, that one has to bear in mind differences between HTTP and CLI mode.