[Scilab-Dev] Hijacking built-in "set" almost works...

[Stéphane Mottelet]

Hello,

> Le 1 mars 2018 à 20:18, Samuel Gougeon <sgougeon at free.fr> a écrit :
> 
>> Le 01/03/2018 à 20:09, Stéphane Mottelet a écrit :
>> Hello,
>> 
>> I have tried to implement a (naïve) hijacking mechanism that works *like a charm* under scilab 5.5.2:
>> 
>> newfun('scilab_set',funptr('set'));
>> clearfun('set');
>> function set(varargin)
>>    scilab_set(varargin(:))
>>    printf("...\n")
>> endfunction
>> // test the hijacked "set"
>> f=gcf()
>> set(f,"tag","1")
>> f.tag="2"
>> 
>> When I test this under  6.0.0 or 6.0.1, the last line always crashes Scilab. Is there an evident reason why ? When trying this on the command line (scilab -nw)
>> 
>>> --> set(f,"tag","1")
>>> ...
>>> 
>>> --> f.tag="2"
>>> ...
>>> /Applications/scilab-6.0.1.app/Contents/MacOS/bin/scilab: line 972: 27117 Illegal instruction: 4  "$SCILABBIN" "$@"
>> 
>> I can see that the problem occurs *after* the insertion code f.tag="2" has delegated the operation to the hijacked "set", hence the crash occurs in the built-in function which does the insertion. In order to understand why this crash occurs (under Linux or OSX), I would like to know which module is in charge of the insertion for handles (a kind of %h_i but built-in) ?
> 
> You may have a look at
> SCI\modules\graphic_objects\src\cpp\setGraphicObjectProperty.cpp
> and
> SCI\modules\graphic_objects\src\java\org\scilab\modules\graphic_objects\*

Hmm, the crash occurs *after* the property has been set. So my question was rather about the generic code that handles field insertion, which is delegated to “set” for handles.

S.

> 
> Samuel
> 
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev