[Pharo-project] Class comments are in the .sources ?
Hi folks. I was playing a bit with the ClassOrganizer stuff. I thought that class comments were in the image, but it seems they are kept in the .source. Is this correct ? They are ALWAYS kept in the .sources? I know that the class of the instancia variable "classComment" in the ClassOrganizer can be Text, ByteString or even RemoteString. I though that only those who have RemoteString were in .sources but it seems all are there. I am correct ? is this the desired behavior ? Thanks! Mariano
2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks. I was playing a bit with the ClassOrganizer stuff. I thought that class comments were in the image, but it seems they are kept in the .source. Is this correct ?
They are ALWAYS kept in the .sources?
I know that the class of the instancia variable "classComment" in the ClassOrganizer can be Text, ByteString or even RemoteString. I though that only those who have RemoteString were in .sources but it seems all are there. I am correct ? is this the desired behavior ?
Yes you are. The state of these things are bunch of hacks, added over a years and really, really messy. I presented some ideas about it in the past, but since it requires a substantial efforts to make it done, they weren't get past much the state of an ideas. :)
Thanks!
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Thu, Mar 11, 2010 at 10:47 AM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks. I was playing a bit with the ClassOrganizer stuff. I thought that class comments were in the image, but it seems they are kept in the .source. Is this correct ?
They are ALWAYS kept in the .sources?
I know that the class of the instancia variable "classComment" in the ClassOrganizer can be Text, ByteString or even RemoteString. I though that only those who have RemoteString were in .sources but it seems all are there. I am correct ? is this the desired behavior ?
Yes you are. The state of these things are bunch of hacks, added over a years and really, really messy.
OK...thanks for the warning.
I presented some ideas about it in the past, but since it requires a substantial efforts to make it done, they weren't get past much the state of an ideas. :)
I would like to hear those ideas. What I want to do right now, is to be able to remove a lot of memory consumption that maybe they are not used under certain circumstances like embedded devices. For example, I would like to remove all the method categories or put a blank space. Or to remove the class comments (I though they were in the image). In summary, for those applications that can live with that, I would like to remove unnecessary data from ClassOrganization so that to low memory footprint. What do you think? Cheers Mariano
Thanks!
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Mar 11, 2010 at 10:47 AM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks. I was playing a bit with the ClassOrganizer stuff. I thought that class comments were in the image, but it seems they are kept in the .source. Is this correct ?
They are ALWAYS kept in the .sources?
I know that the class of the instancia variable "classComment" in the ClassOrganizer can be Text, ByteString or even RemoteString. I though that only those who have RemoteString were in .sources but it seems all are there. I am correct ? is this the desired behavior ?
Yes you are. The state of these things are bunch of hacks, added over a years and really, really messy.
OK...thanks for the warning.
I presented some ideas about it in the past, but since it requires a substantial efforts to make it done, they weren't get past much the state of an ideas. :)
I would like to hear those ideas.
Oh. What is the point? Nobody will have enough comitment to do it anyways :) But briefly. It was an idea of creating a source management layer, starting from replacing a compiler logging and ending with being able to use any other backend for storing the sources , not just bare files, but databases accessible via network as well.
What I want to do right now, is to be able to remove a lot of memory consumption that maybe they are not used under certain circumstances like embedded devices. For example, I would like to remove all the method categories or put a blank space. Or to remove the class comments (I though they were in the image). In summary, for those applications that can live with that, I would like to remove unnecessary data from ClassOrganization so that to low memory footprint.
 What do you think?
