Is it possible to get Z3 running on a system providing posix API without having python installed?
I have seen the new version 4.3 uses python already in the build-process (scripts/mk_make.py).
Whats about older versions like 4.1? Is it imaginable to get it to run on posix without python?
Is Python not available in your system?
Python was always used to automatically generate some parts of the Z3 code base. In the first source code release, we have included the automatically generated code. Actually, at that time, we were using a combination of python + sed + awk + grep to generate these parts of the code. Another problem with the first release is that the build system for Windows (+ Visual Studio) was completely different from the build system for the other platforms. The Makefiles for Linux and OSX were derived from Visual Studio Project files. Some users also started to report problems with the build system for Linux and OSX. So, to reduce these problems and have a uniform build system, we decided to use python (and python only) to:
Automatically generate code (for bindings for different languages, API logging support, etc)
Check the system for requirements
Generate the Makefiles
And any other form of automation
Python is very attractive for us because it works in most systems (even non posix compliant ones). We can easily write portable scripts. Moreover, after we made the switch, we can compile Z3 in more platforms. We successfully compiled it on Windows, Linux (Mint, Ubuntu, Suse, etc), OSX, Cygwin, and FreeBSD.
In the "unstable" (aka working-in-progress) branch, we don't even require autoconf anymore, we use python to do all system specific configuration. To build Z3, we just need: python, C++ compiler (Visual Studio C++, g++ or clang++), ar (on non-windows platform), make (or nmake). This is very small set of requirements. Python is available in most platforms by default.
That being said, is it possible to remove the python requirement? Yes, it is, but it would have to replace python with something else. Something, that would allows us to perform all tasks described above. Take a look in the directory scripts at http://z3.codeplex.com/SourceControl/changeset/view/0c1f2a82818a,
we would have to port all these automation scripts to something that can be used on all platforms we support.
Related
I was wondering If any one could help me to understand the difference of python virtual environment and docker container.
So I would like to have environment for each tools isolating from each other to avoid dependency conflict for example: use of different version of same dependency causing error in one of the tool because one tool need older version and other one requires newer version.
I’m tested out python venv but not sure if it’s the right one I should use for the issue I just explained or docker is something I should be using for my situation?.
Particularly for day-to-day development, prefer a virtual environment if it's practical.
Virtual environment
Docker
Works with native tools; can just run python myscript.py
Requires Docker-specific setup
Every IDE and editor works fine with it
Requires Docker-specific IDE support
Can just open() data files with no special setup
Can't access data files without Docker-specific mount setup
Immediately re-run code after editing it
Re docker build image or use Docker-specific mount setup
Uses Python installation from host
Use any single specific version of Python
Isolated Python library tree
Isolated Python library tree
Uses host version of C library dependencies
Isolated C library dependencies
A virtual environment acts like a normal Python installation in an alternate path. You don't need to do special things to make your local code or data files available; you can just run your script directly or via your IDE. The one downside is that you're limited to what your host OS's package manager makes available for Python versions and C library dependencies.
A Docker container contains the filesystem of a complete OS, including a completely isolated Python installation. It can be a good match if you need a very specific version of Python or if you need host OS dependencies that are tricky to install. It can also be a good match if you're looking for a production-oriented deployment setup that doesn't specifically depend on installing things on to the target system. But, Docker by design makes it hard to access your host files; it is not a great match for a live development environment or especially for one-off scripts that read and write host files.
The other consideration here is, if you use the standard Python packaging tools, it's straightforward to run your program in a virtual environment, and converting that to a Docker image is almost boilerplate. Starting from Docker can make it tricky to go back the other way, and I see some setups around SO that can only be run via Docker; if they were restructured to use a standard setup.cfg/requirements.txt installation setup they would not require Docker but could still be used with it.
I have a private server that I've been slowly setting up for personal projects, but I've run into a bit of a roadblock. My server is running Arch linux [I like bleeding edge and minimalistic installs in situations like this] and I have Jenkins running on it so that I can have it automatically build projects. I have a project that I've been working on that is currently targeting the Win32/64 platform using MSVC, but I can't seem to find any info anywhere about setting up a job on Jenkins for this situation. I was hoping that I could maybe setup a Docker instance that would be able to provide the MSVC toolchain, especially since Visual Studio Code is available for Linux, and that I could use that as part of my Jenkins setup to generate Win binaries for me to test on my main machine. I mention this because naturally, Visual Studio is not a command line utility, and currently my server is a pure headless setup that only provides cli interaction, so if possible, I would like to avoid directly adding GUI packages to the server, but if it is the only way, I'd be willing to do so. Is there really no way to achieve what I'm going for with this?
Sorry if this lacks important details or is formatted poorly, this is my first time asking a question here as it's very rare for me to not be able to find the info I'm looking for in an already existing question.
After research, this is not currently possible as it stems from a misunderstanding of exactly what docker provides. Docker simply uses the underlying OS to provide everything and does not provide any virtualization of foreign OSs. Without a version of the MSVC toolchain that can run on linux, or possibly the use of WINE, there is not a way to achieve this short of a VM. Since WINE is not perfect, the most reliable solution as it appears to me is the VM, but YMMV. The other advantage to using a VM is that I can keep the server headless.
I can't answer this question completely, but this topic is interesting to me too.
Note: Visual Studio Code is open-source, but that's an Electron-based editor. Visual Studio IDE and MSVC are proprietary Windows-only apps.
The website https://blog.sixeyed.com/how-to-dockerize-windows-applications/ suggests it's possible to dockerize Windows apps, including Visual Studio.
Docker images for Windows apps need to be based on microsoft/nanoserver or microsoft/windowsservercore, or on another image based on one of those.
Once you get that working, I'd use Visual Studio command-line builds, like devenv /build file.sln [optionally /project file.vcxproj ]. (https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches?view=vs-2017 ).
Note that the VS2017 installer does not function on Wine. I recently filed a bug for this (https://bugs.winehq.org/show_bug.cgi?id=45749 followed by https://bugs.winehq.org/show_bug.cgi?id=45757 ).
I personally use Appveyor for auto-building MSVC apps. Appveyor is a Windows-based centralized cloud service, not a self-hosted CI system.
In the past I have used environment modules extensively in Unix based systems. The tool proved very usefull since we had many different projects each of them using a potentially different set of tools.
I am now however stuck with a windows machine and need to make the most of it. Does anybody know of a good alternative to environment modules for windows? I am basically looking for a tool that let's me manipulate the PATH (or $env:PATH in windows powershell) environment variable without having to touch it directly.
You can install environment modules on windows as well. The instructions are in the repository https://github.com/cea-hpc/modules/blob/master/INSTALL-win.txt
Basically you have to install active state tcl and copy the source files.
I use this and it works quite well.
Torch is a scientific computing framework with wide support for machine learning algorithms. It is easy to use and efficient, thanks to an easy and fast scripting language, LuaJIT, and an underlying C/CUDA implementation.
Q:
Is there a way to install torch on MS Windows 8.1?
I got it installed and running on Windows (although not 8.1, but I don't expect the process to be different) following instructions in this repository; it's now deprecated, but wasn't deprecated few months ago when I built it. The new instructions point to torch/torch7 repository, but it has a different structure and I haven't been able to build it on Windows yet.
There are instructions on how to install Torch7 from luarocks, but you may run into issues on windows as well; I haven't tried this process. It seems like there is no official support for Windows yet, but some work is being done by contributors (there is a link to a pull request in that thread).
Based on my experience, compiling that deprecated repo may be your best option on Windows at the moment.
Update (7/9/2015): I've recently submitted several changes that fix compilation issues with mingw, so you may try the most recent version of torch7 and follow the build instructions in the ticket. Note that the changes only apply to the core lib and additional libraries may need similar changes.
This webpage hosted by New York University recommends installing a Linux virtual machine in order to run Torch7 on Windows through Linux. Another option would off course be to install a Linux dist in parallel with Windows 8.
Otherwise, if you don't mind running an older version of Torch, there is a Windows installer for Torch5 at SourceForge.
I think to use a GPU from inside the virtual machine, the processor and the motherboard should not only support VT-x , but VT-d should be supported too.
But the question is, if I use a CPU with VT-d supported, do you think there will be a significant loss in PCIe connections efficiency?
From what I understand,
VT-d is important if I want to give the virtual machines direct access to my hardware components (like PCI Express cards). Like directly attach graphics card to vm instead of host machine. Isn't that mean that the PCIe connections efficiency will be the same just like if it was the host?
I have Python 2.7 installed in "C:\Python27". Now I run 1st demo of Python4delphi with D7, which somehow uses my Py2.7 install folder. If I rename Python folder, demo can't run (without error message). I didn't change properties of a demo form.
What part/file does py4delphi use from my Python folder?
python4delphi is a loose wrapper around the Python API and as such relies on a functioning Python installation. Typically on Windows this comprises at least the following:
The main Python directory. On your system this is C:\Python27.
The Python DLL which is python27.dll and lives in your system directory.
Registry settings that indicate where your Python directory is installed.
When you rename the Python directory, the registry settings refer to a location that no longer exists. And so the failure you observe is entirely to be expected.
Perhaps you are trying to work out how to deploy your application in a self-contained way without requiring an external dependency on a Python installation. If so, then I suggest you look in to one of the portable Python distributions. You may need to adapt python4delphi a little to find the Python DLL which will be located under your application's directory. But that should be all that's needed. Take care of the licensing issues too if you do distribute Python with your application.