[GSoC] OpenModelica Integration Discussion

classic Classic list List threaded Threaded
31 messages Options
12
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[GSoC] OpenModelica Integration Discussion

This post was updated on .
Hi all,


I made a preliminary proposal for the project I discussed on previous thread. So I'm asking for some comments about it, possible misconceptions, unfeasible time estimates, etc.

- Requirements

Here is the image showing compiled scilab-master initial screen and "about" window:


Apart from my patch for last GSoC, I'm also trying to push some Coverity fixes (more to come).


Thanks again.


Att,
Leonardo
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi, all.

I have tried some other coverity fixes and ended up submitting the proposal at GSoC page. There were no comments so I am assuming the text is mostly OK.

Thanks again.


Att,
Leonardo.
Caioc2 Caioc2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi,


It seems good for me, you have been discussing all those ideas with scilab team, and I think it is already well defined which incomes are expected for this project.
I would like a better detailed schedule, maybe less weeks but more details for each topic, but I also know that it is hard to give those details before working on them.

You could improve the document style, to make things you think to be important "pops out", but it would be just a lift up, irrelevant to its content.

On Sun, Apr 2, 2017 at 8:15 PM, Bitiquinho <[hidden email]> wrote:
Hi, all.

I have tried some other coverity fixes and ended up submitting the proposal
at GSoC page. There were no comments so I am assuming the text is mostly OK.

Thanks again.


Att,
Leonardo.



--
View this message in context: http://mailinglists.scilab.org/GSoC-OpenModelica-Integration-Proposal-draft-tp4036042p4036117.html
Sent from the Scilab / GSOC - Mailing Lists Archives mailing list archive at Nabble.com.
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc


_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi, Caio.

Thanks for your input. I'll try to address those points (at least some of them) before the submission deadline.


Att,
Leonardo.
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

In reply to this post by Bitiquinho
Hi All,


With a little delay, thanks for accepting me to participate in one more GSoC with Scilab !

As stated in my proposal, during the bonding period, I'll be looking into building a minimal OMC compiler inside Scilab's build system in place of the modelicac compiler, to get things started.

I hope I can contribute enough during this summer.


Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft

Hi all,

First of all, sorry for being a little late with getting started

I'll be posting my progress reports in the same blog I have used last year: http://bitiquinho.github.io/2017-05-12-google_summer_of_code_2/

The GSoC webpage says that my mentors this year are davidcl (Clément David, I suppose) and paro. I would like to know what are your preferred way of communicating for questions and other discussions.


Thanks again
paul paul
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration: Proposal draft


Hello Bitiquinho,

