Class comments are in the .sources ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Class comments are in the .sources ?

Mariano Martinez Peck
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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Igor Stasenko
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.
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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Mariano Martinez Peck


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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Stéphane Ducasse
In reply to this post by Mariano Martinez Peck
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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Igor Stasenko
In reply to this post by Mariano Martinez Peck
2010/3/11 Mariano Martinez Peck <[hidden email]>:

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

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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Henrik Sperre Johansen
In reply to this post by Mariano Martinez Peck

Den 11.03.2010 11:05, skrev Mariano Martinez Peck:


On Thu, Mar 11, 2010 at 10:47 AM, Igor Stasenko <[hidden email]> wrote:
2010/3/11 Mariano Martinez Peck <[hidden email]>:

 
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-management-system-td1566103.html#a1566103

Some grand ideas indeed :)

Cheers,
Henry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Mariano Martinez Peck
In reply to this post by Igor Stasenko

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



--
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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Marcus Denker-4

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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Igor Stasenko
On 11 March 2010 17:12, Marcus Denker <[hidden email]> 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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Marcus Denker-4
In reply to this post by Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Class comments are in the .sources ?

Stéphane Ducasse
:)
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
> [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