[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:
http://blogs.msdn.com/b/ericlippert/archive/2012/06/08/persistence-facades-and-roslyn-s-red-green-trees.aspx

frank

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