[Scilab-users] Counter of pointers to an XML object, and clear destructor

classic Classic list List threaded Threaded
6 messages Options
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Counter of pointers to an XML object, and clear destructor

Hello,

I am doing some tests about the save() function, in order to document its behavior when saving pointers to some objects.

There is the case of XML objects:
Contrarily to graphic handles, that are pointers whose reloading restores the pointed graphics, saving XML pointers is possible, but then their reloading does NOT restore the XML document.
Then, when digging in Bugzilla in order to search for features about this and the clear() function applied to XML pointers, i've found back the following comment from Calixte, referring to an expected change of Scilab 6 with respect to Scilab 5:

With Scilab 6, things will be easier since each data will have a reference counter [of pointers to it] which will allow to call a kind of destructor when the reference count will be zero.

In practical, this new feature looks still not to be implemented. Here is an illustration:

// Let's create an XML document and a pointer "doc" to it:
--> doc = xmlReadStr("<root><a att=""foo"" rib=""bar""><b>Hello</b></a></root>")
 doc  =
XML Document
url: Undefined
root: XML Element

// Now, let's make a copy of the pointer:

-->doc2=doc
 doc2  =
XML Document
url: Undefined
root: XML Element

--> doc2==doc
 ans  =
  T T    <<< this double True is strange, but it's not the matter here

// Then let's clear both pointers: If a counter actually exists,
// it shall be set to 0 afterwards.
// And if the automatic destructor is implemented, then this should
// automatically delete the XML document. What's the reality?:
--> clear doc doc2   // OK
-->  xmlGetOpenDocs()
 ans  =
       ans(1)
XML Document
url: Undefined
root: XML Element

The document still exists. So, the automatic destructor is not yet implemented,
at least for XML objects.

Is it a pity? To me, the reverse approach would be more relevant:
Deleting an object should clear all its pointers. For instance, with the XML example
hereabove, deleting the document should clear doc and doc2.
It's unfortunately not the case:
--> xmlDelete(xmlGetOpenDocs()(:))  // cleaning the area
--> doc = xmlReadStr("<root><a att=""foo"" rib=""bar""><b>Hello</b></a></root>");
--> doc2 = doc;
--> xmlDelete(doc)
--> isdef(["doc" "doc2"],"l")
 ans  =
  T T
--> doc
 doc  =
-->

This is the same issue with graphic handles when the figure they point to has been closed:
We then get some still existing but invalid handles, instead of properly clearing them.

Regards
Samuel



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

Re: Counter of pointers to an XML object, and clear destructor

 

Regarding the save() function, the output *.sod file fails to be consumed by load() for some graphical handles.

Example of error message in Scilab 6.0.1:

      load: Unable to load 'h'.

 

--> typeof(h)

ans  =  handle

 

--> h

h  =

Handle of type "uicontrol" with properties:

===========================================

Parent: Figure

Children: []

Style = "listbox"

BackgroundColor = [-1,-1,-1]

Callback = ""

Callback_Type = -1

Constraints = "NoLayoutConstraint"

Enable = "on"

FontAngle = "normal"

FontName = "Tahoma"

FontSize = 12

FontUnits = "points"

FontWeight = "bold"

ForegroundColor = [-1,-1,-1]

ListboxTop = 0

Margins = [0,0,0,0]

Max = 1

Min = 0

Position = [0,0,500,850]

Relief = "default"

String = string 14x3

Tag = ""

TooltipString = ""

Units = "pixels"

Userdata = []

Value = []

Visible = "on"

 

 

Any tips/workaround to save/load Scilab sessions in a clean way (even if compromising graphical entities)?

 

Regards,

Rafael

 


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

Re: Counter of pointers to an XML object, and clear destructor

Le 28/07/2018 à 22:21, Rafael Guerra a écrit :

 

Regarding the save() function, the output *.sod file fails to be consumed by load() for some graphical handles.

Example of error message in Scilab 6.0.1:

      load: Unable to load 'h'.


Yes, it was reported this week as http://bugzilla.scilab.org/15667
By the way, even when we load a whole figure (the bug 15667 does not occur)
but with uicontrols, there are still some issue with their positions
(however the situation is much better than with Sciab 5.5.2).



