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

H. Hirzel hannes.hirzel at gmail.com
Thu Oct 11 13:57:52 UTC 2012

On 10/11/12, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.

Why should I want to do this?  I want to _use_ PetitParser as is and I
do not want to temper with it's implementation.

> What PPCompositParser does is one of the things why i don't like
> PetitParser.

I perceive it as a very elegant solution. A well integrated of a DSL
into Smalltalk..

Easy to use.

And I like Lukas' PhD thesis. It's a pity that Helvetia is not
available in newer versions of Pharo.

> Sure, i don't want to discourage from using it, just my personal taste.

Yes, fine.  :-)


>> frank
> --
> Best regards,
> Igor Stasenko.

More information about the Vm-dev mailing list