Menu
▾
▴
[Swig-devel] Fwd: Re: Swig Scilab ready ?
|
From: Simon M. <sim...@sc...> - 2014-02-26 10:45:02
|
In my solution containers of pointers (on classes) is supported only.
The problem is the following.
As for other languages, I implement the operator T() in the struct
"SciSequence_Ref" (Lib/scilab/scicontainer.swg)
The implementation uses templates, as usual in SWIG
(Lib/scilab/scisequence.swg) :
template <typename T> struct traits_asval_sequenceitem {
static T asval(SwigSciObject obj, void *pSequence, int iItemIndex) {
.... ? .....
}
};
I can't use the SWIG traits, because the Scilab typemaps work for
function arguments only. You do not have any type info like the PyObject
in Python. What provides the Scilab API is giving you the type of data
for a specified argument, given its index. And then you convert all the
data of the arguments in one shot. SwigSciObject obj is a dummy argument
here.
This template is specialiezd for common Scilab types: double, int, bool,
etc... No problem for that, problem is unknown types.
I have to convert an item, without knowing its type. And in SWIG you
cannot use C++ type traits.
So I just do not know what to write in the body of the function.
There are four solutions:
- I could provide a context. I am not sure if this solution will solve
all problems.
- I could consider T is a pointer. In Scilab, mostly if you do not have
a primitive type, you have a pointer. But it makes me very scary to do
this. I am quite sure some cases will not work.
- I could choose to not implement the operator T(). But in that case,
operator [] won't be supported in Scilab, do you confirm that ?
- raise a runtime error
The last solution looks like the fastest and the most secure. I do not
have so much visibility on the other solutions.
Fortunately I can implement a specific behavior for pointers:
template <typename T> struct traits_asval_sequenceitem<T*> {
static T* asval(SwigSciObject obj, void *pSequence, int iItemIndex) {
return static_cast<T*>(SWIG_AsVal_SequenceItem_dec(ptr)(obj, (int
*)pSequence, iItemIndex));
}
};
And so vector<class*> is supported but not vector<class>.
But after all, that is not so a big limitation. I do not how to really
deal with vector<class> in Scilab as classes do not exist in Scilab.
Technically vector<class> and vector<class*> differ mostly on memory
management issue as you said in a previous mail. You will have to
allocate items in output. I do not measure all the consequences of this,
it looks like a bit akward to me, from the user point of view.
Simon
Le 26/02/2014 00:18, William S Fulton a écrit :
> Simon
>
> Sounds good. By all means add proper support for STL containers that
> use non-primitive types in a later version if this is going to be
> better supported by a later version of Scilab. For this release, the
> minimum requirement is the generated code must compile, even if it is
> rather useless.
>
> What I don't understand is, do you have support for classes working?
> That is the SWIGTYPE typemaps? Also references/pointers to classes -
> SWIGTYPE&, SWIGTYPE&const and SWIGTYPE* typemaps? If you do,
> containers of classes shouldn't be much different as the marshalling
> of the elements (such as push_back) will use the aforementioned typemaps.
>
> William
>
> On 25/02/14 11:07, Simon Marchetto wrote:
>> Hello William,
>>
>> I am in the race to finish my works on Scilab.
>>
>> I've fixed the typemaps the way I proposed to you recently, and
>> implemented more exhaustive tests on this topic, among other things.
>> Still some tests and documentations are missing, but I am feeling I am
>> very close to the end.
>>
>> What blocks me is in the STL support, the conversion in input of
>> container items (and maybe in output, I haven't looked at this yet).
>> I have successfully implemented some container item typemaps for Scilab
>> specific types such as double, bool, string, etc....
>>
>> But implementing the default typemap is hard. I looked what has be done
>> for Python, and I cannot do the same.
>> Because of different reasons, in my case, I have no idea about the item
>> type, if is a pointer, or something else.
>> I cannot neither use here the swig traits library, nor the C++ type
>> traits.
>>
>> I think the only reasonable solution here is to raise a type error in
>> the default typemap. I could consider by default an item is a pointer,
>> but I surely have some problems with this.
>>
>> I would like to have your advices. Maybe there is a better solution but
>> I am afraid to spend too much time on it. I think we can go on with this
>> for moment. STL support is important but supporting custom types in STL
>> from Scilab is no so critical in that version. And future version of
>> Scilab has a new C++ API which should make the things much easier on
>> this subject.
>>
>> Simon
>>
>>
>> Le 07/02/2014 09:58, Simon Marchetto a écrit :
>>> Yes it will raise an error, as in Octave. The code will also check
>>> overflows.
>>>
>>> Double is indeed the norm in Scilab. You can have an exemple of this
>>> with the factorial() function in Scilab. This integer in essence
>>> function does not even accept integers as input !
>>>
>>> -->factorial(3.0)
>>> ans =
>>> 6.
>>>
>>> -->factorial(3.2)
>>> error 10000
>>> ....
>>>
>>> -->factorial(int32(3))
>>> error 10000
>>> ....
>>>
>>> Simon
>>>
>>> Le 06/02/2014 20:20, William S Fulton a écrit :
>>>> What do you plan to happen when you call
>>>>
>>>> print smethod(22.2)
>>>>
>>>> Presumably this will error out? If it silently loses precision, then
>>>> I don't know that your approach is a good one and I can't see
>>>> overloading working. If on the other hand you can reliably detect and
>>>> extract a true integer out of a double in Scilab, then using doubles
>>>> as the Scilab type everywhere seems reasonable. It sounds a bit
>>>> inefficient and slower to me, but if this is the norm in Scilab, then
>>>> fine.
>>>>
>>>> William
>>>>
>>>> On 05/02/14 10:10, Simon Marchetto wrote:
>>>>> Once we agree on the principles, I will write a full and precise
>>>>> specification, that should be included in the documentation.
>>>>>
>>>>> Simon
>>>>>
>>>>> Le 05/02/2014 10:57, Simon Marchetto a écrit :
>>>>>> 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
>>>>>>>>> <sim...@sc...
>>>>>>>>> <mailto:sim...@sc...>> 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.
>>>>>>>>>
>>>>>>>>> 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<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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> Managing the Performance of Cloud-Based Applications
>>>>>> Take advantage of what the Cloud has to offer - Avoid Common
>>>>>> Pitfalls.
>>>>>> Read the Whitepaper.
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Swig-devel mailing list
>>>>>> Swi...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Swig-devel mailing list
>>> Swi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>
>>
>>
>>
>> _______________________________________________
>> Swig-devel mailing list
>> Swi...@li...
>> https://lists.sourceforge.net/lists/listinfo/swig-devel
>>
>
|