[Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs

[Igor Stasenko]

On 8 May 2011 21:02, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Sun, May 8, 2011 at 3:24 AM, stephane ducasse <stephane.ducasse at gmail.com> wrote:
>>
>> > Therefore, some classes
>> >>> cannot be made non-compact in Cog, and that is a perfectly good tradeoff.
>> >> In theory. But you have no proof now.
>> >> Why i should trust you/Eliot/anyone else, without being able to test it?
>> >
>> > You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't...
>>
>> Hi andreas
>>
>> your points are totally valid. Now the point is that it does not look like we are building a community
>> around Cog, more a sect and this is sad - even if eliot is doing his best to answer the stupid questions of people like mariano. I organized the school deep into smalltalk and payed eliot for his talks just to spread the knowledge. For me this is important to discuss and that knowledge is spread on pros and cons. So at least the links you sent were good.
>>
>> Now personally I do not use Cog yet just to see how far I need to be bound to something
>> complex and understood by two persons. This is my way to manage my own risks in my business.
>> So making pharo fast on the interpreter is a reasonable approach too. I think that our little community
>> should realize that, else one day it can be hurt.
>
> How many people really understand the VisualWorks JIT or any other high-performance VM?  In my experience few people have the interest, skills and experience in language design and implementation and low-level computer architecture.  There are relatively few really good VM engineers compared to the number of really good high-level object-oriented programmers.  That matches perfectly with the far smaller number of VMs than interesting object-oriented programs.  A VM, like any other piece of core infrastructure has a very high rate of use.  I don't see anything unusual, surprising or worrying about this.  How is it that different from Ian, Andreas, John and David as the keepers of the Interpreter before Cog?
> Further Nicholas demonstrated this week that with a little intellectual effort someone really good can come to understand Cog and make a contribution quite quickly.  Instead of all this FUD about there not being a community around Cog why not try and play with it, as Nicholas has successfully, and we can start building the community.  I'm not going to respond well to bullying tactics.  I respond well to real collaboration (thanks Marcus, Nicholas, Levente, Andreas, Igor, Mariano and all who have found and reported bugs).
>>
>> This is sad that we do not succeed to build a set up where the community could pay eliot to work on Cog
>> but this is like that so far. I tried some setup but so far this is not working. Now even if this would be the case, how a set of companies would invest money  in something that only one guy or two understand. I think that if we do not minimize the truck factor then we have a high risk profile that investors should be able to understand quite well and run away from us (or they are blind which is better). After we should not cry when "rewrite everything in java" arrives (even if it may be for other less obvious reasons). As an investor of the money for my kids I tend to be much more picky about reality and risks. Having kids is a good way to check reality.
>
> Why express such FUD?  I am happily at Cadence again and will have the freedom to spend significant time on Cog (with Newspeak also).  And there are a few other potential places I could end up working on Cog.  Meanwhile people like Nicholas will gain a better understanding of Cog, people like Mariano will produce ever more comprehensible documentation, people like Marcus will evolve it in really interesting performance directions and people like Igor will evolve its basic architecture away from a monolithic simulated-in-Smalltalk system to a true live bootstrap.  Others will work on the FFI and Cog will evolve into a key component of a powerful open-source Smalltalk platform.  The community /is/ building.  Relax.

Be cool, Stephane.
JIT is more complex, sure thing. Entry point is high. Sure thing.
But the road overcomes a walking one. So little steps at a time.
It is just a smalltalk code, after all.
Yes, it is slang, and because its a slang, its even more 'stupidified'
code than usual smalltalk.
Yes, its more tedious to code in 'slang mode' , because you need to
make sure it will be translated, but it is still better than writing
everything in C.



-- 
Best regards,
Igor Stasenko AKA sig.