Thank you for that. Email is our go-to tool, to keep traces, but for
punctual exchanges you may connect to our IRC
(https://www.scilab.org/fr/resources/user_community/irc)

Regards,
Paul (paro)

On 2017-05-12 06:38, Bitiquinho wrote:

> Hi all,
>
> First of all, sorry for being a little late with getting started
>
> I'll be posting my progress reports in the same blog I have used last
> year:
> http://bitiquinho.github.io/2017-05-12-google_summer_of_code_2/
>
> The GSoC webpage says that my mentors this year are davidcl (Clément
> David,
> I suppose) and paro. I would like to know what are your preferred way
> of
> communicating for questions and other discussions.
>
>
> Thanks again
>
>
>
>
> --
> View this message in context:
> http://mailinglists.scilab.org/GSoC-OpenModelica-Integration-Proposal-draft-tp4036042p4036372.html
> Sent from the Scilab / GSOC - Mailing Lists Archives mailing list
> archive at Nabble.com.
> _______________________________________________
> gsoc mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/gsoc
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Bitiquinho
Hi all,

I was revisiting my discussion for this project that I had with Clément before submitting my proposal, and I came across this:

"You can split the tasks as :
 1. build a simple OMCompiler
 2. get into the code to discover how to generate FMI2 API (or internal API)
 3. write a scicos_block4 compatible block generator (either using a wrapper or a new code
generator)
 4. package everything for all Scilab supported platforms (in thirdparties)."

So, about task 4: I almost went for figuring out a way to build a simple OMCompiler as part of the Scilab build itself (like what happens with modelicac compiler), but that didn't make much sense, as OpenModelica is a full application that could be installed/packaged by distributions separately. I guess that OMCompiler would be more like a soft dependency during Scilab compilation, whose detection triggers the building of compatible scicos_block4 generator. That's why it would be stored inside thirdparties folder, right ?

However, currently the thirdparties SVN repository seems to only contain Java Jar packages. How should I add a new C++ target to its building process ? Or are the packages for this repo just copied from their respective binary releases ?

Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

(I don't know if someone saw my question here or in the mailing list, but I'm really clueless about the thirdparties repo)

Hi again

I spend some time over the last days trying to understand how Xcos model compilation calls the Modelica compiler, and it seems like everything comes down to the build_modelica_block function (inside modules/scicos/macros/build_modelica_block.sci), which separates the process in combining all Modelica into a single .mo file (inside create_modelica) and feeding this to actual translation (which I don't quite get what means), compilation (modelicac calling), properties aquisition (reading_incidence) and linking (all inside compile_modelica function)

Is that accurate ? I couldn't find any other reference to modelicac executable being called.

Could I assume that the code generated by create_modelica is completely standard (even if outdated) and one wouldn't have any issues passing it to a different compiler, so that I could just leave this function as it is ?

If the usage of OMCompiler (rather than modelicac) will be conditional, what is the proper way to change *.sci scripts during Scilab build process ? Or should the Modelica compiler be selectable with a runtime switch ?


Thanks again
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hello Leonardo,

(answered inline)

> Hi again
>
> I spend some time over the last days trying to understand how Xcos model
> compilation calls the Modelica compiler, and it seems like everything comes
> down to the build_modelica_block function (inside
> modules/scicos/macros/build_modelica_block.sci), which separates the process
> in combining all Modelica into a single .mo file (inside create_modelica)
> and feeding this to actual translation (which I don't quite get what means),
> compilation (modelicac calling), properties aquisition (reading_incidence)
> and linking (all inside compile_modelica function)
>
> Is that accurate ? I couldn't find any other reference to modelicac
> executable being called.

Yep this is all good ! There is also an XML file generation for tuning default values on do_eval ;
at first this is not critical but I am not sure if we can have such an output from OpenModelica.

About "translating", this is the process of flattening the Modelica class-like model to a single 1
file with a reduced syntax : eg. without "connect" or model inheritance.

> Could I assume that the code generated by create_modelica is completely
> standard (even if outdated) and one wouldn't have any issues passing it to a
> different compiler, so that I could just leave this function as it is ?

Yes it is, the code generated using create_modelica() is extracted from block parameters and is
standard ; the associated Modelica libraries are stored in `modules/scicos_blocks` :

modules/scicos_blocks/macros/Electrical/Electrical.mo
modules/scicos_blocks/macros/Hydraulics/Hydraulics.mo

> If the usage of OMCompiler (rather than modelicac) will be conditional, what
> is the proper way to change *.sci scripts during Scilab build process ? Or
> should the Modelica compiler be selectable with a runtime switch ?

IMHO the OMCOmpiler should be used instead of modelicac . The modelicac support is already optional
and OMCompiler can be embedded within Scilab dependencies. In the build process, you should not add
anything more ; just detect OMCompiler and use it.

Thanks,

--
Clément
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Bitiquinho
Hello Leonardo,

Exactly I missed this part, sorry :)

> However, currently the thirdparties SVN repository seems to only contain
> Java Jar packages. How should I add a new C++ target to its building process
> ? Or are the packages for this repo just copied from their respective binary
> releases ?

The SVN pre-requirements repository also contains binary : JVM, lib, etc.. The binary building is
not committed on the main repo ; there is a bash script for Linux thirdparties committed on the repo
to download and build them all. Visual Studio Projects are committed on another repo.

As OpenModelica have a lot of dependency, I suggest you to build a "minimal" version and use it. You
might also add a Scilab Preferences setting to let the user configure an external executable.

Thanks,

--
Clément
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Thanks for replying and sorry for the delay

Where could I find and edit the bash script and VS project files to add OMCompiler-minimal download and compilation to both pre-requirements repositories ?


Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Clément David-3
>Yep this is all good ! There is also an XML file generation for tuning default values on do_eval ;
>at first this is not critical but I am not sure if we can have such an output from OpenModelica.

Aside from C/C++ source code, OMCompiler also generates a modelDescription.xml file, but I'm not sure it can be used for the same purpose (looks like only a listing of state variables)

>IMHO the OMCOmpiler should be used instead of modelicac . The modelicac support is already optional
>and OMCompiler can be embedded within Scilab dependencies. In the build process, you should not add
>anything more ; just detect OMCompiler and use it.

But should modelicac still work as a fallback (in the absence of OMCompiler e.g. for Scilab packaged by distros) when building with Modelica support ? Or just ditched altogether ?


Thanks again
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

This post was updated on .
In reply to this post by Clément David-3
Hi all,

I need to ask one more thing:

Looking at C code files produced by modelicac, I see that they include scicos_block.h instead of scicos_block4.h for scicos_block structure definition. Also, they use Get_Jacobian_parameter() function for Jacobian calculation, which is not declared in scicos_block4.h. There are Get_Jacobian_cj() and Get_Jacobian_ci() functions that I guess could be used in this case, but they don't seem to be implemented anywhere.

So, which header file should I use for a FMI2 wrapper implementation ?

Thanks in advance
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

In reply to this post by Bitiquinho
Hi again,

I have one more question:

According to Scicos Block documentation, DerivativeState (and I guess Jacobian also, but it's not listed) jobs for computational function use xd field of scicos_block structure as output, but when I was looking at the code generated by current Modelica compiler, that didn't seem to be the case:

void BouncingBall_Modelica_im(scicos_block *block, int flag)
{
        double *rpar = block->rpar;
        double *x = block->x;
        double *xd = block->xd;
        double *res = block->res;

        /* Intermediate variables */
        double v0;

        if (flag == DerivativeState) {
                res[0] = xd[0]-x[1];
                res[1] = rpar[0]+xd[1];
        }
        /* ... */
        else if (flag == Jacobian) {
                v0 = Get_Jacobian_parameter();
                res[0] = v0;
                res[1] = 0.0;
                res[2] = -1.0;
                res[3] = v0;
                res[4] = 1.0;
                res[5] = 0.0;
                res[6] = 0.0;
                res[7] = 1.0;
                set_block_error(0);
        }

        return;
}
 
The document I referenced states that the res array field has the same length as x and xd and is only used for internally implicit blocks, but its purpose is not clear. What is the difference between using res and xd ? Are the docs outdated ?
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hello Leonardo,

It seems that you are getting in-depth understanding of ODE vs IDA simulation :) . For related
papers, do not hesitate to take a look at the Sundials documentation.

Basically, a block perform a simulation in different domains and have outputs (or states) for all
the domains. For example, to compute an output with a continuous state your block performs:

 u = f(u, x, t)

To compute the derivative, it performs:

 xd = f(u, x, t)

That's it for pure continuous simulation but as Xcos performs in an hybrid mode where the simulation
is continuous between events there is an additional function to compute. The continuous system have
to be initialized after each event to check when block computation modes changed. This is called
"Jacobian" computation or residuals resolution and is performed using Sundials Kinsol solver.

To compute the residuals [2] (partial derivative of xd), this 0D (time constant) evaluation invoke
the blocks which computes:

 res = f(jac) where res is the residuals and jac is a value returned by the Kinsol solver.

[1]: https://en.wikipedia.org/wiki/Jacobian_matrix_and_determinant
[2]: https://en.wikipedia.org/wiki/Residual

Thanks,

--
Clément

Le vendredi 16 juin 2017 à 17:25 -0700, Bitiquinho a écrit :

> Hi again,
>
> I have one more question:
>
> According to  Scicos Block documentation
> <http://www.scicos.org/Newblock.pdf>  , *DerivativeState* (and I guess
> *Jacobian* also, but it's not listed) jobs for computational function use
> *xd* field of *scicos_block* structure as output, but when I was looking at
> the code generated by current Modelica compiler, that didn't seem to be the
> case:
>
> void BouncingBall_Modelica_im(scicos_block *block, int flag)
> {
> double *rpar = block->rpar;
> double *x = block->x;
> double *xd = block->xd;
> double *res = block->res;
>
> /* Intermediate variables */
> double v0;
>
> if (flag == DerivativeState) {
> res[0] = xd[0]-x[1];
> res[1] = rpar[0]+xd[1];
> } 
>         /* ... */
> else if (flag == Jacobian) {
> v0 = Get_Jacobian_parameter();
> res[0] = v0;
> res[1] = 0.0;
> res[2] = -1.0;
> res[3] = v0;
> res[4] = 1.0;
> res[5] = 0.0;
> res[6] = 0.0;
> res[7] = 1.0;
> set_block_error(0);
> }
>
> return;
> }
>  
> The document I referenced states that the *res* array field has the same
> length as *x* and *xd* and is only used for internally implicit blocks, but
> its purpose is not clear. What is the difference between using *res* and
> *xd* ? Are the docs outdated ?
>
>
>
> --
> View this message in context: http://mailinglists.scilab.org/GSoC-OpenModelica-Integration-Discuss
> ion-tp4036042p4036585.html
> Sent from the Scilab / GSOC - Mailing Lists Archives mailing list archive at Nabble.com.
> _______________________________________________
> gsoc mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/gsoc
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hi all,

Thanks, Clément. I've trying to read as much as I can to get the particularities of each solver available in Scilab.

From what I understand up until now, DAE solvers (e.g. IDA), unlike ODE ones (e.g. CVODE), use residuals rather than derivatives for continuous updates. So you would deal with a function like

xd = f(u,x,t)

for ODEs and

res = F(u,x,xd,t) = f(u,x,t) - xd

for DAEs


If that's right, is there a way I can get from the block information regarding which kind of solver is being used (to know when to treat xd as input or output), and which are the derivative and algebraic states (in the case of DAEs) ?


Regarding Kinsol solver, from Sundials documentation, it seems to be intended to a different purpose: nonlinear algebraic systems. Is it used together with the DAE solver to solve the algebraic part ? I couldn't figure that out by looking at scicos.c code.

When the scicos_block is called with flag 10 (Jacobian) to calculate res = f(jac), is the jac matrix stored in one of block fields, or should I get that calling e.g. hfjac_() function ?


Sorry if I'm confusing things here and thanks again.
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hi Leonardo,

> From what I understand up until now, DAE solvers (e.g. IDA), unlike ODE ones
> (e.g. CVODE), use residuals rather than derivatives for continuous updates.
> So you would deal with a function like
>
> xd = f(u,x,t)
>
> for ODEs and 
>
> res = F(u,x,xd,t) = f(u,x,t) - xd
>
> for DAEs

Yep

> If that's right, is there a way I can get from the block information
> regarding which kind of solver is being used (to know when to treat xd as
> input or output), and which are the derivative and algebraic states (in the
> case of DAEs) ?

In Xcos, both inputs (and outputs as inputs of another block) and states are passed to the solver.
And for algebraic blocks, a modelica subsystem is created containing all the modelica world in one
block. Please take a look at build_modelica.sci and c_pass1.sci:270 for the actual implementation.

This solver information is not located on blocks as the solver choice is left to the user on diagram
parameter. If the diagram contains a modelica block, the solver is switched in IDA automatically.

> Regarding Kinsol solver, from Sundials documentation, it seems to be
> intended to a different purpose: nonlinear algebraic systems. Is it used
> together with the DAE solver to solve the algebraic part ? I couldn't figure
> that out by looking at scicos.c code.

It is used to solve the modelica initial conditions (x and xd at t=0) using the dedicated GUI, see
SolveAction.java:43 and Compute_cic.sci .

> When the scicos_block is called with flag 10 (Jacobian) to calculate res =
> f(jac), is the jac matrix stored in one of block fields, or should I get
> that calling e.g. hfjac_() function ?

The Jacobian is never passed to each block, only (x, xd, residuals) are and should be computed. The
Jacobian is computed by the IDA solver using the residuals.

Thanks,

--
Clément
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
Bitiquinho Bitiquinho
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hi, Clément

> In Xcos, both inputs (and outputs as inputs of another block) and states are passed to the solver.
> And for algebraic blocks, a modelica subsystem is created containing all the modelica world in one
> block. Please take a look at build_modelica.sci and c_pass1.sci:270 for the actual implementation.

I understand. Putting everything into a single block is the purpose of Modelica "flattening", right ?

I also get that the block structure contains all input and output information, but my question comes from a investigation of simulator code (sorry for not mentioning that before), where this conditional appears before the computational function is called:

/* continuous state */
if ((solver == IDA_BDF_Newton || solver == DDaskr_BDF_Newton || solver == DDaskr_BDF_GMRes) && block->type < 10000 && *flag == 0)
{
  ptr_d = block->xd;
  block->xd  = block->res;
}

According to this, if Modelica blocks are of type 4, during derivatives update for DAE solvers the xd and res pointers would reference the same data, so the function wouldn't be able to write both derivatives and residuals.

> This solver information is not located on blocks as the solver choice is left to the user on diagram
> parameter. If the diagram contains a modelica block, the solver is switched in IDA automatically.

Oh, that makes things much clearer. So I should only care about returning residuals here, right ?

> It is used to solve the modelica initial conditions (x and xd at t=0) using the dedicated GUI, see
> SolveAction.java:43 and Compute_cic.sci.

Thanks. I didn't know about these files.

> The Jacobian is never passed to each block, only (x, xd, residuals) are and should be computed. The
> Jacobian is computed by the IDA solver using the residuals.

I guess that explains the larger res array for Jacobian flag in this function generated by modelicac:

void BouncingBall_Modelica_im(scicos_block *block, int flag)
{
        double *rpar = block->rpar;
        double *x = block->x;
        double *xd = block->xd;
        double *res = block->res;
       
        /* ... */

        double v0;

        if (flag == DerivativeState) {             // Flag 0
                res[0] = xd[0]-x[1];
                res[1] = rpar[0]+xd[1];
        } else if (flag == OutputUpdate) {         // Flag 1
                if (get_phase_simulation() == 1) {
                        y[0][0] = x[0]; /* OutPutPort1.vo */
                        y[1][0] = x[1]; /* OutPutPort2.vo */
                } else {
                        y[0][0] = x[0]; /* OutPutPort1.vo */
                        y[1][0] = x[1]; /* OutPutPort2.vo */
                }
        }
        /* ... */
        else if (flag == Jacobian) {             // Flag 10
                v0 = Get_Jacobian_parameter();
                res[0] = v0;
                res[1] = 0.0;
                res[2] = -1.0;
                res[3] = v0;
                res[4] = 1.0;
                res[5] = 0.0;
                res[6] = 0.0;
                res[7] = 1.0;
                set_block_error(0);
        }

        return;
}

For flag 10, res is filled with the partial derivatives matrix you've mentioned, right ?

Thanks one more time
Clément David-3 Clément David-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [GSoC] OpenModelica Integration Discussion

Hello Leonardo,

> > And for algebraic blocks, a modelica subsystem is created containing all
> > the modelica world in one
> > block. Please take a look at build_modelica.sci and c_pass1.sci:270 for
> > the actual implementation.
>
> I understand. Putting everything into a single block is the purpose of
> Modelica "flattening", right ?

Exactly !

> I also get that the block structure contains all input and output
> information, but my question comes from a investigation of simulator code
> (sorry for not mentioning that before), where this conditional appears
> before the computational function is called:
>
> /* continuous state */
> if ((solver == IDA_BDF_Newton || solver == DDaskr_BDF_Newton || solver ==
> DDaskr_BDF_GMRes) && block->type < 10000 && *flag == 0)
> {
>   ptr_d = block->xd;
>   block->xd  = block->res;
> }
>
> According to this, if Modelica blocks are of type 4, during derivatives
> update for DAE solvers the xd and res pointers would reference the same
> data, so the function wouldn't be able to write both derivatives and
> residuals.

Hmm, to the block->xd is saved in a temporary and the residuals are passed as xd before callf the
block.
The ptr_d should be used later to restore the pointer.

> > This solver information is not located on blocks as the solver choice is
> > left to the user on diagram
> > parameter. If the diagram contains a modelica block, the solver is
> > switched in IDA automatically.
>
> Oh, that makes things much clearer. So I should only care about returning
> residuals here, right ?

Yep

> For flag 10, res is filled with the partial derivatives matrix you've
> mentioned, right ?

res should be filled by the block and give an indication on the variable weight for future
iteration. In the code snippet you posted, the useful value is stored for the corresponding variable
(or at rigth index of res) ; other res indices are discarded using 0 or have a weight as 1 or -1 to
indicate a direction.

PS: At this point, you are at my understanding limits ; I suggest you to try to implement something
we can check and iterate on that :)

--
Clément
_______________________________________________
gsoc mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/gsoc
12
Loading...