Compiling Julia embedded in C++ code - c++

I'm trying to compile the following C++ code
#include <julia.h>
int main(int argc, char *argv[])
{
/* required: setup the julia context */
jl_init(NULL);
/* run julia commands */
jl_eval_string("print(sqrt(2.0))");
/* strongly recommended: notify julia that the
program is about to terminate. this allows
julia time to cleanup pending write requests
and run all finalizers
*/
jl_atexit_hook();
return 0;
}
I compile the code using
gcc -I/usr/include/julia -L/usr/lib/x86_64-linux-gnu/julia -ljulia juliatest.cpp -o test
I get the following error-
juliatest.cpp:19:20:: error: too few arguments to function ‘void jl_atexit_hook(int)’
jl_atexit_hook();
^
In file included from juliatest.cpp:1:0:
/usr/include/julia/julia.h:1188:16: note: declared here
DLLEXPORT void jl_atexit_hook(int status);
^
If I remove jl_atexit_hook(); from the code, I get the following errors-
juliatest.cpp:(.text+0x1a): undefined reference to `jl_init_with_image'
juliatest.cpp:(.text+0x24): undefined reference to `jl_eval_string'
What am I doing wrong?

The example you are trying to compile is a little bit outdated. As already mentioned you need to give an exitcode to the jl_atexit_hook()
function. The linker message is about missing functions defined in libraries. To get rid of distribution details I downloaded and build the tarball. Now the example can be build using this makefile:
JULIA_DIR:=julia-0.4.2
JULIA_LIB:=$(JULIA_DIR)/usr/lib
JULIA_SRC:=$(JULIA_DIR)/src
JULIA_INC:=$(JULIA_DIR)/usr/include
CPPFLAGS:=-I$(JULIA_INC) -I$(JULIA_SRC) -I$(JULIA_SRC)/support
LDFLAGS:=-L$(JULIA_LIB)
LDLIBS=-ljulia
export LD_LIBRARY_PATH:=$(JULIA_LIB):$(JULIA_LIB)/julia
all: main
run: main
#./main
clean:
rm -f main
If you now type make run you will get the next error message about a wrong path the system image is searched in. As Thomas noted here the function jl_init() is creating a context that may fail in this case. We shall give the name and the path of the system image to the init function using jl_init_with_image("julia-0.4.2/usr/lib/julia", "sys.so") instead. This is an ugly hard coded path and can surely be replaced. But for getting started with this example and to get this problem known, it is enough. The corrected example is this:
#include <julia.h>
#include <stdio.h>
int main(int argc, char *argv[]) {
/* required: setup the julia context */
jl_init_with_image("julia-0.4.2/usr/lib/julia", "sys.so");
/* run julia commands */
jl_eval_string("print(sqrt(2.0))");
/* strongly recommended: notify julia that the
program is about to terminate. this allows
julia time to cleanup pending write requests
and run all finalizers
*/
jl_atexit_hook(0);
putchar('\n');
return 0;
}
Running make run will now be a quite complicated way to calculate the square root of 2 :-)
Have fun.

Related

SystemC: read() and write() to port doesnt work

I am new to systemC It might look stupid but I would appreciate help.
In the below code
In main function :write() to aa and bb shows value 0 when read using aa.read() and bb.read() which should be 10 and 20
And also I think it should enter the method do_add() in the adder module as it is sensitive to a and b and a,b are binded to aa and bb signals but it doesn't call the method do_add(). How does it work and is there any error in the code?
For compiling the code:
g++ -I. -I$SYSTEMC_HOME/include -L. -L$SYSTEMC_HOME/lib-linux64 -Wl,-rpath=$SYSTEMC_HOME/lib-linux64 -o out adder.cpp -lsystemc -lm
./out
#include "systemc.h"
#define WIDTH 32
SC_MODULE(adder) {
sc_in<sc_uint<WIDTH> > a, b;
sc_out<sc_uint<WIDTH> > sum;
void do_add() {
// cout<<"hello"<<endl;
// cout<<a.read()<<b.read()<<"\n";
sum.write(a.read() + b.read());
// cout<<sum.read()<<endl;
}
SC_CTOR(adder) {
SC_METHOD(do_add);
sensitive << a << b;
}
};
int sc_main(int argc, char* argv[]) {
sc_signal<sc_uint<WIDTH> >aa,bb;
adder add("Adder");
add.a(aa);
add.b(bb);
aa.write(10);
bb.write(20);
cout<<aa.read()<<bb.read()<<"\n";
}
There are a number of things here. Firstly, you never actually start the simulation (see function sc_start) and even if you did it would exit immediately since there are no events to process. And lastly, even if you fixed those issues you would still get the same result since SystemC simulates hardware and reading a port in the same delta cycle as it was written will give you the original value on the port not the newly written one. How can hardware change the value of a signal in zero time?
The best advice I can give is to look in the directory where you downloaded SystemC and you will see a directory of PDF documents. On my SystemC it is in a directory called 'docs' (it may be different on yours depending on who installed it and where). If you look in there you will find a 'user guide' and some other PDF documents. These explain how SystemC works and give you examples you can try and modify to your own needs. Also there are some examples in the SystemC sources in the 'examples' folder. You can try playing around with these to get a feel for it and maybe just cut and paste some code and modify it to get what you require.

Why does my GStreamer-based C++ application not produce any log output, but gst-tools like "gst-launch" do?

After reading every thread and guide to GStreamer debugging I am still stuck with my problem.
Setting the debug level to GST_DEBUG=*:3 (or any other level) leads to log perfect output when using the gst-tools (e.g. gst-launch-1.0 for testing a certain pipeline), even GST_DEBUG_FILE=filename.txt works.
My problem: My own application that uses GStreamer-stuff a lot does not produce any debug output at all when using the same settings above, any ideas?
Setup: Ubuntu 14-4, Gstreamer 1.0
For anyone who runs into this problem, there is a helpful comment in the code:
The macro is only active if gstreamer is configured with
"--gst-enable-gst-debug" and the environment variable
GST_DEBUG_DUMP_DOT_DIR is set to a basepath (e.g. /tmp).
Therefore, you should set GST_DEBUG_DUMP_DOT_DIR to a specific directory.
Ubuntu : If you want to know the value of GST_DEBUG_DUMP_DOT_DIR:
$ echo $GST_DEBUG_DUMP_DOT_DIR
If the result is empty then you can set it on the terminal using the below line:
$ export GST_DEBUG_DUMP_DOT_DIR=path/to/save/dot/file
and then run your program from the same terminal, or you can set the variable in the /.bashrc file.
second solution
This export can be placed in the main function of our C file:
int main(int argc, char *argv[]) {
putenv("GST_DEBUG_DUMP_DOT_DIR=/tmp");
.
.
.
}
Problem solved: I did start my application with sudo, overwriting my entire environment.

creating an RInside instance inside a thread

I am interested in writing a c++ program that is capable of running R scripts. For several design reasons I would like to create an instance of RInside, execute a script, grab the result, and destroy the instance; all within a thread. I know that R is not multi-threaded, and that one cannot create multiple instances of RInside. But can I create single instances within isolated threads? When I attempt to do this my code compiles, but I get the following error at run-time:
Error: C stack usage is too close to the limit
Error: C stack usage is too close to the limit
terminate called after throwing an instance of 'Rcpp::binding_not_found'
what(): binding not found: '.AutoloadEnv'
Aborted
Here is the code that produced the error:
#include <unistd.h>
#include <stdio.h>
#include <pthread.h>
#include <RInside.h>
void *thread_main(void *args){
RInside R(0,NULL);
/* hope to execute an R script here */
printf("--printing from thread--\n");
return NULL;
}
int main(int argc, char *argv[]){
pthread_t tid;
if( pthread_create(&tid, NULL, thread_main, NULL) ){
printf("failed to create thread\n");
return -1;
}
sleep(1);
return 0;
}
I have tried setting R_CStackLimit = (uintptr_t)-1 as recommended in Writing R Extension, but to no avail.
I am running ubuntu, R version 2.15.2, RInside version 0.2.10.
Is it possible to accomplish this? or do I have to learn something like Rserve?
Thank you so much!
R is, and will likely remain, single-threaded. RInside goes to some length to ensure it is created as a singleton; if you subvert that you get the errors you see above. Within the same executable, you only get one RInside instance so one-per-thread will not work. As you experienced.
See the examples I include in the source on how to cope with the single-threaded backend when using multi-threaded frontends such as Qt or the Wt library for webapps.
Longer term we may be able to do what Rserve does and fork. Code contributions would be welcome, I probably won't have time to work on this.

UnitTest++ and main

I want to give TDD a try and I've chosen the UnitTest++ framework, but the documentations is almost non-existent (to my knowledge).
My concern is this: in all the tutorials I've seen, they put UnitTest::RunAllTests() in the main() function. I'm guessing they do it only to simplify the explanation, but I wouldn't want that with my software. Where should I put UnitTest::RunAllTests() so that I can have it executed every time I build the software but not when I run it?
UnitTest::RunAllTests() should be put into the main function of a separate program, which you compile and run as part of your build process.
One thing we've done in the past is to add a command line argument which makes the main executable run all the tests and then exit. It's fairly easy to arrange some #ifdefs such that this code gets compiled out on release builds. Something like this (it's not very C++ but if you weren't parsing command line arguments already this is the simplest way to do it):
int main (int argc, char *argv[])
{
#ifdef DEBUG
if (argc > 1 && !strcmp(argv[2], "-t"))
{
return UnitTest::RunAllTests();
}
#endif
[rest of program]
}

How to use FMOD with C++?

I'm trying to create a simple mp3 player using FMOD:
#include "inc/fmod.h"
int main()
{
FSOUND_Init(44100, 32, 0);
return 0;
}
Trying to compile the program I get the following error:
holle#x300:justmp3$ pwd
/media/daten/Entwicklung/C/justmp3
holle#x300:justmp3$ LD_LIBRARY_PATH=$(pwd)/lib
holle#x300:justmp3$ ls $LD_LIBRARY_PATH
libfmodex-4.34.02.so libfmodexL-4.34.02.so
holle#x300:justmp3$ g++ -o mp3 mp3.cpp
mp3.cpp: In function ‘int main()’:
mp3.cpp:8: error: ‘FSOUND_Init’ was not declared in this scope
What's my mistake? How could I get g++ to compile the program?
FSOUND_Init is an FMOD 3 API function, you are using FMOD Ex so that function doesn't exist. To initialize FMOD Ex you should include "fmod.hpp" and use the functions:
System_Create to create the FMOD system object, then
System::init to initialize, followed by
System::createStream to load your MP3, then
System::playSound to play it.
There are a bunch of useful examples that ship with FMOD that you could use as a reference, especially the playstream example for what you want to achieve. Also there is full documentation in CHM format. If you are porting code from FMOD 3 I would recommend reading the migration guide in the fmodex.chm docs.
You need to include the headers for the library too, add
#include <fmod.h>
at the beginning of your code.