Hi Stephane,<br><br><div class="gmail_quote">On Sat, May 7, 2011 at 1:35 AM, stephane ducasse <span dir="ltr"><<a href="mailto:stephane.ducasse@gmail.com">stephane.ducasse@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Eliot<br>
<br>
may be this is because of bad communication medium but each time somebody is mentioning something<br>
not really working your main messages over the months is do not fix it.<br>
I do not think that this is really the way to build a community around Cog.<br></blockquote><div><br></div><div>You need to understand the technical issue here before you can say that I'm saying "do not fix it". I am /sure/ that there is no bug here to be fixed, and that "fixing" the supposed bug will make things worse for no benefit. I also /do not/ leave bugs unfixed. Recently I have fixed shallow copy for contexts, objects-as-methods, locales on linux and many more. So it is unfair to accuse me of not fixing bugs, and a little intellectually lazy of you in this case not to understand the issue that is behind my saying we should not "fix" this. Pl;ease see Andreas' message and my reply to it.</div>
<div><br></div><div>best,</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
At least to me the messages is that you are not really interested in that. I can understand that you are busy<br>
but there is nothing like little issues: because little issues make hard stupid people to move and since<br>
stupid people are the masses then this means that nothing move. This is ok too. but I wanted<br>
to let you know the message we receive.<br>
I should say that I'm really concerned about the truck factor around Cog. If you go to work on something else<br>
what will happen. And imagine that nothing improves except speed for a couple of years and nothing<br>
has the knowledge to understand the system and you leave then we would have lost of couple of year<br>
making sure that the system is slowly improving and not only from the speed perspective.<br>
<br>
Now about uncompacting classes<br>
<br>
- I know that making classes uncompact was working when benjamin was working on hazelnut<br>
because he used that to simplify his approach.<br>
Now this is not working anymore so instead of working on the bootstrap we will have to understand<br>
what is wrong and turn around.<br>
<br>
- Second if simple stuff do not work or cannot even be changed how can we think about<br>
bigger changes.<br>
<br>
- Third we need a flexible system for making experiments. If we remove that from the system then<br>
we should all better go and do ruby or python. May be at the end this what we should do.<br>
<br>
- Camillo started to work on immutable objects and we check and we have 13 compact classes but 5 bits<br>
so it may make sense to keep 4 bits for compact classes and 2 bits for experiments (which are really<br>
important to us. it would mean 3 bits since immutability is important and we would like to have it).<br>
Then this means that we can live happily waiting for a new object format.<br>
<br>
<br>
Stef<br>
<div><div></div><div class="h5"><br>
> ><br>
> > and your point would be?<br>
> ><br>
> it needs to be fixed.<br>
><br>
> No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact.<br>
><br>
> Because if we can't do:<br>
><br>
> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each<br>
> becomeUncompact]].<br>
><br>
> then we cant:<br>
><br>
> VM getRidOfCompactClassesNotion<br>
><br>
> :)<br>
><br>
> That will be done by producing a new GC and a new image format, not by tinkering with compact classes in the current GC. Right?<br>
><br>
> > On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
> >><br>
> >> Hi, i tried to do a simple:<br>
> >><br>
> >> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each<br>
> >> becomeUncompact]]<br>
> >><br>
> >> and it crashing the image.<br>
> >> I tried to do this for individual classes.<br>
> >><br>
> >><br>
> >> CompiledMethod, ByteString, BlockClosure, BlockContext ,<br>
> >> seems working ok.<br>
> >><br>
> >> MethodContext, LargePositiveInteger, LargeNegativeInteger, Float<br>
> >> crashes the image.<br>
> >><br>
> >> i also tried following:<br>
> >><br>
> >> [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each<br>
> >> becomeUncompact]]<br>
> >> ] forkAt: Processor highestPriority<br>
> >><br>
> >> but it didn't helped much.<br>
> >><br>
> >> Also, i saved image after couple successfull #becomeUncompact steps..<br>
> >> and now VM cannot open image, most probably<br>
> >> because it fails on 'assumptions check' defined in #checkAssumedCompactClasses<br>
> >><br>
> >> --<br>
> >> Best regards,<br>
> >> Igor Stasenko AKA sig.<br>
> ><br>
> ><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Best regards,<br>
> Igor Stasenko AKA sig.<br>
><br>
<br>
</div></div></blockquote></div><br>