I'm compiling using the LLVM backend. It can be compiled using the Java backend, but the LLVM backend throws the following error:
Compiler: No fresh generator defined for sort Optional[KVar]
The error highlights the !M in <abs> ... .Map => (!M |-> (T1 -> T2)) ... </abs>
This is a bug in K's implementation of substitution that causes fresh constants of sort KVar to only be available on the java backend. You can track the issue here: https://github.com/kframework/k/issues/1186
We will try to have a fix for the issue soon, as it ought to be straightforward.
Related
I want to fuzz the map loading feature in counter strike. The source code for csgo got leaked a while back and here is a build which you can compile https://github.com/SwagSoftware/Kisak-Strike . However, when I try to compile it using this command:
AFL_USE_ASAN=1 PERSIST=1 cmake -DCMAKE_BUILD_TYPE=Debug -DUSE_ROCKETUI=ON -DFREETYPE_LIBRARY=/usr/lib/x86_64-linux-gnu/libfreetype.so -DFREETYPE_INCLUDE_DIRS=/usr/include/freetype2/freetype/ -DUSE_KISAK_PHYSICS=ON -DCMAKE_C_COMPILER=/home/cyberhacker/Asioita/Hakkerointi/Counterstrikestuff/aflpp/afl-gcc-fastthing/AFLplusplus/afl-gcc-fast -DCMAKE_CXX_COMPILER=/home/cyberhacker/Asioita/Hakkerointi/Counterstrikestuff/aflpp/afl-gcc-fastthing/AFLplusplus/afl-g++-fast ..
and then when i try to run ./csgo_linux64 , it throws this error:
Failed to load the launcher(bin/linux64/launcher_client.so) (/home/cyberhacker/Asioita/Csgocompile/withjump/game/bin/linux64/libtier0_client.so: undefined symbol: __afl_area_ptr)
I am expecting it to just work as usual (same as with the regular build). It works completely fine when I try to compile it normally with this command:
cmake -DCMAKE_BUILD_TYPE=Debug -DUSE_ROCKETUI=ON -DFREETYPE_LIBRARY=/usr/lib/x86_64-linux-gnu/libfreetype.so -DFREETYPE_INCLUDE_DIRS=/usr/include/freetype2/freetype/ -DUSE_KISAK_PHYSICS=ON -DCMAKE_C_COMPILER=/usr/bin/cc -DCMAKE_CXX_COMPILER=/usr/bin/c++ ..
and then make -j8
I searched a bit and found this: this . In that conversation they say that this error can be cause by compiling with afl-gcc but then linking with normal gcc or ld. However this is not the cause of my problem since I have looked through the cmake log files and the binaries are being linked with afl-g++-fast so this shouldn't be a problem in my case. I read somewhere that the libraries should be statically included, not dynamic but I do not think that it is a necessity. Feel free to look at the Kisak strike source code if you want to (obviously).
I’m trying to migrate CUDA code to Dpc++ using Intel DPCT tool. Here are my details:
OS: Ubuntu 20.04
Application: BlackScholes (Finance app. Nvidia CUDA toolkit samples)
During migration, lot of warnings have been generated by the DPCT tool:
/home/administrator/NVIDIA_CUDA-11.1_Samples/4_Finance/BlackScholes/BlackScholes.cu:116:21: warning: DPCT1003:0: Migrated API does not return error code. (, 0) is inserted. You may need to rewrite this code.
checkCudaErrors(cudaMalloc((void **)&d_CallResult, OPT_SZ));
^
/home/administrator/NVIDIA_CUDA-11.1_Samples/4_Finance/BlackScholes/BlackScholes.cu:117:21: warning: DPCT1003:1: Migrated API does not return error code. (, 0) is inserted. You may need to rewrite this code.
checkCudaErrors(cudaMalloc((void **)&d_PutResult, OPT_SZ));
^
/home/administrator/NVIDIA_CUDA-11.1_Samples/4_Finance/BlackScholes/BlackScholes.cu:118:21: warning: DPCT1003:2: Migrated API does not return error code. (, 0) is inserted. You may need to rewrite this code.
checkCudaErrors(cudaMalloc((void **)&d_StockPrice, OPT_SZ));
^
/home/administrator/NVIDIA_CUDA-11.1_Samples/4_Finance/BlackScholes/BlackScholes.cu:119:21: warning: DPCT1003:3: Migrated API does not return error code. (, 0) is inserted. You may need to rewrite this code.
checkCudaErrors(cudaMalloc((void **)&d_OptionStrike, OPT_SZ));
Can someone tell me how to resolve these warnings?
Steps to reproduce:
intercept-build make
dpct -p compile_commands.json
You can eliminate the warnings related to cudaCheckErrors by just rewriting the code.
For Example:
"checkCudaErrors(cudaMalloc((void **)&d_CallResult, OPT_SZ));" can be rewritten as "cudaMalloc((void **)&d_CallResult, OPT_SZ);" i.e explicitly remove "checkCudaErrors" in cuda sorce code. Same follows with the other cudaCheckErrors warnings.
Later try migrating the code. I hope this might help you
Thanks, Shivani
I am trying to generate files using the square's Wire. I could run their sample all good, but as soon as I added
import "google/protobuf/timestamp.proto"; to their .proto file
to check how wire treats timestamps, compiler broke with this exception:
Exception in thread "main" java.io.FileNotFoundException: Failed to locate google/protobuf/timestamp.proto in [src/main/proto]
I have protoc in my path ($PATH=...usr/local/bin, protoc is located in there. timestamp.proto is located under /usr/local/include/google/protobuf). I expected wire compiler to use protoc from my system and therefore to be able to use it's includes.
Tried running wire with gradle plugin and using precompiled jar to same result.
UPDATE:
Also tried using gradle plugin in android studio project to same extent.
* What went wrong:
Execution failed for task ':app:generateProtos'.
> unable to resolve 1 imports:
google/protobuf/timestamp.proto
searching 0 proto paths:
Ok, after some searching and experimenting, turns out that:
1) Wire doesn't support proto3 syntax (yet)
2) Timestamp is written in proto3 syntax, and so wire just doesn't support it too.
So answer is - you can't import timestamp.proto and use it to generate classes with wire until proto3 support is implemented.
Wire now supports Proto3 and the new types, including Timestamp.
You can check the differences in implementation here: https://square.github.io/wire/wire_vs_protoc/
I get this error trying to use a github repository as a dependency using elm-install
Problem in dependency repo_name/package_name 1.0.0
The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.
What does this exactly mean?
(This answer courtesy of #ilias at Elm Slack channel)
It means that Elm couldn't compile the sources for that package in the context of your package.
Imagine for a minute I'm making a package my-fancy-package, and I have a dependency on a package foo/bar. So in my-fancy-package/elm-package.json, I could have a dependency like "foo/bar": "1.0.0 <= v < 2.0.0". Now, perhaps the most recent version of foo/bar while I'm developing my-fancy-package is 1.5.0. And in version 1.5.0, a new function was added that does exactly what I need in my-fancy-package, so I start using that function. The core issue is that there currently is no automated way to test that a package actually works with all the allowed versions of its dependencies. So now my-fancy-package says it depends on foo/bar at any version between 1.0.0 and 2.0.0, while in reality, it really needs to be at least 1.5.0 because I'm using a function from that package.
Now, imagine you're developing an application, and you're using foo/bar at version 1.2.3. According to the semver ranges of my-fancy-package, that means you should be able to use it, but if you were to actually try it, you'd receive this error: my-fancy-package is stating it is compatible with foo/bar#1.2.3 while it really needs 1.5.0.
The reason the error message doesn't simply say "it failed to compile" is because all the published packages are compiled before publishing. The most common reason for a package failing to compile in some context is that its dependencies aren't "accurate": they're letting too much stuff through.
In case of elm-install and packages from github, it's harder to say - it could actually be broken package.
Another common cause for this error is a rather silly one - conflicting definitions of infix operators. The associativity and precedence of infix ops can only be defined "globally", so if there are 2 packages that define the same infix operator, that could become a problem
I am using Eclipse Kepler with jdk1.8.0.
I do not face any compilation problems in import statements related to java8 or collect construct. However I get the compilation issue in:- Dish::getName...it says.. Syntax errors on tokens, delete the tokens.
Just trying to run the following code:
List<String> dishNames = menu.stream()
.map(Dish::getName)
.collect(toList());
System.out.println(dishNames);
Dish is a java object with String property name.
I have installed JDK8, added the latest JRE in eclipse Java Build Path.
Java compiler compliance.
Any hints what something silly I am missing?
I think you missed installing support of java8 in eclipse kepler.
You can follow this link for detailed instructions.
https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_For_Kepler