[Contents] [TitleIndex] [WordIndex

User Documentation

I have added a document "User_Manual.odt" to dNIMS module. It's content is following:

How to build the module?

To build module, run builder.sce in Scilab. Requirements: c++ compiler. There are precompiled ScilabDotNetObjects.dll and ScilabDotNetObjects.lib in folder src/mcpp. It contains code, compiled from sources, which are located in the same folder. However, if you need to recompile managd c++ code (e.g. in case, you have modified it), you can do it by setting “compile_managed = %F” in builder_src.cpp. Note, that your vc compilers must be in PATH environment variable to build managed code.

Scilab version requirement

At least 5.3.2 version of Scilab is required.


To use a .NET object of class A, you must:

  1. If class A is not in System.dll assembly,you must load assembly, containing class A using dnload or dnloadfrom.
  2. Import class A. After this you can use static members of class A. (dnimport)
  3. To use non-static members of class A, you must create an instance of it either by calling A. (A.new(arguments) or newInstance(A, arguments)

Generalized diagram of reaching .NET class members is represented in the following figure: usage_diag_r.png

Technical documentation


This week I have stumbled upon strange bug with "remove". It does not correctly define type variable on getVarType call, given the same address as other functions, which define type correctly. Of course, I will resolve it ASAP, but it's not critical, because dNIMS can work without removing variables.

There's another little issue with temporary dlls, which are created during dynamic compilation of C# code. They must be removed, but they are not for now. Not a big issue, will be resolved soon


The biggest "Next" thing is Mono, which appeared not so easy as I thought, because there's no managed c++ compiler for Mono (at least, I could not find any). So, I will use another approach for Mono, namely, implement another ScilabMonoEnvironment class, which will use Embedding Mono. This must not be complicated, because all that is needed is translate logic from ScilabDotNetObjects to ScilabMonoEnvironment and learn how to use Embedding Mono.

The next "next" is getting benefit from abstract layer and plugging some more environments. The first, which I'm interested in and which will, IMHO, be most useful is Python, which has C API. I also will have pleasure to help anyone, who'd like to plug any other environment. And, of course, I will maintain the module as long as it is being used.

Now JIMS with abstraction layer now works fine on Linux and dNIMS part is just not built.


It seems, that dNIMS and abstraction layer works fine with .NET on Windows and JIMS works on Windows and Linux, but I'd like to start version 1.0 with dNIMS/Mono for Linux on board and some feedback from users. So, we'd better stick to 0.1 for start.


Code is available under forge here http://forge.scilab.org/index.php/p/JIMS/source/changes/abstractlayer/ and here http://forge.scilab.org/index.php/p/dnims/source/tree/master/. I did not publish tarballs. I will upload it to ATOMS after we define it's status, because it includes JIMS functionality, and JIMS is already in ATOMS.


JIMS/dNIMS works on Windows and JIMS works on Linux. As described in "Next" section, main task is to plug Mono to work with .NET on Linux. For Windows users, precompiled managed c++ dll ScilabDotNetObjects.dll will be distributed. For those, who want to compile managed c++ code, such possibility will be available by turning on flag compile_managed in builder_src.sce.

Unitary test

I know, this is bad, but I did now yet create unit tests. I used this(test_dNIMS.txt) big bunch of test pieces to test functionality. I will turn them to unit tests. Shame on me.

Implementing new environment connector

An abstraction layer has been introduced to JIMS/dNIMS. This means that other object-oriented environments can be with little effort and knowledge of Scilab internals plugged to Scilab. What developer needs to do to plug new environment, lets call it ExtEnv is:

  1. Implement class ScilabExtEnvEnvitonment, which must be inherited from ScilabAbstractEnvironment and ScilabExtEnvEnvitonmentWrapper, which must be inherited from ScilabAbstractEnvironmentWrapper.

  2. Add macro->gateway mappings to gw_table matrix in builder_gateway.c. with new macros having prefixes, identifying ExtEnv like ["extenvinvoke" "sci_invoke"; "extenvsetfield" "sci_setfield";].

  3. Add new environment type to EnvironmentType enum.

  4. Add macro->EnvironmentType mappings to macrosMap_ in ScilabAbstractEnvironmentFactory::Initialize(). Also, add name of environment, displayed to used on getenvironmentname() call to environmentNamesMap_.

  5. Modify getEnvironment and getEnvironmentWrapper of ScilabAbstractEnvironmentFactory to create and return environment and wrapper objects for ExtEnv.

  6. Create null object for ExtEnv in initialization() in ScilabObjects.c : just add line createNamedEnvironmentObjectEnv(_ENVOBJ, "extenvnull", 0, envId);, where envId is id of ExtEnv (for now, 0 is for Java and 1 is for .NET, so next environment will get 2).

  7. Implement environment-specific features. This will require deeper knowledge of Scilab, because user will need to create new gateways. But there's lot of helpfull stuff in abstraction layer (which comes from JIMS), which will make even this task simpler.
  8. Add help, demos and unitary tests.

Done in last weeks

Me and the GSoC

This was the second GSoC at Scilab for me and is was as great experience as the last year. Thanks to all who helped me through it. And although I was from start I was acquainted with lot of Scilab internals, I might have spent a little less time, than I could. But results are worth publishing of the module and I will not reduce my activity in module development ( I will also review and improve my previous module, SciDb ).

Longest part

The longest part was, definitely, refactoring wrappers in JIMS to introduce some abstraction, because they are quite complicated there, consisting of several layers of macros and template classes.

What to improve

Get more students :) ! May be announce some kind of competition for the best module (e.g. defined by voting of students and mentors in the end of the program).


The subject itself was not very hard, but I had to refactor lot of code in JIMS, which nevertheless is quite readable and understandable. It also was first time I coded in managed c++, so lot of hard googling was involved for some tricks.

2022-09-08 09:26