Hijacking built-in "set" almost works...

classic Classic list List threaded Threaded
8 messages Options
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Hijacking built-in "set" almost works...

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) ?

Thanks in advance

S.

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...

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\*

Samuel

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...

Hello,

> Le 1 mars 2018 à 20:18, Samuel Gougeon <[hidden email]> 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
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...



Le 01/03/2018 à 21:57, Stéphane Mottelet a écrit :

> Hello,
>
>> Le 1 mars 2018 à 20:18, Samuel Gougeon <[hidden email]> 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.
>

I have localized many methods for handle type in
modules/ast/src/cpp/types/graphichandle.cpp. Although I don't know much
of C++, I can see that GraphicHandle::invoke is delegated to the
overloaded %h_e macro, hence is an extraction method, but I am not able
to find any *insertion* method in this file. Maybe someone knows ?

S.
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...

Le 01/03/2018 à 23:26, Stéphane Mottelet a écrit :

> Le 01/03/2018 à 21:57, Stéphane Mottelet a écrit :
>> Hello,
>>
>>> Le 1 mars 2018 à 20:18, Samuel Gougeon <[hidden email]> 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.
>>
>
> I have localized many methods for handle type in
> modules/ast/src/cpp/types/graphichandle.cpp. Although I don't know
> much of C++, I can see that GraphicHandle::invoke is delegated to the
> overloaded %h_e macro, hence is an extraction method, but I am not
> able to find any *insertion* method in this file. Maybe someone knows ?

Maybe
edit generic_i_h


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...

Le 01/03/2018 à 23:44, Samuel Gougeon a écrit :
Le 01/03/2018 à 23:26, Stéphane Mottelet a écrit :
Le 01/03/2018 à 21:57, Stéphane Mottelet a écrit :
Hello,

Le 1 mars 2018 à 20:18, Samuel Gougeon [hidden email] 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.


I have localized many methods for handle type in modules/ast/src/cpp/types/graphichandle.cpp. Although I don't know much of C++, I can see that GraphicHandle::invoke is delegated to the overloaded %h_e macro, hence is an extraction method, but I am not able to find any *insertion* method in this file. Maybe someone knows ?

Maybe
edit generic_i_h
I found it in modules/ast/src/cpp/ast/visitor_common.cpp

When you don't have any idea of where to look, sometimes a "grep theStringToFind -r ." is useful :

2241         else if (_pVar->isHandle())
2242         {
2243             if (_pArgs->size() == 1 && (*_pArgs)[0]->isString())
2244             {
2245                 //s(["x"])
2246                 types::GraphicHandle* pH = _pVar->getAs<types::GraphicHandle>();
2247                 types::String *pS = (*_pArgs)[0]->getAs<types::String>();
2248                 types::typed_list in;
2249                 types::typed_list out;
2250                 types::optional_list opt;
2252                 in.push_back(pH);
2253                 in.push_back(pS);
2254                 in.push_back(_pInsert);
2256                 types::Function* pCall = (types::Function*)symbol::Context::getInstance()->get(symbol::Symbol(L"set"));
2257                 if (pCall)
2258                 {
2259                     types::Callable::ReturnValue ret = pCall->call(in, opt, 1, out);
2260                     if (ret == types::Callable::OK)
2261                     {
2262                         pRet = _pVar;
2263                     }
2264                     else
2265                     {
2266                         throw ast::InternalError(ConfigVariable::getLastErrorMessage(), ConfigVariable::getLastErrorNumber(), e.getLocation());
2267                     }
2268                 }
2269             }
2270             else
2271             {
2272                 pRet = _pVar->getAs<types::GraphicHandle>()->insert(_pArgs, _pInsert);
2273             }
2274         }

here one can see the delegation to "set" at line 2256...2259. However, the internal overload mechanism is still very obscure to me. Now that I can build scilab_master on my Linux machine, I have played a little bit and replaced lines 2246..2268 by the sole lines

pRet = callOverload(e, L"i", _pArgs, _pInsert, _pVar); sciprint("after callOverload\n")

then recompiled the ast module. The result is a scilab with a fully working graphics, e.g. typing "plot" without arguments works as usual and triggers a lot of handle insertions (a bunch of "after callOverload" are printed). However, there is no %h_i macro, so I don't understand by which miracle it could work.

