## Re: [Swig-devel] Swig Scilab ready ?

 Re: [Swig-devel] Swig Scilab ready ? From: Simon Marchetto - 2014-02-05 09:57:54 ```Hello William, In your mail of 10/03/2013, you proposed me to model the Scilab typemaps on Octave: "Python is usually a good reference, but it does separate out integral and floating point values, so a cast from a number that is a floating point number must be cast to an integral, eg: short smethod(short d); // C code # Python code print smethod(int(22.0)) # Okay print smethod(22.0) # Runtime error print smethod(22) # Okay Modelling on Octave ought to be a better fit where smethod(22.0) just works. Why do you want an option to add in casting like in Python? You could just make life easier for users by modelling it instead on the Octave module. Given the similarities between Octave, Matlab and Scilab, it would be a good thing to have them working similarly." That was a good idea to be consistent on what is done for other languages that are close to Scilab, as Octave is. In Scilab as in Octave, the double type is the mostly used type, you barely use integers. So Swig Scilab should convert in intput/output integer from/to double, if possible. We have this behavior in Octave. I have just tested it now: SWIG Octave converts from double to integer in input, and from integer to double in output. At first, I thought as a developer, and so was a bit scared to impose theses automatic conversions. But I find no use cases where an integer should be returned as this to Scilab, as Scilab can deal with doubles everywhere, but can have some troubles with integers. Simon Le 02/02/2014 20:58, William S Fulton a écrit : > Simon > > This isn't clear to me what you will be doing. I think you need to > write a more precise specification. It seems to me that for a given C > numeric type as input, the marshalling should try its hardest to > convert the Scilab type (be it a boolean, signed or unsigned integer > type or double) into the given C numeric type. If it can't then it > should give some sort of overflow error. With regard to output types, > then if the C type is a signed integer type it should be converted > into a signed Scilab integer. I don't see why you want to convert a C > int in output to a Scilab double, you should use the closest match in > size and sign to the C integer type. I suggest you next make a > complete table of C types and Scilab types that you will convert to > and from. This should form part of the documentation too. > > William > > On 30/01/14 09:47, Simon Marchetto wrote: >> 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. >> >> Simon >> >> Le 29/01/2014 23:40, William S Fulton a écrit : >>> Simon, >>> >>> 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? >>> >>> William >>> >>> >>> On 29 January 2014 17:09, Simon Marchetto >>> >> > 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 (we'll >>> have to discuss about it) and a few other things (I need to review >>> and probably clean the support of vector). 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. >>> >>> Regards, >>> >>> Simon >>> >>> >>> 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. >>> >>> William >>> >>> On 20/12/13 08:30, Simon Marchetto wrote: >>> >>> Hello, >>> >>> 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 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. >>> >>> Simon >>> >>> >>> 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. >>> >>> William >>> >>> >>> >>> >>> >>> >> > ```