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

Eliot Miranda eliot.miranda at gmail.com
Sun May 8 19:02:47 UTC 2011

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.


> Stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110508/a3c3b9a8/attachment.htm

More information about the Vm-dev mailing list