This is doubtless something obvious, but downloading the F# PowerPack from codeplex and running fshtmldoc produces this error:
clements$ mono ./fshtmldoc.exe FSharp.PowerPack.dll
Processing 'FSharp.PowerPack.dll'...
Unexpected failure while writing HTML docs: An exception was thrown by the type initializer for Microsoft.FSharp.Metadata.AssemblyLoader
This is using mono 2.6.3, F# 2.0 1.9.9.9, & OS X 10.6.3 on a 32-bit intel processor.
Any help would be appreciated.
Many thanks,
John Clements
(repost from powerpack online discussion group--no response there)
At IntelliFactory we are so fed up with fshtmldoc.exe that we started an alternative project:
https://bitbucket.org/IntelliFactory/if-doc
It is still in beta but it quickly approaching being useful. I have not tried it on Mono yet but am interested in supporting it on Mono.
The key difference between our tool and fshtmldoc is that our tool uses Mono.Cecil instead of linking to the assemblies being documented. This means that it does not fail when those assemblies are in a different folder or their references are missing.
Related
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:
Hello I downloaded Z3 from http://z3.codeplex.com/ and then opened the Z3 solution in Visual Studio 2012. (While I'm not totally new to VS I haven't used it in over 10 years). There are 9 projects in this solution but I am having a hard time telling which I ought to be using. I can guess at some of them, but others aren't very clear. Eg. what is the difference between Microsoft.Z3 and Microsoft.Z3V3 ? Can anyone briefly explain what the different projects are and which ones to build?
Anyway just for kicks I tried building the top level solution but got the following errors
Error 1 error RC1015: cannot open include file 'afxres.h'. C:\Projects\z3-src-4.1.2\z3\dll\dll.rc 10 1 dll
Error 2 (same as Error 1 except in shell.rc)
Error 3 error LNK1104: cannot open file 'C:\Projects\z3-src-4.1.2\z3\Debug\z3_dbg.lib' C:\Projects\z3-src-4.1.2\z3\test_capi\LINK test_capi
Trying to build just the MS.Z3 project still gives me Error 1.
My eventual goal is to invoke Z3 from say an F# program. Can someone provide some guidance for how to do this?
Any help would be appreciated.
EDIT
This answer reflects the directory structure used in Z3 version <= 4.1.1. In version 4.3, the code base has been reorganized/simplified.
END EDIT
Which version of Visual Studio are you using? I'm asking because I want to reproduce the behavior you described.
The easiest way to build Z3 is described here.
You should use the Visual Studio Command Prompt, and execute msbuild. It seems you tried that, and got errors. Here is a short description of each project folder:
lib: the Z3 source code is here. This is the important folder. For visual studio users, it generated a static library.
dll: project for wrapping the static library as a Windows DLL. This is irrelevant for users in other platforms.
shell: uses the static library from lib to build z3.exe.
test: a bunch of unit tests. It produces test.exe.
Microsoft.Z3: .Net API. It is the official .Net API (C#, Visual Basic, F#, etc) for Z3. This is the API you should use with F#.
Microsoft.Z3V3: It is the old .NET API. It was the API available in Z3 3.x. We maintain it because some users still use it.
test_capi: Application that tests the Z3 C API.
maxsat: Small application that implements two maxsat algorithms on top of the Z3 API.
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 work with intel parallel studio 2011 and I included:
#include <cilk/cilk.h>
which seemed to be included just fine.
Then I tried using the command:
cilk_spawn (and also _Cilk_spawn)
and got the following error:
Error: identifier "_Cilk_spawn" is undefined.
Does anyone know how to solve this problem?
"Some mysterious problem with the text view which makes look like it is a syntax error" which you refer to in the comment probably means that Microsoft's Intellisense cannot recognize Cilk keywords, which are Intel's extension to C/C++.
I was unable to find any fix or workaround for that, so suggest you ask at Intel's Cilk Plus forum; maybe Intel Parallel Studio can take care of it. Also see a bug report to Microsoft.
When i compiled my application in blackberry it shows the following error.
generics are not supported in -source 1.3
(use -source 5 or higher to enable generics)
how to solve this
Java 1.3 is barbaric and no one should ever have to suffer its indignities. Fortunately, there is a solution!
Generics, enums, changing return signature in overrides, and pretty much everything that makes java usable was introduced in java 1.5. (see http://en.wikipedia.org/wiki/Java_version_history). Fortunately, most of java 1.5 was designed to be backwards compatible and not require JVM / bytecode changes. (or maybe this was unfortunate, as it lead Java's implementation of generics to be much weaker than C#. just try creating a generic class with static methods / fields that use the generic parameter)
This IBM article does a good job of explaining the background:
http://www.ibm.com/developerworks/java/library/j-jtp02277.html
But this JVM similarity allowed for creation of tools such as:
http://retrotranslator.sourceforge.net/
This is the section from my Ant buildfile that calls retrotranslator:
< java jar="${transformer.jar.exe}"
fork="true"
classpath="${epic-framework.dir}/tools/retrotranslator-runtime13-1.2.9.jar:${epic-framework.dir}/tools/retrotranslator-runtime-1.2.9.jar"
args="-srcjar ${build.dir}/classes5.jar -target 1.3 -destjar ${build.dir}/classes5to3.jar"
/>
Run the converted jar through preverify.exe and then give it to rapc.exe and you will have a working Blackberry app written with Java 1.5.
Edit: I missed a key detail in my original post. In addition to being Java 1.3, the Blackberry class hierarchy is missing many classes that would normally be a part of a Java SE 1.3 JDK. The one you will hit first is StringBuilder -- javac transforms ("string" + "otherstr" + "blah blah") into StringBuilder.append("string").append("otherstr").append("blah blah"). That class doesn't exist on BB, so you break. However, BB has StringBuffer, so writing an adapter between the two is pretty easy. The one catch is that BB disallows apps from adding classes into java.*. This can be very effectively fixed in the build process: 1) build your app against Java 1.5 w/ java.lang.StringBuilder on the classpath, 2) string transform java.lang.Stringbuilder (and everything else in your compat shim) to live in com.mycorp.java.lang.StringBuilder and build it into a JAR file. 3) Use that JAR file w/ retrotranslator and retrotranslator will update all bytecode references to java.lang.StringBuilder so that they now point to com.mycorp.java.lang.StringBuilder. Now you have a java 1.3 compatible bytecode that can be run on a Blackberry.
If anyone is interested in this stuff, contact me. I could look into open sourcing the compat library I have.
This is a limitation of J2ME, which uses a subset of the J2SE (no collections, reflection, etc.) and a Java language level of 1.3. Any code written for J2SE will most likely need to be manually ported.
It seems the JDK5 is not yet supported.
Same question was asked on the blackberrry forum but about enum support:
Sadly, the BlackBerry api is very behind in terms of Java versioning. There's no Generics, no Maps, no Enums - it's based around JDK 1.3.
I believe there is no way of enabling this feature within your BlackBerry app. If you find one, I'd be very interested to hear about it.