allClassesDo: [:class | class organization setDefaultList: #() ]
Cheers
Mariano
Thanks!
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
What do you think?
allClassesDo: [:class | class organization setDefaultList: #() ]
Seems to be more complicated than that. There is a problem with the notifications.... Now, I added to ClassOrganizer the method putAllSelectorInDefaultCategory self elementArray do: [:each | self classify: each under: self class default suppressIfDefault: false] And then I evaluate: Smalltalk allClassesDo: [:each | each organization putAllSelectorInDefaultCategory]. Smalltalk allClassesDo: [:each | each organization removeEmptyCategories]. Smalltalk garbageCollect. That seems to work. I mean, all method of all classes uses the same category. As it is a ByteSymbol, there is only one instance. However, after saving the image, is it is bigger than before evaluating that.... there is of course something I am not understanding. Is there some chapter, tutorial or link to read about all the ClassOrganizer stuff ? Thanks Mariano
Cheers
Mariano
Thanks!
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 11, 2010, at 3:58 PM, Mariano Martinez Peck wrote:
What do you think?
allClassesDo: [:class | class organization setDefaultList: #() ]
Seems to be more complicated than that. There is a problem with the notifications....
Now, I added to ClassOrganizer the method
putAllSelectorInDefaultCategory self elementArray do: [:each | self classify: each under: self class default suppressIfDefault: false]
And then I evaluate:
Smalltalk allClassesDo: [:each | each organization putAllSelectorInDefaultCategory]. Smalltalk allClassesDo: [:each | each organization removeEmptyCategories]. Smalltalk garbageCollect.
That seems to work. I mean, all method of all classes uses the same category. As it is a ByteSymbol, there is only one instance. However, after saving the image, is it is bigger than before evaluating that....
there is of course something I am not understanding. Is there some chapter, tutorial or link to read about all the ClassOrganizer stuff ?
no... all the ClassOrganizer stuff is so old that it seriously needs to be replaced... it looks like it comes from a time when the only collection available was an Array :-) It's very badly done from today's OO design perspective. Hard to understand, difficult to use (I can never remember how to get all classes of one category, for example). And it's not OO. Categories are not Object, for example. They are just symbols. Asking for classes of one category gives you names, not classes. In addition it's slow. e.g. we discovered in 3.9 that asking a class for it's category needed to iterate over the whole array, making it very slow. Than we saw that there was an unused "category" iVar in Class, which we used to cache the category. MC suddenly became 2 times faster in loading. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On 11 March 2010 17:12, Marcus Denker <marcus.denker@inria.fr> wrote:
On Mar 11, 2010, at 3:58 PM, Mariano Martinez Peck wrote:
 What do you think?
allClassesDo: [:class | class organization setDefaultList: #() ]
Seems to be more complicated than that. There is a problem with the notifications....
Now, I added to ClassOrganizer the method
putAllSelectorInDefaultCategory   self elementArray do: [:each | self classify: each under: self class default suppressIfDefault: false]
And then I evaluate:
Smalltalk allClassesDo: [:each | each organization putAllSelectorInDefaultCategory]. Smalltalk allClassesDo: [:each | each organization removeEmptyCategories]. Smalltalk garbageCollect.
That seems to work. I mean, all method of all classes uses the same category. As it is  a ByteSymbol, there is only one instance. However, after saving the image, is it is bigger than before evaluating that....
there is of course something I am not understanding. Is there some chapter, tutorial or link to read about all the ClassOrganizer stuff ?
no... all the ClassOrganizer stuff is so old that it seriously needs to be replaced... it looks like it comes from a time when the only collection available was an Array :-) It's very badly done from today's OO design perspective. Hard to understand, difficult to use (I can never remember how to get all classes of one category, for example). And it's not OO. Categories are not Object, for example. They are just symbols. Asking for classes of one category gives you names, not classes.
In addition it's slow. e.g. we discovered in 3.9 that asking a class for it's category needed to iterate over the whole array, making it very slow. Than we saw that there was an unused "category" iVar in Class, which we used to cache the category. MC suddenly became 2 times faster in loading.
Marcus, once before, i did examined the ClassOrganizer implementation. Yes, it is slow, complex and using Arrays. But i know why - it was designed for compactness to have a small memory footprint. So, all of good things, like simplicity, good OO etc etc was sacrificed towards having less memory in image.
    Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Den 11.03.2010 11:05, skrev Mariano Martinez Peck:
On Thu, Mar 11, 2010 at 10:47 AM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
2010/3/11 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>:
I presented some ideas about it in the past, but since it requires a substantial efforts to make it done, they weren't get past much the state of an ideas. :)
I would like to hear those ideas.
http://n4.nabble.com/Source-code-management-my-vision-Was-Re-Why-a-package-m... Some grand ideas indeed :) Cheers, Henry
This is not bad or good. A lot of the design decision where taken for extremely small machines (80k loom) Now marcus would say that he wants everything in memory. :) And I would say can we get the best of both worlds having everything in memory if we want or on disc. Stef
Hi folks. I was playing a bit with the ClassOrganizer stuff. I thought that class comments were in the image, but it seems they are kept in the .source. Is this correct ?
They are ALWAYS kept in the .sources?
I know that the class of the instancia variable "classComment" in the ClassOrganizer can be Text, ByteString or even RemoteString. I though that only those who have RemoteString were in .sources but it seems all are there. I am correct ? is this the desired behavior ?
Thanks!
Mariano _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mar 11, 2010, at 11:21 AM, Stéphane Ducasse wrote:
This is not bad or good. A lot of the design decision where taken for extremely small machines (80k loom) Now marcus would say that he wants everything in memory. :)
I would that my 13inch *laptop* has 4GB RAM *today* and that research should be about inventing the Future... :-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
:) We know you start to work the mega huge OO M :) Stef On Mar 12, 2010, at 1:06 PM, Marcus Denker wrote:
On Mar 11, 2010, at 11:21 AM, Stéphane Ducasse wrote:
This is not bad or good. A lot of the design decision where taken for extremely small machines (80k loom) Now marcus would say that he wants everything in memory. :)
I would that my 13inch *laptop* has 4GB RAM *today* and that research should be about inventing the Future...
:-)
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Henrik Johansen -
Igor Stasenko -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse