I succesfully builded Caffe on Windows 10 by following https://github.com/BVLC/caffe/tree/windows.
Then, after copying C:\Projects\caffe\python\caffe folder to my Python site_packages folder, I can use "import caffe" in Python.
My question is that if I want to use Caffe on other computers without building Caffe from the beginning, do I just need to copy the files in C:\Projects\caffe\python\caffe folder to the other computers' site_packages folder?
Actually, I am not familiar with 'build' and 'compile' and I don't know what 'build' is doing during the Caffe installation.
You can do the copy provided that the destination computer uses the same support libraries (for software linkage to your Python and Caffe) and has bit-compatible hardware (to support the binary code).
I do this regularly, within a controlled cluster. All the nodes have the same OS configuration. I build on one node, and then copy the entire directory to the same place on the other nodes. Then I run multi-node applications on the result.
If you switch to a different core processor, or a different OS implementation, your attempts to use the result will likely crash. I've tried that one, too. :-)
Related
I need to build Activestate TCL for Ubuntu 18.04 with memory option enabled, "--enable-symbols=mem flag to the configure script" but there is no configure script in my download, only these, which don't have a "configure" line in them.
license-at8.6-thread.
update_check
komodo_download
payload
README-8.6-thread.txt
pdemos
install_welcome.txt
install.tcl
install.sh
install_lib.tcl
install_images
MANIFEST_at8.6.txt
install_data.tcl
Can someone describe how to add the switch described above for Ubuntu?
.
In order to set the mem option, you'll need to compile Tcl from source. To do that you'll need to get a C build chain (especially a C compiler such as gcc or clang, and make to act as a build orchestrator) and the Tcl (and Tk) source code for the version you want to build. The official location for releases of Tcl sources is on SourceForge:
https://sourceforge.net/projects/tcl/files/Tcl/
Pick the version you need and the download package you prefer (ZIP or compressed Tar archive).
Once you've downloaded and unpacked the Tcl code, change into the appropriate directory within the distribution (e.g., unix for Linux builds) and run the configure script inside; it's that script that you pass the --enable-symbols=mem option to.
ActiveTcl is essentially built the same way (except without symbols at all; it's a production distribution after all). It's main distinguishing feature is that it is set up with access to lots of extra packages to go with it. The same goes for most Linux distributions' own tcl packages. They're all production distributions and aren't configured for memory debugging precisely because that adds a lot of overhead to the code (both time and space).
I have installed gulp-imagemin on my Windows 7 laptop using
npm install --save-dev gulp-imagemin
and after a lengthy process ended up with a folder with well over 10,000 files and some very deep folder structures. Has anyone else seen this? Is it likely to be correct or would I be right in suspecting an issue?
Yes it is correct. I've installed it too on my Windows machine and I saw the same thing as you describe here.
The reason it has over 10,000 files and an even more lengthier directory structure is the nature of node modules.
Each and every node module is self containing and has a sub directory node_modules with all it's dependencies. Those dependencies have dependencies as well, resulting in a very deep directory structure.
When I try to remove gulp-imagemin, Windows is even complaining that the directory structure is too large and that it cannot remove certain files. This is because of the MAX_PATH length of 260 characters; see msdn.microsoft.com.
Nevertheless I really, really like this node module and I'm using it in every front end project I work on. Sometimes it takes 2 tries to install it, but I think it's definitely worth it.
On GitHub I have a starter application for working with single page applications; skeletonSPA in which I use it too.
I'm trying to create packages for some robot controller code that will support different architectures, such as i386 and armhf (for Raspberry Pi). I don't know how Debian intends this to be done. Is there a way to create a single .deb package that contains both binaries? Or must I create a separate .deb package for each architecture, which I do know how to do?
In the latter case, if I give the two packages the same package name, I can't put them both in the same repository, but if they have different names, users will have to specify which package they want to install using apt-get. Is there a solution to this problem?
You need to have different binary packages for different architectures unless what you're packaging is interpreted and not compiled.
If the package you're making is compatible with all architectures, then the Architecture: field of your debian/control file must be any. This is telling you that the package can be built in any Debian supported architecture. Then you'll just compile it and cross-compile it to i386 and armhf.
About your second question, you can. In fact, this is how is done in the official Debian repositories. The binary packages have a suffix in the file name containing the architecture. See this example. When users install your package, they won't need to specify the architecture as it's automatically detected.
I created .exe file from .jar file .Now my client demands to run the application without installing jre in the sytem.I have heard that with bundled jre it is possible ...but i dont know how to bundle jre with .exe file..
The JavaFX is working on this. Here are the up-coming features in Java SE 7 u10:
https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7#3
https://blogs.oracle.com/talkingjavadeployment/entry/packaging_improvements_in_jdk_7
I have used VMware ThinApp to do exactly what you are trying to do. It does cost money, but works extremely well. It allows you to roll up all the dependencies your application uses into a single executable that can then run on vanilla installations of Windows. It can be used for a lot more than just Java, and it does so by recording the changes you make to a system after installing your application + the JRE for example, and then wraps up all of those changes. It certainly simplifies application deployment, since the applications are now portable. I've even used it to roll up Visual C++ redistributables, and .NET as well. This certainly increases the size of the executable, but it's also convenient knowing the application will run successfully. See more info at http://www.vmware.com/products/thinapp/overview.html.
The open source Launch4j allows you to produce an exe with an embedded JRE. This SO article also discusses this topic. Caveat: I've had very good success with Launch4j, but never used the embedded JRE feature.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.