[squeak-dev] Re: [Pharo-dev] ||

Frank Shearar frank.shearar at gmail.com
Thu Feb 5 15:52:52 UTC 2015

On 5 February 2015 at 15:35, Levente Uzonyi <leves at elte.hu> wrote:
> 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.

C#'s Roslyn does this:


>> 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

More information about the Squeak-dev mailing list