I installed Windows 10 (64bit). Since then, Isabelle HOL is no longer starting, even after a re-installation (which ran through smoothly). The error message is the following: "Startup Error: Error starting Java VM". This happens with the two versions I tested (2013-2 and 2015).
The jvm.dll which is specified in the configuration file, exists in the right folder. Additionally, I have installed Java SDK in newest version (8.51) in both, 32bit and 64bit.
Is there a known compatibility problem with Windows 10? Isabelle used to work with Windows 7 and 8.
Thank you for you help.
Update (150822)
From the developer's mailing list, there's a link to a test release:
NEWS: updated to jdk-8u60, with support for x86_64-windows
www4.in.tum.de/~wenzelm/test/Isabelle_21-Aug-2015
That's working different from Isabelle2015, in how it does some things with paths, so it might find the things it needs for Windows 10, or it may not. However, even if it works, there may be some incompatibilities with Isabelle2015 (in theorem proving).
Regardless, Isabelle only gets released 1 to 2 times a year, and I wouldn't expect anything special to be released for Windows 10 within 4 to 6 months. The links above, though, show that M.Wenzel can package together a test release, but he mainly operates on the user's mailing list.
In my batch file below, I set HOMEDRIVE and HOMEPATH, which you don't need if you want .isabelle to be in C:\user.
In this test release, those settings don't affect my home path. It also appears that USER_HOME is used, though my setting of USER_HOME doesn't make my batch file work for this test release.
Anyway, this test release has changed the way it works to discover things, and accomodates Windows even more, as shown by the new behaviour of the function File.platform_path.
It's working different enough, and requires enough changes, that I should stay with Isabelle2015, or I'll be out of sync with the official release.)
Original
(Zeroeth: Problems like this generally get hashed out on the mailing list, but I go ahead show you how I start Isabelle using a batch file, which I started doing before I had to start doing it.)
First, the Java that Isabelle uses is in this folder:
Isabelle2015\contrib\jdk\x86-cygwin\jre
Doing a normal Java install for Windows is not going to change which Java that Isabelle uses.
Below, I give you a batch file and bash file to start Isabelle/jEdit, which is an alternative to using Isabelle2015\Isabelle2015.exe.
For myself, what I've done is manually replace the 32-bit jre folder shown above with the jre in jre-8u45-windows-x64.tar.gz. (I renamed the old 32-bit folder. The most recent Java tar files can be found at the download page.)
Consequently, if I try to start up Isabelle with Isabelle2015.exe, I also get a popup that says, "Startup Error, Error starting Java VM", but starting Isabelle with the batch/bash combination works for me on Windows 8.1.
What I show you below may not fix your problem, but I guess Isabelle2015.exe has to get some info from the OS to work right, and maybe that's changed with Windows 10:
https://lists.cam.ac.uk/mailman/htdig/cl-isabelle-users/2014-December/msg00033.html
You put the batch and bash file below in the folder that you have or want your .isabelle folder. Change ISAHOME below to where your Isabelle distribution is. PATH needs the Cygwin bin in the path, and the path for isabelle, which I set in the batch file.
FILE: start-isabelle.bat
:: Isabelle2015.exe uses these directly. Setting HOME or USER_HOME doesn't work
set HOMEDRIVE=%~d0
set HOMEPATH=%~p0
:: Cygwin uses HOME, and this is how HOME is set in Cygwin-Terminal.bat
set HOME=%HOMEDRIVE%%HOMEPATH%
:: ADD PATHS: 'cygwin/bin' to start terminal, 'Isabelle2015/bin' for 'isabelle'
set ISAHOME=E:\E_2\d ev\Isabelle2015
set PATH=%PATH%;%ISAHOME%/contrib/cygwin/bin;%ISAHOME%/bin;
set CHERE_INVOKING=true
::MINTTY CONSOLE
start /MIN mintty.exe -i /Cygwin-Terminal.ico "%~dp0start-isabelle.bash"
:: REGULAR WINDOWS CONSOLE
::bash --login -i "%~dp0start-isabelle.bash"
FILE: start-isabelle.bash
#!/usr/bin/env bash
#
isabelle jedit -l HOL
With 64-bit Java, I can increase the size of the memory that Isabelle uses, by making this change in .isabelle\Isabelle2015\etc\settings:
JEDIT_JAVA_OPTIONS="-Xms1g -Xmx4g -Xss4m"
or
JEDIT_JAVA_OPTIONS="-Xms1024m -Xmx4096m -Xss4m"
With 32-bit Java, when I do that, Isabelle will start but then terminate.
Related
On its website OpenFlipper says it can be compiled in three steps as:
cd build
cmake ..
make # or, even better, make -j8
However I get an error saying Qt is unable to be found at the cmake step and that I should specify a QT5_INSTALL_PATH. However even if I do this OpenFlipper is still issuing the same complaint!
You are not supposed to specify where Qt is installed in the QT5_INSTALLED_DIR but prior to that as environment variable in your terminal:
# assuming Qt was installed in your home directory, as is default
export CMAKE_PREFIX_PATH=~/Qt5.7.0/5.7/gcc_64/
# note that you now have to call cmake etc from that process
Compiling and running it after that you might get errors telling you GL_ARB_vertex_buffer_object is not present, even if your glxinfo | grep ARB_vertex_buffer is telling you it is.* Clicking "Ignore" results in a crash. To mitigate this, you have to manually change (4,3) to (3,0) in
OpenFlipper/widgets/coreWidget/CoreWidget.cc
If you still experience errors, try deleting your cmake cache, this is accomplished by using cmake-gui (was in the package cmake-qt-gui for me) and hitting "Delete Cache"
(optional) remove the very annoying warning message you get at every start of OpenFlipper by removing the line concerning "renderers shipped" in
OpenFlipper/Core/Core.cc
*: My teaching assistant told me that there is a bug in Qt (<5.9) that forces OpenFlipper to use the OpenGL Compatibility Profile. Additionally Intel and AMD drivers hand back an OpenGL 3.0 Core Context when asked for an OpenGL 4.3 Compatibility Context (my TA described this behavior as a "bug", I'm not so sure about this), leading to a crash in Qt. So this should be resolved in Qt 5.9 (not out yet). This seems to affect also mainly integrated graphics, so one could try using a dedicated GPU.
When running the checks for my R-package (via devtools::check()) I face the warning ''qpdf' is needed for checks on size reduction of PDFs. I found this question were it was suggested (if I understood the answer correctly) to run Sys.which(Sys.getenv("R_QPDF", "qpdf")) and see whether qpdf is found or not. In my case this just returns
qpdf
""
so, I think I didn't install qpdf correctly. Unfortunately it seems to be quite complicated to install qpdf on Windows. My first side question is: does it really is so painful and complicated to install qpdf for Windows or is there an easy solution?
I've followed the instructions until it is said to add C:\MinGW-w64\bin and C:\MinGW-w64\lib\mingw to the PATH variable. But then I don't find further specific instructions to install qpdf, only about how to build qpdf with different other programs. The second side question is: is my assumption correct that after I've build qpdf it is installed? But the real question is: What is the best way to build qpdf? I tried the ./config-mingw32 and ./config-mingw64 commands from the section "Building with MinGW" in my C:\MinGW\msys\1.0\bin\bash.exe but got the error messages ./config-mingw32: No such file or directory and have no idea how to fix this issue.
I'm using Windows 10, R version 3.3.2 Patched (2017-01-07 r71934) -- "Sincere Pumpkin Patch" and RStudio 1.0.136.
You basically do not need to build the file on windows. Please follow three steps below:
Download qpdf for windows from https://sourceforge.net/projects/qpdf/?source=typ_redirect
Extract files in a temp folder
Copy the contents of the bin folder to %SystemRoot%\System32
job done!
Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"C:\\WINDOWS\\SYSTEM32\\qpdf.exe"
To flesh out an answer provided elsewhere:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 10.0.1 is listed here).
Rather than copying files to C:/Windows/System32, a potentially safer option is to extracted the zipped qpdf directory to C:\Program Files. If you do this, you'll need to add C:\Program Files\qpdf-version_number\bin to your system PATH under the environment variables.
To do this within R, run Sys.setenv('PATH' = paste0('C:\Program Files\qpdf-version_numer\bin;', Sys.getenv('PATH')))
To do this in Windows, open the start menu, type "edit the system environment variables" to open the System Properties, and at the bottom of the "Advanced" tab click "Environment variables". Find the "Path" entry under "System variables" and click "Edit". Then, re-start R so it picks up the modified PATH.
One further step may be required to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning, as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. This done, Windows will recognize the file as safe to run and allow other software, including R, to use it.
I recently upgraded to Architect version 0.9.7 on my Win 7 machine. However, after starting Architect, the RJ console wouldn't launch and I got the error message:
‘Launching the R Console was cancelled, because It seems starting the R engine failed.”
Please make sure that R package 'rj' (2.0 or compatible) is installed and
that the R library paths are set correctly for the R environment
configuration 'Embedded R Server'.
I installed the packages ‘rj’ and ‘rj.gd’ through the RTerm run console (which does happen to work) within Architect using the command suggested on www.walware.de:
install.packages(c("rj", "rj.gd"), repos="http://download.walware.de/rj-2.0")
Then, I restarted windows, and restarted Architect. Same error message. I zoomed in on the details of the error message and noticed the following line:
SEVERE: Path to rj package not found. Use R_LIBS or java property
'de.walware.rj.rpkg.path' to specify the location.
So I opened an RTerm run console to check whether any of my .libPaths() locations contains the directories ‘rj’ or ‘rj.gd’. Oddly enough, they do. My first .libPaths path contains both packages. So that doesn’t seem to be the reason.
How could this be fixed?
I received prompt and helpful feedback from Open Analytics (thanks!), who informed me that the problem is due to changes in Java 8. With Java 7, Architect works fine. The next release of Architect will incorporate the changes in Java 8.
In order to get it work with Java 7, enforce the use of a specific Java Runtime, by using the -vm argument in the architect.ini file as follows:
-vm
C:\Program Files\Java\jre7\bin\javaw.exe
(mind the line break, which is required)
This is particularly useful if you have several Java versions on your system where the default Java is not suitable for use with Architect. The architect.ini file is found directly at the top level of the installation folder of Architect. You can find out where this is by looking at the Properties of the Architect shortcut on your desktop.
N.B. the -vm argument should be put before the -vmargs argument otherwise it is simply ignored!
N.B. examples of -vm specification on GNU/Linux and Mac OS X:
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Linux_Example
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Mac_OS_X_Example
I use vim for C++ code editing. But its code completion isn't so good (although I have tried many plugins, such as OmniCppComplete). The Qt Creator code completion is awesome, and it also has vim style editing which functionality is full enough for me. Only thing that isn't so good for me is that I cannot use ctags functionality inside Qt Creator (although Qt Creator has functionality to go to class definition, but it takes a lot more time to parse the source code).
Is it possible to create the source code tag file and use it with in Qt Creator in fake vim mode?
Code completion for C++ in Vim is actually superior. I'll outline the steps you have to take in order to make it work. However, I won't go into much detail here (such as building huge open-source code base, cloning a repository, installing plugins for Vim, etc.) because otherwise it would be worth writing a large tutorial for novices. So, assuming that you are well-aware and well-prepared software developer, there you go a fluent guide:
Get and install clang_complete (plugin for Vim);
Get and install neocomplcache (plugin for Vim);
If you are on Unix, then you are lucky because you probably have LLVM and Clang either installed on your system already or you have to use package manager and install them with a single command. If so, then you can immediately jump to the last step (#7).
If you are on Windows, then you are less lucky, but that's actually better from the practical point of view - you'll have a great experience of building huge stuff on your own and getting things to work no matter what. :)
So, if you're on Windows (and using Qt Creator as I can see), then you might have MinGW already installed on your system. If that's not the case, then I strongly suggest that you to install a bleeding-edge MinGW-w64. Fortunately, you don't have to compile it yourself as rubenvb has kindly built MinGW-w64 toolchain in both variants: targeting 64-bit Windows (aka x64) and targeting 32-bit Windows (aka x86). Just download one depending on your OS. NOTE: These links are pointing to the latest (at the time of writing this answer) stable builds of MinGW-w64, i.e. based on GCC 4.7.2. IMPORTANT: Make sure that MinGW-w64 is in the %PATH% environment variable.
Another piece of software needed is CMake (a popular build system). Again, if you are on Unix it might be installed already. If you are on Windows, then just download and install it. IMPORTANT: Make sure that CMake is in the %PATH% environment variable.
The last thing we'll need is Python. Once again, if you are on Unix, then it is already installed on your system. Otherwise, you know what to do already. :) Officially, there are 2 versions of Python: 2.7.3 and 3.x.x - you should definitely download and install both. Python is an essential piece of software on any developer's machine. IMPORTANT: Make sure that Python 2.7.3 (not 3.x.x!) is in the %PATH% environment variable.
Now that we have MinGW-w64, CMake, Python installed, we are ready to build LLVM and Clang. To ease the pain go to my Out-of-Source Builders project and scroll down to Guide: Build 64-bit LLVM and Clang for Windows (64-bit) Using MinGW-w64. If you are on 32-bit Windows, don't pay attention to 64-bit (it does not matter) in the title, just follow the instructions there. Wait for about an hour until LLVM and Clang are built.
We are almost done, all that is left is to configure Vim properly. Here I'll simply provide my configuration which would most likely satisfy your needs.
Configure neocomplcache:
let g:neocomplcache_enable_at_startup = 1
let g:neocomplcache_enable_smart_case = 1
let g:neocomplcache_enable_camel_case_completion = 1
let g:neocomplcache_enable_underbar_completion = 1
let g:neocomplcache_min_syntax_length = 2
if !exists('g:neocomplcache_force_omni_patterns')
let g:neocomplcache_force_omni_patterns = {}
endif
let g:neocomplcache_force_overwrite_completefunc = 1
let g:neocomplcache_force_omni_patterns.c = '[^.[:digit:] *\t]\%(\.\|->\)'
let g:neocomplcache_force_omni_patterns.cpp = '[^.[:digit:] *\t]\%(\.\|->\)'
\ . '\|\h\w*::'
let g:neocomplcache_force_omni_patterns.objc = '[^.[:digit:] *\t]\%(\.\|->\)'
\ . '\|\h\w*::'
let g:neocomplcache_force_omni_patterns.objcpp = '[^.[:digit:] *\t]\%(\.\|->\)'
\ . '\|\h\w*::'
inoremap <expr> <Tab> pumvisible() ? "\<C-n>" : "\<Tab>"
inoremap <expr> <S-Tab> pumvisible() ? "\<C-p>" : "\<S-Tab>"
Configure clang_complete:
let g:clang_use_library = 1
let g:clang_auto_select = 0
let g:clang_complete_auto = 0
let g:clang_complete_copen = 1
let g:clang_complete_macros = 1
let g:clang_complete_patters = 1
let g:clang_library_path = 'D:/Toolchains/x64/LLVM/3.3/bin'
let g:clang_auto_user_options = 'path, .clang_complete'
For more information on both of these plugins use Vim's help documentation: :h clang_complete and :h neocomplcache. There are lots of options to tweak, especially in neocomplcache. From my point of view both plugins are must have for any C++ developer who uses Vim.
NOTE: If you don't know how to complete some of the steps listed here, you would have to either ask additional questions here on StackOverflow or look elsewhere for the reason described in the beginning of this answer.
I hope this helps and you would favor Vim more for your development efforts from now. :)
I'm trying to build an application from source in windows that requires some Unix tools. I think it's the apparently standard ./configure; make; make install (there's no INSTALL file). First I tried MinGW but got confused that there was no bash, autoconf, m4, or automake exes in \bin. I'm sure I missed something obvious but I installed Cygwin anyways just to move forward. For some reason when I run
sh configure.sh
I get:
platform unix
compiler cc
configuration directory ./builds/unix
configuration rules ./builds/unix/unix.mk
My OS has identity problems. Obviously the makefile is all wrong since I'm not on unix but win32. Why would the configure script think this? I assume it has something to do with Cygwin but if I remove that I can't build it at all. Please help; I'm very confused.
Also is it possible to build using MinGW? What's the command for bash and is mingw32-make the same as make? I noticed they're different sizes.
Everything is fine. When you are inside CygWin, you are basically emulating an UNIX. sh runs inside CygWin, and thus identifies the OS correctly as Unix.
Have a look at GCW - The Gnu C compiler for Windows
Also, you might be interested in this help page, that goes into some detail about the minimal system (MSYS), such as how to install, configure et. c.
That should help you get bash, configure and the rest to work for MinGW as well.
From the Cygwin home page
Cygwin is a Linux-like environment for Windows. It consists of two parts:
A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
A collection of tools which provide Linux look and feel.
Since configure is using the Cygwin environment, it is interacting against the emulation layer and so it is just like it's working on a Unix environment.
Have you tried building the application and seeing if it works?