I used JNA to call some C++ methods from Java. Everything works fine. This methods contain "cout" to print some things. My question is if it is possible to redirect these prints from C++ methods to a JFrame in Java. In Java methods it is quite easy but I don't know if it possible for methods called through JNA. Ok I know it is a quite strange question but I would like to know if it is possible. Thanks in advance.
You'll need to redirect the cout stream to where Java can read it. You might use a circular buffer with producer/consumer pointers, a callback to Java with the most recent data, or any other method common to inter-process communication. It'll probably be easier to redirect the stream in native code to test, but there's no reason you couldn't translate that native code into JNA calls.
See Rerouting stdin and stdout from C for one method of redirecting stdout. If you dump to a file, you can have Java read from the file. JNA is perfectly capable of calling freemen.
You may need to look around to find the actual value of stdout; look at your system's <stdio.h> file for its definition. On OSX, it's a global symbol called __stdout of type FILE*. On other systems it's the address of an element within a global array of FILE structs.
Related
I would like to have a DML device with interfaces and register banks as the TOP-level of my device but offload processing to Python. Is there a lightweight method of calling into Python from DML?
This post How can I unit test a specific DML method? addresses calling from Python into DML, but I am interested in the reverse.
I think I can create a bunch of custom interfaces to do this, but I'm interested to know if there's a better way.
Implementing parts of a device in Python can make sense, in particular for code that seldom is invoked (user interaction comes to mind), and when faced with tasks like string manipulation where the shortcomings of a C-like language is particularly painful, or when code sharing with CLI commands is desired.
You can use the SIM_call_python_function API to call out to Python from DML. The function uses the equivalent of eval on the passed string, so you can find a module-local function by __import__:
local attr_value_t a = SIM_make_attr_list(0);
local attr_value_t result = SIM_call_python_function(
"__import__('simics').SIM_version", &a);
log info: "%s", SIM_attr_string(result);
SIM_attr_free(&a);
SIM_attr_free(&result);
This API is admittedly not very pretty. Parts of the standard lib for DML 1.2 is in fact written in Python and uses the internal function VT_call_python_module_function for this task instead. That API is nicer, but we cannot recommend use of VT_ functions outside the core Simics team.
This question is really more about the Simics simulator framework than about DML. Given how Simics works, Python code lives in a separate context. There is no obvious light-weight way. Rather, you need to put the Python code in a separate Python class and a separate runtime object and use a Simics simulator interface to orchestrate the calling.
The Python code would in general not be able to access the state of the object anyway, so it would have to be a strict "compute this and return all computed values". Which is not very convenient for device behavior that is really all about mutating the state of the object.
Even with a bunch of interfaces, there is still the matter of state handling. I guess you need an interface for that as well.
I want to use Uprobe in eBPF to trace the Java program I wrote, but I do not know how to find the symbol table corresponding to the Java program. In C language, platform-related executable files will be generated after compilation, and the corresponding address of the method can be obtained through the executable file.But Java is an interpreted language, there are no executable files, and eBPF is a Linux tool, do not know the Java language related information.I know that methods in the JVM can be traced using USDT, such as method__entry, but that doesn't give you information about the arguments to the methods, so is there a way to trace Java functions using eBPF?
BCC,using USDT to print a method flow graph in high-level languages.
Not a Java tracing expert, but I think that you need to look at perf-map-agent.
This is what Brendan Greggs mentions in his posts on perf and on CPU flame graphs, and I believe it applies to eBPF as well as perf. This post gives an example on how to call the tool from a container, to produce flame graphs with BCC tools.
Is there a supported way to have an Ada program call out to GNAT to compile a source file, and then load the result dynamically?
(By 'supported' I mean: better than shelling out to gnatmake.)
Background: I have a program whose configuration files contain code. Right now I have an LLVM-based library, written in C++, which I have C bindings to and call out to from Ada, which handles this: it loads the configuration files, JIT compiles them into (commendably fast) machine code, and then I call out to them from Ada.
This is horrible.
It would be far cleaner to simply write the configuration in Ada, and compile and link it against the program. But I don't want to force the end user to have to set up a build system. What I'd like is for the end user to just point my program at the configuration files, and then have the program compile and dynamically load them invisibly, without the user needing to care.
This sounds like exactly the sort of thing that someone's already done. Have they? (I only care about Unixoids like Linux, if that helps.)
I have just finished the first version of a Java 6 compiler plugin, that automatically generates wrappers (proxy, adapter, delegate, call it what you like) based on an annotation.
Since I am doing mixed Java/Scala projects, I would like to be able to use the same annotation inside my Scala code, and get the same generated code (except of course in Scala). That basically means starting from scratch.
What I would like to do, and for which I haven't found an example yet, is how do I generate the code inside a Scala compiler plugin in the same way as in the Java compiler plugin. That is, I match/find where my annotation is used, get the AST for the annotated interface, and then ask the API to give me a Stream/Writer in which I output the generated Scala source code, using String manipulation.
That last part is what I could not find. So how do I tell the API to create a new Scala source file, and give me a Stream/Writer/File/Handle, so I can just write in it, and when I'm done, the Scala compiler compiles it, within the same run in which the plugin was invoked?
Why would I want to do that? Firstly, because than both plugins have the same structure, so maintenance is easy. Secondly, I want to open source it, and there is just no way to support every option that anyone would want, so I expect potential users to want to extend the generation with their own code. This will be a lot easier for them if they just have to do some printf(), instead of learning the AST API (this also applies to me).
Short answer:
It can't be done
Long answer:
You could conceivably generate your source file and push that through a parser instance within your plugin. But not in any way that's likely to be of any use to you, because you'd now have a bigger problem to contend with:
In order to grab all the type/name information for generating the delagate/proxy, you'll have to pick up the annotated type's AST after it has run through both the namer and typer phases (which are inseperable). The catch is that any attempts to call your generated code will already have failed typechecking, the compiler will have thrown an error, and any further bets are off.
Method synthesis is possible in limited cases, so long as you can somehow fool the typechecker for just long enough to get your code generated, which is the trick I pulled with my Autoproxy 'lite' plugin. Even then, you're far better off working with TreeDSL to generate code instead of pumping out raw source.
Kevin is entirely correct, but just for completeness it's worth mentioning that there is another alternative - write a compiler plugin that generates source. This is the approach that I've adopted in Borachio. It's not a very satisfactory solution, but it can be made to work.
Edit - I just reread your question and realised that you're actually asking about generating source anyway
So there is no support for this directly, but it's basically just a question of opening a file and writing the relevant "print" statements. There's no way to invoke the compiler "inside" a plugin AFAIK, but I've written an sbt plugin which hides most of the complexity of invoking the compiler twice.
I have a function written in C (Say in HelloWorld.c file).
I want to compile this and need to create a staic object file HelloWorld.a
Finally I need to call this from a Perl program (HelloWorld.pl).
To call from perl to C one usually compiles a shared, not a static, library from his c code, and then loads that into the perl interpreter using the XSLoader or DynaLoader module.
To then be able to call the C code from perl space there's many ways. The most common one is writing something called XSUBs, which have a perl-side interface, map the perl calling-conventions to C calling-conventions, and call the C functions. Those XSUBs are usually also linked into the shared library that'll be loaded into perl, and written in a language called XS, which is extensively documented in perlxs and perlxstut.
There's also other ways to build that wrapper layer, like various XS code generators, as well as SWIG. But you could also call to the C functions directly using an NCI. Perl also has many of those. The P5NCI is one example of those, the ctypes module developed in this year's Google Summer of Code program is another.
Another related technique that should probably be mentioned here is Inline::C, and the other modules of the Inline family. They allow you to write code in other languages directly in perl, and call to it. Under the hood Inline::C just builds XS code and loads the result of that into the interpreter.
As #rafl says, you should use a shared library.
If you must use a static library, then you have to rebuild Perl with the static library built in. You'll need some XS glue too. However, this is messy enough that you really, really don't want to do it.
According to perlxstut:
It is commonly thought that if a system does not have the capability to dynamically load a library, you cannot build XSUBs. This is incorrect. You can build them, but you must link the XSUBs subroutines with the rest of Perl, creating a new executable. This situation is similar to Perl 4.
This tutorial can still be used on such a system. The XSUB build mechanism will check the system and build a dynamically-loadable library if possible, or else a static library and then, optionally, a new statically-linked executable with that static library linked in.
Should you wish to build a statically-linked executable on a system which can dynamically load libraries, you may, in all the following examples, where the command "make" with no arguments is executed, run the command "make perl" instead.
If you have generated such a statically-linked executable by choice, then instead of saying "make test", you should say "make test_static". On systems that cannot build dynamically-loadable libraries at all, simply saying "make test" is sufficient.