I have successfully created BDD using CUDD package. I am also able to visualize it using some already built tool. I am interested in storing BDD in a file using DDDMP package of CUDD. I read that Dddmp_cuddBddStore() is doing that for us. I am not able to find any examples of using that function. Its arguments are a little complex. Any small example using that function will be a great help.
An interface to the DDDMP package is available with the Cython bindings to CUDD of the Python package dd. An example that creates the BDD of a Boolean function, saves it to a DDDMP file, and then loads it from that file, is the following.
from dd import cudd as _bdd
bdd = _bdd.BDD()
bdd.declare('x', 'y')
# The BDD node for the conjunction of variables x and y
u = bdd.add_expr('x /\ y')
# save to a DDDMP file (the file extension matters,
# for example a PDF extension would result in plotting
# a diagram using GraphViz)
bdd.dump('storage.dddmp', [u])
# load the BDD from the DDDMP file
u_ = bdd.load('storage.dddmp')
assert u == u_, (u, u_)
The source code of the Cython module dd/cudd.pyx includes an example of how to use the functions Dddmp_cuddBddStore and Dddmp_cuddBddLoad
https://github.com/tulip-control/dd/blob/b625dd46120e2e1f5a12190332e6191d07681ee8/dd/cudd.pyx#L1157-L1222
Installation of dd with the module dd.cudd is described here and could be summarized as
pip download dd --no-deps
tar -xzf dd-*.tar.gz
cd dd-*/
python setup.py install --fetch --cudd
This will download and build CUDD, and build and install the Cython bindings of dd to CUDD.
Related
I've installed Time::Duration and it failed most of its tests. I want to be able to rebuild the module - with my edits - from the locally stored module.
I edited the file that contains the module (that corresponds to Duration.pm6):
~/.perl6/sources/D00C101A0157E3EAC494310C9961F299240423E7
And then try building via it's json file:
zef --debug build ~/.perl6/dist/83839D8D315EEDEDFEAF211EE42E8D936ACE29CB
This returns:
===> # SKIP: No need to build Time::Duration:ver<2.00>
!!!> Build failure: ~/.perl6/dist/83839D8D315EEDEDFEAF211EE42E8D936ACE29CB at ~/.perl6/dist
I was hoping that this would rebuild the module with the change I made to the source.
Have I done this wrong, or am I going about this entirely wrong?
As it has been noted already you should not modify installed files. However, the workflow for testing changes of some module is pretty straight forward.
First:
# Fetch and extract the distribution, then change into its directory.
# If the distribution is still in zef's local file cache then it will
# skip the fetch and extraction steps.
zef look Time::Duration
Then:
At this point you can edit any of the files you wish.
Finally:
# test your changes without reinstalling (assumes all dependencies are installed)
zef test .
# Reinstall the modified version of Time::Duration using one of the following:
zef install . --force-install
zef uninstall Time::Duration && zef install .
You should git clone the code or download the zip package, edit the code you want, then zef install . if the current directory have a META6.json file.
I am using the Yocto Project, Jethro release. However, I think this question applies to other releases as well.
I need to modify the image creation process. I have read the BitBake manual, but I still don't know how a full python script or several scripts are included.
Here is what I have found so far:
bitbake core-image-mininmal
After bitbake reads all the config files and parses bblayers.conf, it searches all the layer directories for the recipe core-image-minimal.bb
In core-image-minimal.bb, we have:
inherit core-image
This inherits the class core-image.bbclass which in turn inherits image.bbclass which contains the bitbake code:
fakeroot python do_rootfs () {
from oe.rootfs import create_rootfs
from oe.image import create_image
from oe.manifest import create_manifest
# generate the initial manifest
create_manifest(d)
# generate rootfs
create_rootfs(d)
# generate final images
create_image(d)
}
Searching the source tree for the text create_image, I found the following in image.py:
def create_image(d):
Image(d).create()
and also:
def create(self):
bb.note("###### Generate images #######")
pre_process_cmds = self.d.getVar("IMAGE_PREPROCESS_COMMAND", True)
post_process_cmds = self.d.getVar("IMAGE_POSTPROCESS_COMMAND", True)
I've also created my own class my-class.bbclass and put the following in it:
fakeroot python do_rootfs_prepend () {
print("==> do_rootfs_prepend")
}
fakeroot python do_rootfs_append () {
print("==> do_rootfs_append")
}
and I see the messages in the log file, so I know this is working to add my python code to the do_rootfs function in image.bbclass.
However, I would still like to know how image.py and a whole bunch of other *.py files are included (e.g. rootfs.py) from the poky/meta/lib/oe directory.
First, note that rootfs/image code has been refactored quite a bit after the Jethro release: the last releases do not have some of the functions referred to in your example.
There's no Yocto-specific magic in the library function usage: they are used via standard python module import, just with meta/lib/ in the module search path, e.g.
from oe.image import create_image
will make the create_image() function from meta/lib/oe/image.py available in the current scope.
Arjuncomar states in the OpenCV-Raw readme.md at this link https://github.com/arjuncomar/opencv-raw/blob/master/README.md
"Compilation / Installation
Compiling this package might be a little tricky at the moment since I've only had the chance to test it on my machine so far. First, you need to generate C wrappers for the version of OpenCV on your machine -- this repo holds the wrappers for OpenCV 3.0 (HEAD) only. You can generate these wrappers (and the corresponding Haskell bindings) via:
./setup.sh <path to opencv headers>
e.g.
./setup.sh /usr/local/include"
I ran './setup.sh /usr/local/include', in the root directory of Opencv-Raw, btw I have OpenCV 2.4.7 installed on Ubuntu Saucy 64-bit and I get this error
Traceback (most recent call last):
File "cbits/genhsc.py", line 161, in <module>
cgen.gen(header_dir, headers, dstdir)
File "/home/w/Documents/opencv-raw-master/cbits/genc.py", line 367, in gen
self.readHeaders(header_dir, srcfiles)
File "/home/w/Documents/opencv-raw-master/cbits/genc.py", line 350, in readHeaders
decls = parser.parse(header_dir + hdr)
File "/home/w/Documents/opencv-raw-master/cbits/hdr_parser.py", line 732, in parse
f = open(hname, "rt")
IOError: [Errno 2] No such file or directory: '/usr/local/include/opencv2/core.hpp'
Arjuncomar states "this repo holds the wrappers for OpenCV 3.0 (HEAD) only." so I tried to find an OpenCV 3.0 download but no luck and I've never seen a core.hpp file in /usr/local/include so don't really understand error. I'm trying to incoroporate the autogenerated C wrappers for OpenCV's C++ interface arjuncomar wrote in his haskell bindings into my own OpenCV wrapper for a different language (minus the haskell part of course) and I felt this might be a good first step but if I can just make a make file for this code i/e
the cpp file
void cv_imshow(String* winname, Mat* mat) {
cv::imshow(*winname, *mat);
}
the hpp file
void cv_imshow(String* winname, Mat* mat);
and expect it to be a perfect C wrapper for C++ OpenCV code pls let me know...and if posible a link regarding how to make such a make file posted here would aid greatly....I'm used to C but new to C++/ C++ MakeFiles and would rather do this perfect on my first try so I can output volume more quickly without worrying about making an error...
....Any help is appreciated...A good day=) to you All...
I'm the library author. The library has been moved a couple of times after requests from the OpenCV folks. It's currently sitting in my fork of the opencv_contrib repo. Follow the instructions in the readme to build and install the wrappers.
The procedure amounts to setting up an opencv build directory, having cmake populate it by telling it where the opencv source tree is located and that it needs to load the extra modules from opencv_contrib.
cd <cmake build directory>
cmake -DOPENCV_EXTRA_MODULES_PATH=<opencv_contrib>/modules <opencv_source_directory>
Compiling and installing the library will install the C wrapper headers to "/include/opencv2/c/" and the compiled binary to "/lib/libopenc_c.so". If cabal and ghc are present on the system, it will also compile and install the Haskell bindings. For me, this is as simple as:
make -j6 && sudo make install
Building in this manner should avoid the issue listed in the OP because the headers are pulled by cmake from the source tree and passed directly to the header parser and wrapper generator. Please send bug reports to either the opencv_raw repo or to opencv_contrib. I'm watching both repos and I'm always happy to take pull requests.
Edward -- I understand you're trying to get in touch with me. You can reach me at nrujac at gmail dot com or directly on github by opening an issue on any of repos.
I found out just buld Arjun Comars fork here https://github.com/arjuncomar/opencv and the bindings will be autogenerated in the opencv_generated cpp and hpp files
How do I know which version of Gtest is being used in the project I'm working with? I'm working on a linux platform.
The source code of libgtest or libgtest_main libraries doesn't contain special functions which allow recognize their version (something like GetGTestVersion () or something else).
Also header files doesn't have any defined identifiers (something like GTEST_VERSION or something else).
So you can’t check version of Google C++ Testing Framework at runtime inside user code.
But maintainers provide as part of the framework special script scripts/gtest-conf which:
...
provides access to the necessary compile and linking
flags to connect with Google C++ Testing Framework, both in a build prior to
installation, and on the system proper after installation.
...
Among other things this script has several options which connected with version:
...
Installation Queries:
...
--version the version of the Google Test installation
Version Queries:
--min-version=VERSION return 0 if the version is at least VERSION
--exact-version=VERSION return 0 if the version is exactly VERSION
--max-version=VERSION return 0 if the version is at most VERSION
...
The script also contain usage example of it:
Examples:
gtest-config --min-version=1.0 || echo "Insufficient Google Test version."
...
It means that user can test version of the framework in build time using script gtest-config.
Note:
The script gtest-config get actual version of the framework during configuration through variables declared in configure.ac.
...
AC_INIT([Google C++ Testing Framework],
[1.7.0],
[googletestframework#googlegroups.com],
[gtest])
...
And after calling autoconf the following identifiers inside configure file populated:
...
# Identity of this package.
PACKAGE_NAME='Google C++ Testing Framework'
PACKAGE_TARNAME='gtest'
PACKAGE_VERSION='1.7.0'
PACKAGE_STRING='Google C++ Testing Framework 1.7.0'
PACKAGE_BUGREPORT='googletestframework#googlegroups.com'
PACKAGE_URL=''
...
# Define the identity of the package.
PACKAGE='gtest'
VERSION='1.7.0'
...
As far the framework compiled with option AC_CONFIG_HEADERS this identifiers stored into file build-aux/config.h and availiable for user at compile time.
The file CHANGES, in the gtest home directory, contains a gtest version number.
If you have cloned the official repo you can check the latest Git commit inside Google Test's directory (using for example git log -n 1 or git rev-parse HEAD) and compare it with the list of released versions.
In my case, the commit hash is ec44c6c1675c25b9827aacd08c02433cccde7780, which turns out to correspond to release-1.8.0.
I currently have a .cpp file that I can compile using sourceCpp(). As expected the corresponding R function is created and the code works as expected.
Here it is:
#include <Rcpp.h>
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector exampleOne(NumericVector vectorOne, NumericVector vectorTwo){
NumericVector outputVector = vectorOne + vectorTwo;
return outputVector;
}
I am now converting my project over to a package using Rcpp. So I created the skeleton with rStudio and started looking at how to convert things over.
In Hadley's excellent primer on Cpp, he says in section "Using Rcpp in a Package":
If your packages uses the Rcpp::export attribute then one additional step in the package build process is requried. The compileAttributes function scans the source files within a package for Rcpp::export attributes and generates the code required to export the functions to R.
You should re-run compileAttributes whenever functions are added, removed, or have their signatures changed. Note that if you build your package using RStudio or devtools then this step occurs automatically.
So it looks like the code that compiled with sourceCpp() should work pretty much as is in a package.
I created the corresponding R file.
exampleOne <- function(vectorOne, vectorTwo){
outToR <- .Call("exampleOne", vectorOne, vectorTwo, PACKAGE ="testPackage")
outToR
}
Then I (re)built the package and I get this error:
Error in .Call("exampleOne", vectorOne, vectorTwo, PACKAGE = "voteR") :
C symbol name "exampleOne" not in DLL for package "testPackage"
Does anyone have an idea as to what else I need to do when taking code that compiles with sourceCpp() and then using it in a package?
I should note that I have read: "Writing a package that uses Rcpp" http://cran.rstudio.com/web/packages/Rcpp/vignettes/Rcpp-package.pdf and understand the basic structure presented there. However, after looking at the RcppExamples source code, it appears that the structure in the vignettes is not exactly the same as that used in the example package. For example there are no .h files used. Also neither the vignette nor the source code use the [[Rcpp::export]] attribute. This all makes it difficult to track down exactly where my error is.
Here is my "walk through" of how to go from using sourceCpp() to a package that uses Rcpp. If there is an error please feel free to edit this or let me know and I will edit it.
[NOTE: I HIGHLY recommend using RStudio for this process.]
So you have the sourceCpp() thing down pat and now you need to build a package. This is not hard, but can be a bit tricky, because the information out there about building packages with Rcpp ranges from the exhaustive thorough documentation you want with any R package (but that is above your head as a newbie), and the newbie sensitive introductions (that may leave out a detail you happen to need).
Here I use oneCpp.cpp and twoCpp.cpp as the names of two .cpp files you will use in your package.
Here is what I suggest:
A. First I assume you have a version of theCppFile.cpp that compiles with sourceCpp() and works as you expect it to. This is not a must, but if you are new to Rcpp OR packages, it is nice to make sure your code works in this simple situation before you move to the more complicated case below.
B. Now build your package using Rcpp.package.skeleton() or use the Project>Create Project>Package w/Rcpp wizard in RStudio (HIGHLY recommended). You can find details about using Rcpp.package.skeleton() in hadley/devtools or Rcpp Attributes Vignette. The full documentation for writing packages with Rcpp is in Writing a package that uses Rcpp, however this one assumes you know your way around C++ fairly well, and does not use the new "Attributes" way of doing Rcpp. It will be invaluable though if you move toward making more complex packages.
You should now have a directory structure for your package that looks something like this:
yourPackageName
- DESCRIPTION
- NAMESPACE
- \R\
- RcppExports.R
- Read-and-delete-me
- \man\
- yourPackageName-package.Rd
- \src\
- Makevars
- Makevars.win
- oneCpp.cpp
- twoCpp.cpp
- RcppExports.cpp
Once everything is set up, do a "Build & Reload" if using RStudio, or compileAttributes() if you are not in RStudio.
C. You should now see in your \R directory a file called RcppExports.R. Open it and check it out. In RcppExports.R you should see the R wrapper functions for all the .cpp files you have in your \src directory. Pretty sweet, eh?.
D) Try out the R function that corresponds to the function you wrote in theCppFile.cpp. Does it work? If so move on.
E) You can now just add new .cpp files like otherCpp.cpp to the \src directory as you create them. Then you just have to rebuild the package, and the R wrappers will be generated and added to RcppExports.R for you. In RStudio this is just "Build & Reload" in the Build menu. If you are not using RStudio you should run compileAttributes()
In short, the trick is to call compileAttributes() from within the root of the package. So for instance for package foo
$ cd /path/to/foo
$ ls
DESCRIPTION man NAMESPACE R src
$ R
R> compileAttributes()
This command will generate the RcppExports.cpp and RcppExports.R that were missing.
You are missing the forest for the trees.
sourceCpp() is a recent function; it is part of what we call "Rcpp attributes" which has its own vignette (with the same title, in the package, on my website, and on CRAN) which you may want to read. It among other things details how to turn something you compiled and run using sourceCpp() into a package. Which is what you want.
Randomly jumping between documentation won't help you, and at the end of the genuine source documentation by package authors may be preferable. Or to put a different spin on it: you are using a new feature but old documentation that doesn't reflect it. Try to write a basic package with Rcpp, ie come to it from the other end as well.
Lastly, there is a mailing list...