[Vm-dev] HackerNews + vm-dev = a lightbulb saying "STACK!"

Igor Stasenko siguctua at gmail.com
Thu Oct 11 10:54:22 UTC 2012

On 11 October 2012 11:42, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 11 October 2012 08:45, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> On 10/11/12, Igor Stasenko <siguctua at gmail.com> wrote:
>>> On 10 October 2012 22:55, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>> On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney <colin at wiresong.com>
>>>> wrote:
>>>>> On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda <eliot.miranda at gmail.com>
>>>>> wrote:
>>>>> > Right now I'm redesigning the bytecode set to lift limits on branch
>>>>> > distances, number of literals, and number of inst vars.  So a small
>>>>> > increment.
>>>>> I suppose that Newspeak is different from Smalltalk in terms of the
>>>>> size and complexity of methods that it encourages. It could be that
>>>>> the existing limits are blocking the development of Newspeak, and
>>>>> obviously legacy code is much less of an issue for Newspeak than
>>>>> Squeak.
>>>> Not newspeak.  But within Cadence we have internal customers that are
>>>> hitting limits we must lift.
>>> <trolling>
>>> perhaps then it would cost less to customers to attend a small course
>>> on programming basics then?
>>> </trolling>
>>> The biggest bloat of inst vars, which i ever seen in smalltalk is
>>> Interpreter & ObjectMemory classes.
>>> And this is mainly because this code has to be translated to C due to
>>> limitations/design of VMMaker.
>>> But VMMaker is special. A regular code don't requires so much state
>>> kept per single object.
>>> Now, it is hard to imagine, how much more complex the software must be
>>> that it requires even more instances in class than those two?
>>> Especially when you saying it is not because of Newspeak.
>>> These news saddening me a lot.
>> The answer is
>> "It depends".
>> Normally having more 255+ instance variables is a sign of bad design.
>> But not always. There are exceptions. It depends on the problem domain
>> and business case.
>> I actually welcome that this limitation is lifted because of
>> PetitParser (though Lukas has a workaround). At the moment I have not
>> hit the limit yet.
> Is that from a large PPCompositParser? (Because each rule manifests as
> an instvar initialised as a delegate parser. Delegates are lazily
> resolved post initialisation.)

oh, man, that's lame. If/when you hit that limit, you can always
refactor the code to use dictionary
to hold/cache parsers instead of inst vars.
What PPCompositParser does is one of the things why i don't like PetitParser.
Sure, i don't want to discourage from using it, just my personal taste.

> frank

Best regards,
Igor Stasenko.

More information about the Vm-dev mailing list