OK, I agree.

So are we going on the following behavior ?
- Scilab double or integer in input => C int
- C int in output => Scilab double
- C unsigned int <=> Scilab unsigned integer

(same for short, and long).

It is the behavior you proposed last time, and which is currently used in Octave, if I remembered what you told me ?

Maybe there are some use cases in which we want absolutely a Scilab signed integer returned, but in fact I can't see anyone for now.
We'll see on using.

About bool: there is a Scilab boolean type, mapping should be direct, no other conversion.


Le 29/01/2014 23:40, William S Fulton a écrit :

Your plan sounds reasonable. Definitely any fine tuning such as memory leak fixes can be done in later releases. Indeed the basic typemaps for primitives should work correctly. Also basic STL like std::vector should work reasonably well, at the minimum generating compilable code even if they cannot be usefully used from Scilab. In summary the test-suite should pass if these basics are all ready. SWIG is very forgiving and can easily generate compilable code even if all types are practically unusable and this is the minimum accepted standard. From what I recall of the Scilab test-suite you were practically there until something went wrong in the primitive typemaps and vectors.

What precisely do you mean by the Scilab integers will only be used if the wrapped function specified signed or unsigned integers. All integers in C are either signed or unsigned, they can't be anything else! If you are thinking that 'signed' or 'signed int' should behave differently to 'int', then I will contest that. Surely you mean all integer types will convert to an equivalent Scilab integer type without exception and the only 'other cases' are floating point types, which of couse should map to a Scilab double? What about bool?


On 29 January 2014 17:09, Simon Marchetto <simon.marchetto@scilab-enterprises.com> wrote:
Hello William,

I am back on SWIG ! I During the time I have been away, I could think about the initial tasks planned below. I decided to revise some of them:

- We dont need a SWIG feature to set the behavior for primitive typemaps (conversion to/from double or not). The Scilab (signed and unsigned) integers will be used only if the wrapped function signature specifies signed or unsigned integers. In other cases, we convert from/to Scilab double, if possible. It is simpler. By the way that was the initial behavior, but it still needs to be fixed. The code of Scilab typemaps still need some cleaning in general.

- Code generation : I wanted to optimize the generated code, to reduce its size, and increase its performance. But it can wait the next version.

- Review of C/C++ features support. It will take too much time. I will review the most important unit tests, fix them and add a few if needed. I will do a complete review later.

- STL support : I will fix only the case of vector<class> (we'll have to discuss about it) and a few other things (I need to review and probably clean the support of vector<enum>). I let away other features of STL: iterators...

But I keep the task of finishing the documentation, which is one of the most important tasks.

Also a generated code is not usable if it has huge memory leaks. I do not think it will have any, but if I have time, I will do some checks on memory management.

I hope I can finish all this soon.



Le 20/12/2013 21:26, William S Fulton a écrit :

I don't think you need go overboard on the tests for acceptance into master. So long as the test-suite passes and you have a few runtime tests (you already have enough), then I'll merge it into master. You can add improvements over time. All I think you need to do is get the primitive typemaps working as these are fundamental.

With regard to checklists for C/C++ features supported, if the test-suite compiles and your tests include things like enums, global functions and variables, static and non-static class methods and variables, you'll find that you'll have a lot covered as a lot of the detail is handled in the core. Adding in stl wrappers etc can come later.


On 20/12/13 08:30, Simon Marchetto wrote:

Yes unfortunately I was away from SWIG. My aim is also to add Scilab in
the major version SWIG 3.
I am not sure if it is still possible now, if we want to keep high quality.

My planned tasks were:
- finish the C++ support: fix the vector<class> case, maybe a few small
other things
- fix primitive type typemaps, mostly about integer and double. I would
like to introduce a SWIG feature that sets the behavior of that
typemaps: either convert automatically int from/to Scilab double as
Octave does, or keep integers as integers.
- finish the documentation
- check memory management
- some refactoring : the generated code maybe or more organized or
smaller (optional)
- also, and what is the most important to me :  I do not have a clear
and complete view on what is supported or not by SWIG Scilab. I would
like to build a check list of support status for all C or C++ features.
For this, I need to analyze also all the unit tests, and maybe I need to
add some tests too.

Each of these task may be not so long to complete, but the sum could
take a couple of weeks.


Le 18/12/2013 01:21, William S Fulton a écrit :
What is the latest status for Scilab? Perhaps I've got it wrong, but
not much development has happened recently and we are now in the final
stages for putting out SWIG 3 and really I'd like Scilab support added
for this release.