[squeak-dev] Re: [Pharo-dev] ||
leves at elte.hu
Thu Feb 5 15:35:50 UTC 2015
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.).
More information about the Squeak-dev