Antoine it think that you are the author of this file (/ast/src/cpp/ast/visitor_common.cpp) can you explain how it works ?

Thanks in advance,

S.

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...

Le 02/03/2018 à 13:00, Stéphane Mottelet a écrit :
Le 01/03/2018 à 23:44, Samuel Gougeon a écrit :
Le 01/03/2018 à 23:26, Stéphane Mottelet a écrit :
Le 01/03/2018 à 21:57, Stéphane Mottelet a écrit :
Hello,

Le 1 mars 2018 à 20:18, Samuel Gougeon [hidden email] 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.


I have localized many methods for handle type in modules/ast/src/cpp/types/graphichandle.cpp. Although I don't know much of C++, I can see that GraphicHandle::invoke is delegated to the overloaded %h_e macro, hence is an extraction method, but I am not able to find any *insertion* method in this file. Maybe someone knows ?

Maybe
edit generic_i_h
I found it in modules/ast/src/cpp/ast/visitor_common.cpp

When you don't have any idea of where to look, sometimes a "grep theStringToFind -r ." is useful :

2241         else if (_pVar->isHandle())
2242         {
2243             if (_pArgs->size() == 1 && (*_pArgs)[0]->isString())
2244             {
2245                 //s(["x"])
2246                 types::GraphicHandle* pH = _pVar->getAs<types::GraphicHandle>();
2247                 types::String *pS = (*_pArgs)[0]->getAs<types::String>();
2248                 types::typed_list in;
2249                 types::typed_list out;
2250                 types::optional_list opt;
2252                 in.push_back(pH);
2253                 in.push_back(pS);
2254                 in.push_back(_pInsert);
2256                 types::Function* pCall = (types::Function*)symbol::Context::getInstance()->get(symbol::Symbol(L"set"));
2257                 if (pCall)
2258                 {
2259                     types::Callable::ReturnValue ret = pCall->call(in, opt, 1, out);
2260                     if (ret == types::Callable::OK)
2261                     {
2262                         pRet = _pVar;
2263                     }
2264                     else
2265                     {
2266                         throw ast::InternalError(ConfigVariable::getLastErrorMessage(), ConfigVariable::getLastErrorNumber(), e.getLocation());
2267                     }
2268                 }
2269             }
2270             else
2271             {
2272                 pRet = _pVar->getAs<types::GraphicHandle>()->insert(_pArgs, _pInsert);
2273             }
2274         }

here one can see the delegation to "set" at line 2256...2259. However, the internal overload mechanism is still very obscure to me. Now that I can build scilab_master on my Linux machine, I have played a little bit and replaced lines 2246..2268 by the sole lines

pRet = callOverload(e, L"i", _pArgs, _pInsert, _pVar); sciprint("after callOverload\n")

then recompiled the ast module. The result is a scilab with a fully working graphics, e.g. typing "plot" without arguments works as usual and triggers a lot of handle insertions (a bunch of "after callOverload" are printed). However, there is no %h_i macro, so I don't understand by which miracle it could work.

Antoine it think that you are the author of this file (/ast/src/cpp/ast/visitor_common.cpp) can you explain how it works ?

Thanks in advance,

S.

Ok, no miracle... in fact, if the callOverload is forced as explained above, then generic_i_h is called (thanks Samuel for your hint), and generic_i_h itself calls "set". So this is almost equivalent, besides the fact that "set" is called from a Scilab macro and not from visitor_common.cpp above. With this solution the hijacking I had proposed does not crash anymore.

But after all these complications, I guess that there may be a more straightforward way of implementing new handle properties at the user level...

S.

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Hijacking built-in "set" almost works...

Quoting Stéphane Mottelet <[hidden email]>:

Le 02/03/2018 à 13:00, Stéphane Mottelet a écrit :
Le 01/03/2018 à 23:44, Samuel Gougeon a écrit :

Le 01/03/2018 à 23:26, Stéphane Mottelet a écrit :

Le 01/03/2018 à 21:57, Stéphane Mottelet a écrit :

Hello,

Le 1 mars 2018 à 20:18, Samuel Gougeon [hidden email] 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.
 

I have localized many methods for handle type in modules/ast/src/cpp/types/graphichandle.cpp. Although I don't know much of C++, I can see that GraphicHandle::invoke is delegated to the overloaded %h_e macro, hence is an extraction method, but I am not able to find any *insertion* method in this file. Maybe someone knows ?

