add please to sdk

Can you automatically build libv86.js on Travis CI at every commit and publish it to some server or GitHub Pages? This would be very good because users then won't need to install and configure Closure Compiler and other build dependencies.

Can you also configure Makefile to also build sourcemap file for libv86.js?

Also, the version on your website is very old (f

Env:

• python 3.8
• capstone 4.0.1
• ubuntu 18.04 (WSL)

Repro:

import capstone
md = capstone.Cs(capstone.CS_ARCH_X86, capstone.CS_MODE_32)
md.detail = True

# case 1
# expected: fstcw  WORD PTR [ebp-0x4] (based on Objdump disassembly which round-trips with GNU as)
for insn in md.disasm(b"\x9B\xD9\x7D\xFC", 0):
    print(insn.address, insn.mnemonic, insn.op_str)

print(

COPYING and README claim this is GPL, but it doesn't specify which version exactly? It looks like GPLv2, the question is: "GPLv2 only" or "GPLv2 or later"?
The current uc.c only contains a copyright where it's unclear wether that file also belongs to GPL'd code.
The source files or README should contain [the license text as per COPYING file](https://github.com/unicorn-engine/unicorn/blob/master/CO

如：xxx app + www.xxx.com

不要在此issue里面提各种问题，谢谢配合。

While the test_suite presented in #589 does work, it is still pretty simple and can be improved and enhanced.

• Add tests for gnutils and coreutils.
• Add necessary utilities so more complex programs can be compiled from sources.
• Integrate CMake, so one could write something like make validate and the subset of test that is deemed necessary (for example everything with min t

I wonder why nobody every asked for this, shouldn't this be a common feature?
This feature would reduce tediousness when having to run multiple "Fill with NOPs" or "Fill with 00s" or "Binary Edit".

Just a quick question, do you think we should add a flag to keystone that will log all assemble attempts and their results? This could help for detecting inconsistencies, however it might be out of the scope for the project.

xargo CI is failing with a strange ICE:

thread 'rustc' panicked at 'failed to lookup `SourceFile` in new context', src/librustc_middle/ty/query/on_disk_cache.rs:456:17

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpect

For now the wiki page of OpenXRay is a mess!
I mean all necessary pages on all possible languages are trying to fit into main wiki page.
I haven't even found coding conventions from the first time!

That should be structured by the next design:

• Main page contains only links to language main wiki page.
• Language main page contains thematic sections like: Development, Modding, Using, Conti

Our documentation site is always lagging behind as updating the docs is a non-trivial task that has to be automated. Setting up the Travis job for building wouldn't be trivial (we probably won't fit into the time constraints), but we can use GitHub actions and host a documentation builder on one of our servers. We shall update both bap documentation and Primus Lisp docs.

It would be good to have some (at least 3-5) tutorials that teach new users what LIKWID can do and how to use it properly. From my experience as a user and FOSS developer, tutorials like deal.ii's are good thing to have. In that case we have first 5 that has to be read in a sequence by users, and then things start to branch off by t

Just like clicking on a function takes you to its definition, clicking on a struct reference like STR_4231 * pStruct = NULL; should take you to the definition of STR_4321