On Thu, 5 Feb 2015, Marcus Denker wrote:

>
>> On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker at inria.fr> wrote:
>>
>>
>>> On 04 Feb 2015, at 22:04, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>> A single parser is a nice goal, but performance is top priority for Shout, because it should do it's job real-time. When it starts lagging behind, then people just turn it off, because it doesn't help them.
>>> Can those parsers (SHRBTextStyler and a Smalltalk parser written using PetitParser) parse an average method in less than 20ms on an average machine?
>>
>> I have not yet benchmarked it… PetitParser as it is is too slow, but we will soon have a faster version (factor 10).
>>
>> We should do some benchmarks. For using, it seems ok. With a fast machine + JIT, which does not say much of course.
>> (there is a setting 'AST based coloring’ in Pharo3 and Pharo4, but it is turned off by default).
>>
>> One thing that is nice with the AST is that it can be used for other things, too. e.g. in Pharo we have a menu that is defined
>> by the AST nodes and structural navigation in the editor.
>>

Rebuilding the whole AST after every keystroke is possible, but keeping 
it real-time is a bit challenging.

I would love to see an editor, which works on the AST directly - aka it 
maps the source code to AST nodes, and just updates the smallest possible 
subtree at each keystroke. Implementing such editor has it's challenges 
ofc, like typing a single character can invalidate the whole code, but 
the editor should keep the AST somehow in that case too.

>
> Another way to see it: How would the original Smalltalk be designed if they would have had 4GB RAM in 1978?
>
> What fascinates me still is that Smalltalk used the existing resources (even building their own machines) to an
> extreme, while today we are obsessed to find reasons why we can not do anything that makes the system
> slower or use more memory than yesterday. And that even with resources growing every year…
>
> This is why we e.g. now have a meta object describing every instance variable in Pharo. I am sure there are people
> who will see these ~7000 objects as pure waste… while I would say that we have already *now* the resources to be
> even more radical.

I think this is a different thing. Improvements are always welcome, as 
long as they don't step on your toes.

About Slots: I don't see their advantages yet (other than bitfields, but 
those are so rare in Smalltalk that I implement them causes no trouble. 
And they are just an optimization over using multiple fields.).

Levente

>
> 	Marcus
>
>
>