Maybe
edit generic_i_h
I found it in modules/ast/src/cpp/ast/visitor_common.cpp

When you don't have any idea of where to look, sometimes a "grep theStringToFind -r ." is useful :

2241         else if (_pVar->isHandle())
2242         {
2243             if (_pArgs->size() == 1 && (*_pArgs)[0]->isString())
2244             {
2245                 //s(["x"])
2246                 types::GraphicHandle* pH = _pVar->getAs<types::GraphicHandle>();
2247                 types::String *pS = (*_pArgs)[0]->getAs<types::String>();
2248                 types::typed_list in;
2249                 types::typed_list out;
2250                 types::optional_list opt;
2252                 in.push_back(pH);
2253                 in.push_back(pS);
2254                 in.push_back(_pInsert);
2256                 types::Function* pCall = (types::Function*)symbol::Context::getInstance()->get(symbol::Symbol(L"set"));
2257                 if (pCall)
2258                 {
2259                     types::Callable::ReturnValue ret = pCall->call(in, opt, 1, out);
2260                     if (ret == types::Callable::OK)
2261                     {
2262                         pRet = _pVar;
2263                     }
2264                     else
2265                     {
2266                         throw ast::InternalError(ConfigVariable::getLastErrorMessage(), ConfigVariable::getLastErrorNumber(), e.getLocation());
2267                     }
2268                 }
2269             }
2270             else
2271             {
2272                 pRet = _pVar->getAs<types::GraphicHandle>()->insert(_pArgs, _pInsert);
2273             }
2274         }

here one can see the delegation to "set" at line 2256...2259. However, the internal overload mechanism is still very obscure to me. Now that I can build scilab_master on my Linux machine, I have played a little bit and replaced lines 2246..2268 by the sole lines

pRet = callOverload(e, L"i", _pArgs, _pInsert, _pVar); sciprint("after callOverload\n")

then recompiled the ast module. The result is a scilab with a fully working graphics, e.g. typing "plot" without arguments works as usual and triggers a lot of handle insertions (a bunch of "after callOverload" are printed). However, there is no %h_i macro, so I don't understand by which miracle it could work.

Antoine it think that you are the author of this file (/ast/src/cpp/ast/visitor_common.cpp) can you explain how it works ?

Thanks in advance,

S.

Ok, no miracle... in fact, if the callOverload is forced as explained above, then generic_i_h is called (thanks Samuel for your hint), and generic_i_h itself calls "set". So this is almost equivalent, besides the fact that "set" is called from a Scilab macro and not from visitor_common.cpp above. With this solution the hijacking I had proposed does not crash anymore.

But after all these complications, I guess that there may be a more straightforward way of implementing new handle properties at the user level...

To finish on this subject and maybe feed the conversation on this subject, here is the final set/get hijacking code and and a simple example of what if allows to do: e.g. here we add a 'xlim' property to the Axes entity. At the user level it is enough to write the two functions  %Axes_set_xlim_property and %Axes_get_xlim_property(varargin). Of course, this works only if the "set" hijacking does not crash scilab, which needs the hack into modules/ast/src/cpp/ast/visitor_common.cpp describe above.

S.

newfun('scilab_set',funptr('set'));
clearfun('set');
newfun('scilab_get',funptr('get'));
clearfun('get');
function set(varargin)
    try
        if length(varargin)==3           
            execstr('%'+sprintf('%s_set_%s_property(varargin(:))',...
            scilab_get(varargin(1),'type'),varargin(2)))
        end
    catch
        scilab_set(varargin(:))
    end
end

function out=get(varargin)
    try
        if length(varargin)==2    
            out=evstr('%'+sprintf('%s_get_%s_property(varargin(:))',...
            scilab_get(varargin(1),'type'),varargin(2));
        else
            out=scilab_get(varargin(:))
        end
    catch
        out=scilab_get(varargin(:))
    end
end

function %Axes_set_xlim_property(varargin)
    varargin(1).data_bounds(1:2)=varargin(3)(:);
end

function out=%Axes_get_xlim_property(varargin)
    out=varargin(1).data_bounds(1:2);
end


clf
plot
a=gcf().children
a(2).xlim=[2 4];
disp(a(1).xlim)




_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev