I am trying to use the Dafny-to-Python compiler that is suggested in Dafny's reference (25.7.7): http://dafny.org/dafny/DafnyRef/DafnyRef.html#2577-python
However, I cannot run the first step for it in the terminal: dafny build --target:py A.dfy, since I get the error: Dafny: Error: unknown switch: --target. I use Use /help for available options as they suggest, but have no idea on how to solve.
Just in case, I also attempted using the old version of the command (see 25.8.11. in the same reference): dafny Hello.dfy -compileTarget:py but then got message Dafny: Error: Invalid argument "py" to option compileTarget.
Any idea? Note that the authors themselves clearly state that The Dafny-to-Python compiler is still under development.
PS: I usually use Dafny in Visual Studio and not in the terminal, so maybe I lack some kind of library or something.
Neither the new CLI nor the Python compiler are supported by the very outdated version of Dafny you are using. You are presumably not using the correct VS Code extension, so I would start there. As of today, this should install 3.10.0 at /Users/$USER/.vscode/extensions/dafny-lang.ide-vscode-3.0.3/out/resources/3.10.0/github/dafny/Dafny.dll. To see how to use the dll, try hitting F5 with a Dafny file opened in VS Code. The Python compiler is complete and passes all tests these days.
Related
I have installed all Dsharp Packages in Delphi XE. But when I run the example, I always get the following error message:
Exception: Patching : ObjAuto.GetTypeSize failed. Do you have set a breakpoint in the method?
Has anybody found a workaround for this error?
The library is trying to apply a runtime code patch to fix a defect in the ObjAuto.GetTypeSize RTL function. The code that does this can be seen here: https://bitbucket.org/sglienke/dsharp/src/ad7c5983505f0117f1347f92d2bb96c07bdfda94/Source/Core/ObjAutoPatch.pas?at=master&fileviewer=file-view-default
The call to FindMethodBytes fails. Because this function is about to modify the executing code to install the runtime patch, it first checks that the code is as it expects it to be. It searches through the code looking for a known signature for that function.
That signature cannot be found and the patch therefore cannot be installed. Hence the error message. Some possible reasons for the patch code failing in this way:
A breakpoint is set in this code. Breakpoints are implemented by temporarily modifying the code to contain breakpoint instructions.
You are compiling and linking against your own modified version of the RTL. Because of this, the function signature is different.
Another unit in your program is also patching this same function, and the second attempt to patch fails for obvious reasons.
You are using debug DCUs that have a different signature from the standard DCUs.
There is a defect in the DSharp code. Perhaps an erroneous signature, that was not tested on your version of the Delphi RTL. That's not very likely. Perhaps you have installed a hotfix or Delphi update that has not been tested by Stefan. Or perhaps you have not installed a hotfix or update that you are expected to have installed. Maybe the linker has stripped so much code (or so little) that the signature search fails.
And the issue could be due to some other reason that I've not yet thought of. Fundamentally, though, these are all variants on the same theme. The code encountered at runtime is not as expected. I do recommend that you try to find out why so that you can determine how best to proceed.
Given that there are so many possible causes for this message, I've simply tried to explain the conceptual reason for it, but now it's really over to you to debug the specifics in your environment.
I'm trying to build Premake5 on FreeBSD 10.1 from the sources. I eventually got it to compile by removing the "-dl" option and using gmake explicitly for the build. It built, but I can't get it to do anything but spit out the following error message. Doesn't matter how I invoke it. It crashes even on 'premake5 --help'.
Here's the message:
PANIC: unprotected error in call to Lua API (attempt to call a string value)
The code is buggy as all get-out. It starts by assuming linux is posix which is clearly not the case. They use linuxism all over the place so converting to posix is going to be quite a task, and until that is done it will never work satisfactorily on non-linux posix based systems.
The -ldl was obviously the first stumbling block. The next is in the function premake_locate_executable in premake.c. In this they are using the /proc filesystem which is a linuxism and since this fails on BSD they are falling back to some lua methods but they seem to be assuming that lua_tostring pops the corresponding value which it doesn't. Since their stack isn't balanced in this function the following lua_call is trying to call the garbage they've left on the stack rather than the function they intended.
Even after I fixed this issue they use getconf _NPROCESSORS_ONLN to get the number of cores to multi-job the make build but they don't actually check that this call succeeds (which it doesn't outside of Linux and MacOSX).
After fixing this issue I then ran into the problem that their makefiles aren't regular make, but GNU-make, so I had to change to using gmake to try and build.
From that point it just came unravelled because none of the premake files in the contrib directory are configured for BSD despite it being one of the legal configuration targets (i.e. it doesn't default to linux) and so there is no configuration for those components.
TLDR: BSD is not a supported platform
The following F# fragment seems to be valid only if compiled in ML compatibility mode (run it here):
let i = (1 lxor 5)
However I can't compile it in a trivial project in Visual Studio 2012 or using fsc.exe from the command line. I get the error:
error FS0039: The value or constructor 'lxor' is not defined
Reading the F# spec it says
Although F# reserves several OCaml keywords for future use, the /mlcompatibility option enables the use of these keywords as identifiers.
It then lists lxor as one such operator. So I tried the command line fsc.exe Program.fs --mlcompatibility (version 11.0.60610.1), but it stil get the same error.
The documentation for fsc.exe seems to indicate that the mlcompatbility option only ignores warnings. I didn't see any other relevant options in fsc's documentation or project options in VS to enable compatibility.
All of the other SO questions about F#/ML compatibility seem to be related to which language constructs can be used, but all I'm looking for is how to actually compile in compatibility mode. Do I have to open a specific namespace, reference another assembly, or do something else?
Update
I have also tried using the open source compiler fsharpc (F# 3.0) on Mono on Ubuntu 13.04. The result is the same as fsc.
The --mlcompatibility option only turns off warnings, so this looks like a regression. YOu can verify this by searching the source for all references to mlcompatibility here https://github.com/fsharp/fsharp/search?q=mlCompatibility&type=Code.
When calling fsc (fsharpc on non-Windows systems), the compiler options go before the source filenames. So the correct way to call it would be something like:
fsc -o:MyProgram.exe --mlcompatibility Program.fs
When compiling with Visual Studio, you can go into the project's properties and add --mlcompatibility to the Other flags box:
I'm interested in playing around with the MaxSAT/MaxSMT c example (specifically, maxsat.c) provided on the z3 (Microsoft Research) website. Using Visual Studio 2010, I eventually got the example to compile (using a fresh install of z3 4.0). However, I can't get any of my (SMT 2.0) models to run using them. Further, I cannot get the example posted in this question to work either.
In the first case, my compiled program crashes when it tries to call Z3_get_smtlib_num_formulas in get_hard_constraints of the file. I don't know why, instead, I get the standard windows 7 "this program has stopped working" popup.
In the second case, it reports unsupported ;benchmark.
In order to help me to get this work, I was wondering if
(a) Has anyone had similar issues when compiling this code, and if so, how did you resolve them?
or
(b) How can I debug either compilation of the file (assuming it is correct)? Namely, can someone enumerate the correct libraries (and library versions - e.g., z3 4.0?) to include in the compiler options to get this example working?
In either case, information on the error reported in the second case would also be appreciated: what does it mean exactly? The keyword was not valid? That the SMT input is the wrong version? Or something else?
Thanks.
The MaxSAT example has not been updated to SMTLIB 2.0 yet. It uses the function Z3_parse_smtlib_file to parse the input, which means that it supports only SMTLIB 1.0 at the moment.
This example is distributed alongside Z3, i.e., you should have received a copy in Z3-4.0/examples/maxsat/, which also contains compilation and execution scripts.
Compilation should be straight-forward by running build.cmd in a Visual Studio Command Prompt, or build.sh on Linux.
I may have this completely wrong, but my understanding is that the --standalone compiler option tells the compiler to include the F# core and other dependencies in the exe, so that you can run it on another machine without installing any 'runtime'.
However, I can't get this to work in the CTP - it doesn't even seem to change the size of the output file (docs I've read say about 1M extra).
"Google may know, but if it does, it ain't telling, or I'm not looking in the right place"
UPDATE:
It seems to work with latest CTP update 1.9.6.2
UPDATE2:
I have since experienced another error:
FSC(0,0): error FS0191: could not resolve assembly Microsoft.Build.Utilities.
If you get errors like this when trying to compile --standalone, you need to explicitly include them as references in your project.
Answer from MS:
There is a CTP update 1.9.6.2 that fixed some --standalone bugs.
I'm reinstalling now...
UPDATE:
Works for me - so the my accepted answer is download CTP update 1.9.6.2.
F# manual: Statically linking the F# library using "--standalone"
Did you try to run peverify.exe utility?
This has been a pet hatred of mine for a long time (it has been broken in every CTP release ever including the latest 1.9.6.16 May 2009 release). The "solution" is essentially to write your own build system that is not broken.
This is a real problem for me because I have accumulated hundreds of great F# programs that I would like to put on our site but it takes hours to build each one into a standalone executable.