.../... 

 

Any tips/workaround to save/load Scilab sessions in a clean way (even if compromising graphical entities)?


None that i know. There are still a bunch of bugs about save(), load() and
listvarinfile(), noticeably recently found and reported when making tests
in order to update, improve, and finally rewrite load() and save() help pages.
To me, the most disturbing one is that listvarinfile() sometimes
leaves the file locked... Then we have to close and restart Scilab
to unlock the file and being able to go on... Really blocking!

The new proposed save() page can be found here.
The current one is there.

Regards
Samuel


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

Re: Counter of pointers to an XML object, and clear destructor

Samuel,

 

Thanks for confirming & bug reports.

 

Regards,

Rafael

 

From: users <[hidden email]> On Behalf Of Samuel Gougeon
Sent: Sunday, July 29, 2018 12:34 PM
To: Users mailing list for Scilab <[hidden email]>
Subject: Re: [Scilab-users] Counter of pointers to an XML object, and clear destructor

 

Le 28/07/2018 à 22:21, Rafael Guerra a écrit :

 

Regarding the save() function, the output *.sod file fails to be consumed by load() for some graphical handles.

Example of error message in Scilab 6.0.1:

      load: Unable to load 'h'.


Yes, it was reported this week as http://bugzilla.scilab.org/15667
By the way, even when we load a whole figure (the bug 15667 does not occur)
but with uicontrols, there are still some issue with their positions
(however the situation is much better than with Sciab 5.5.2).





.../... 

 

Any tips/workaround to save/load Scilab sessions in a clean way (even if compromising graphical entities)?


None that i know. There are still a bunch of bugs about save(), load() and
listvarinfile(), noticeably recently found and reported when making tests
in order to update, improve, and finally rewrite load() and save() help pages.
To me, the most disturbing one is that listvarinfile() sometimes
leaves the file locked... Then we have to close and restart Scilab
to unlock the file and being able to go on... Really blocking!

The new proposed save() page can be found here.
The current one is there.

Regards
Samuel


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Antoine ELIAS-2 Antoine ELIAS-2
Reply | Threaded
Open this post in threaded view
|

Re: Counter of pointers to an XML object, and clear destructor

In reply to this post by Samuel GOUGEON
Hello Samuel,

In XMLObject there is two levels of reference,
 - one on MList (managed by reference counter)
 - one on internal XMLObject (internally manager like handle, an integer that link to a C++ object)

xmlDelete destroy internal XMLObject
clear destroy (unreference and destroy if ref <= 1 ) MList object.

So in your case, after a xmlDelete, the internal XMLObject was destroyed but not the MList.
And after a clear doc, the MList was destroyed but the internal XMLObject not.

Current XMLObject is based on simple MList with the id of the doc ( store as double ).
If we want to correctly destroy the internal XMLObject with the clear command.
We must change the implementation to use types::UserType instead of types::Double and uses destructor of UserType to free XMLObject.

> Deleting an object should clear all its pointers. For instance, with the XML example
> hereabove, deleting the document should clear doc and doc2.
I am not agree with that, I cannot delete an user variable indirectly. ( xmlDelete(doc) that will delete doc )
Only clear command can do that. For me it will be a bad practice.

Antoine
Le 28/07/2018 à 16:20, Samuel Gougeon a écrit :
Hello,

I am doing some tests about the save() function, in order to document its behavior when saving pointers to some objects.

There is the case of XML objects:
Contrarily to graphic handles, that are pointers whose reloading restores the pointed graphics, saving XML pointers is possible, but then their reloading does NOT restore the XML document.
Then, when digging in Bugzilla in order to search for features about this and the clear() function applied to XML pointers, i've found back the following comment from Calixte, referring to an expected change of Scilab 6 with respect to Scilab 5:

With Scilab 6, things will be easier since each data will have a reference counter [of pointers to it] which will allow to call a kind of destructor when the reference count will be zero.

In practical, this new feature looks still not to be implemented. Here is an illustration:

// Let's create an XML document and a pointer "doc" to it:
--> doc = xmlReadStr("<root><a att=""foo"" rib=""bar""><b>Hello</b></a></root>")
 doc  =
XML Document
url: Undefined
root: XML Element

// Now, let's make a copy of the pointer:

-->doc2=doc
 doc2  =
XML Document
url: Undefined
root: XML Element

--> doc2==doc
 ans  =
  T T    <<< this double True is strange, but it's not the matter here

// Then let's clear both pointers: If a counter actually exists,
// it shall be set to 0 afterwards.
// And if the automatic destructor is implemented, then this should
// automatically delete the XML document. What's the reality?:
--> clear doc doc2   // OK
-->  xmlGetOpenDocs()
 ans  =
       ans(1)
XML Document
url: Undefined
root: XML Element

The document still exists. So, the automatic destructor is not yet implemented,
at least for XML objects.

Is it a pity? To me, the reverse approach would be more relevant:
Deleting an object should clear all its pointers. For instance, with the XML example
hereabove, deleting the document should clear doc and doc2.
It's unfortunately not the case:
--> xmlDelete(xmlGetOpenDocs()(:))  // cleaning the area
--> doc = xmlReadStr("<root><a att=""foo"" rib=""bar""><b>Hello</b></a></root>");
--> doc2 = doc;
--> xmlDelete(doc)
--> isdef(["doc" "doc2"],"l")
 ans  =
  T T
--> doc
 doc  =
-->

This is the same issue with graphic handles when the figure they point to has been closed:
We then get some still existing but invalid handles, instead of properly clearing them.

Regards
Samuel




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


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

Re: Counter of pointers to an XML object, and clear destructor

Hello Antoine,

Thanks for your answer. I am afraid that, from a user point of view -- that's mine--, it is hard to understand in pratical the way it works, and why it works like this:

Le 30/07/2018 à 00:55, Antoine ELIAS a écrit :
Hello Samuel,

In XMLObject there is two levels of reference,
 - one on MList (managed by reference counter)
 - one on internal XMLObject (internally manager like handle, an integer that link to a C++ object)

xmlDelete destroy internal XMLObject
clear destroy (unreference and destroy if ref <= 1 ) MList object.

How is it possible to illustrate all this with Scilab instructions and tests?
In what you describe, i don't see any difference between Scilab 5 and Scilab 6,
contrarily to Calixte's announcement, noticeably about the way clear() works.


So in your case, after a xmlDelete, the internal XMLObject was destroyed but not the MList.
And after a clear doc, the MList was destroyed but the internal XMLObject not.

Yes, i understand all that.

Current XMLObject is based on simple MList with the id of the doc ( store as double ).
If we want to correctly destroy the internal XMLObject with the clear command.
We must change the implementation to use types::UserType instead of types::Double and uses destructor of UserType to free XMLObject.

So, is this the new possible feature of Scilab 6 vs Scilab 5?
In this way, i am not sure that this would be the most interesting evolution.
Even if an open document has no local handle, it is still possible to retrieve
an access to open ones, and from everywhere,  with xmlGetOpenDocs().
That's nice.

> Deleting an object should clear all its pointers. For instance, with the XML example
> hereabove, deleting the document should clear doc and doc2.
I am not agree with that, I cannot delete an user variable indirectly. ( xmlDelete(doc) that will delete doc )
Only clear command can do that. For me it will be a bad practice.

Why?! This is the key point. It holds in the same way for graphic handles.
I would like very much to read and understand rationales about this point.
From a user point of view, i don't see a single reason or interest in
keeping "invalid handles" or "invalid XML documents", that's to say,
clearly, keeping some pending pointers! These are dead and completely useless
objects, since there is no way to recover the deleted target.
So, what's the interest in using is_handle_valid(h) instead of simply isdef("h")??
What's the interest of using xmlIsValidObject(doc) instead of isdef("doc")?
With such a current implementation, if we have created many alias of an handle,
then there are as many obsolete aliases that are pending pointers.

If you have in mind a single situation for which this implementation has
an interest (compared to an automatical clearing of invalid handles)
it would be great to share it.

Usually, leaving pending pointers is the bad practice, not removing them.
Isn't it?

Best regards
Samuel


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