open-simulation-platform / cosim4j Goto Github PK

Currently we are based on 0.6.0 with cse namespace. Needs to update to cosim.

cse-core4j still does not work under Windows. We currently use Gradle and the highly experimental and undocuemted cpp-plugin for building the JNI code. Lets try CMake to see if that makes a difference.

We should add CI. I only know how to use CircleCI, which takes about 1 minute to set up. But since this is a private repo, we can't use it unless we buy it (9$ a month).

Someone willing to setup travis Jenkins CI similar to cse-core?

Clone the project and run:

./gradlew test

@hplatou The linux build worked fine in Jenkins when it was a PR. Now it fails by "not finding gradlew".. Is there some sort of Jenkins magic I need to know about?

With Github Actions configured, there is no longer need for the Jenkins build I guess?
@hplatou In addition to removing the checked in Jenkinsfile, I guess there are something you need to do on your end?

It's time to update this repository to support the newer versions of cse-core

Make it possible to create slaves in Java code.

There will be some issues since CSE uses boost::fibers, but we can reuse the solution used when I implemented the callback feature.

org.osp is not owned by us. Need to change. Either a github package name or use ntnu namespace.

Improve readme to give some guidance on how to be able to use cosim4j. How to build and include in a project, for example.

Should automate the process of building natives. This would also allow us to omit checking in the natives to git.

May serve as a PoC for inclusion in cse-core in the future.

Maven artifacts should be published to some suitable server.

The initial design of this module was that all relevant native libs should be bundled with the .jar. This is easier said then done. An alternative solution is to require that CSE is pre-installed on the target system, and naturally added to PATH.

Invalidates #2

@hplatou what OS is running on the Jenkins Windows node? Or the real question is: Can pre-compiled .dlls from a 64-bit Win10 system be used on it?

Windows dlls are missing, thus it only works on Linux.

Step event listener is broken in conjunction with cse::execution.start().

Possible related: https://stackoverflow.com/questions/19092602/context-switched-native-thread-cant-attach-to-jvm

It seems you cannot do callbacks to Java when using boost::fibers.

@kyllingstad @mrindar Any insights?

This is my current code:

cse::step_event_listener::step_event_listener(JNIEnv* env, jobject listener)
{
    env->GetJavaVM(&jvm_);
    jclass cls = env->GetObjectClass(listener);
    mid_ = env->GetMethodID(cls, "post", "()V");
    listener_ = env->NewGlobalRef(listener);
}

void cse::step_event_listener::step_complete(cse::step_number lastStep, cse::duration lastStepSize, cse::time_point currentTime)
{

    JNIEnv* env;
    bool attach = false;
    jint getEnvStat = jvm_->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6);
    if (getEnvStat == JNI_EDETACHED) {
        jvm_->AttachCurrentThread(reinterpret_cast<void**>(&env), nullptr);
        attach = true;
    }

    env->CallVoidMethod(listener_, mid_);

    if (attach) {
        jvm_->DetachCurrentThread();
    }
    
}

cse::step_event_listener::~step_event_listener()
{
    
    JNIEnv* env;
    bool attach = false;
    jint getEnvStat = jvm_->GetEnv((void**)&env, JNI_VERSION_1_6);
    if (getEnvStat == JNI_EDETACHED) {
        jvm_->AttachCurrentThread((void**)&env, nullptr);
        attach = true;
    } 

    env->DeleteGlobalRef(listener_);

    if (attach) {
        jvm_->DetachCurrentThread();
    }
    
}