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

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> On Thu, Mar 11, 2010 at 10:47 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> 2010/3/11 Mariano Martinez Peck <[hidden email]>:
>> > 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
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

>
> 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.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project