||

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

||

Eliot Miranda-2
Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in

convertInstances
| new old |
old := Binding allInstances.
new := old collect: [:ea | ClassBinding key: ea key value: ea value].
old elementsForwardIdentityTo: new.
old := ReadOnlyVariableBinding allInstances.
new := old collect: [:ea | ClassBinding key: ea key value: ea value].
old elementsForwardIdentityTo: new.
Environment allInstancesDo:
[:env |
#('contents' 'bindings' 'public' 'undeclared') do:
=> [:var || dict |
old := Array new writeStream.
new := Array new writeStream.
dict := env instVarNamed: var.
dict associations do:
[:binding |
binding class == Association ifTrue:
[old nextPut: binding.
new nextPut: binding key => binding value]].
old contents elementsForwardIdentityTo: new contents]]

is legal but highlighted as a syntax error by shout.

What do you prefer, editing the source to | | or fixing Shout to accept the syntax?  The right answer should be fixing shout but the fix will be ugly because || is a binary selector and so this will need to be special cased.
--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] ||

David T. Lewis
On Mon, Feb 02, 2015 at 12:47:45PM -0800, Eliot Miranda wrote:

> Hi All,
>
>     code as in the double bars forming the end of block arguments and the
> beginning of block temporaries in
>
> convertInstances
> | new old |
> old := Binding allInstances.
> new := old collect: [:ea | ClassBinding key: ea key value: ea value].
> old elementsForwardIdentityTo: new.
>  old := ReadOnlyVariableBinding allInstances.
> new := old collect: [:ea | ClassBinding key: ea key value: ea value].
> old elementsForwardIdentityTo: new.
>  Environment allInstancesDo:
> [:env |
> #('contents' 'bindings' 'public' 'undeclared') do:
> => [:var || dict |
> old := Array new writeStream.
> new := Array new writeStream.
> dict := env instVarNamed: var.
> dict associations do:
> [:binding |
> binding class == Association ifTrue:
> [old nextPut: binding.
> new nextPut: binding key => binding value]].
> old contents elementsForwardIdentityTo: new contents]]
>
> is legal but highlighted as a syntax error by shout.
>
> What do you prefer, editing the source to | | or fixing Shout to accept the
> syntax?  The right answer should be fixing shout but the fix will be ugly
> because || is a binary selector and so this will need to be special cased.

If anything needs to be fixed, I would vote for fixing Shout. The syntax is
legal, and to me it intuitively looks like it *should* be legal.

On the other hand, adding some whitespace between the vertical bars is a
good idea for readability, even if it is not a necessary part of the syntax.
So it does not bother me if Shout complains about the missing whitespace.
But I have to admit that it is confusing if Shout displays an apparent
syntax error when in fact nothing is wrong with the syntax.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4
In reply to this post by Eliot Miranda-2

On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):



In general, I really am convinced that we should continue to reduce the number of Smalltalk parsers
in the system. Imagine there would be only *one*, then bugs like this would never happen, we would
have less code to maintain and every improvement would benefit directly all subsystems that use 
the Parser or the AST.

We already did that for the tools (RB) and the Compiler. We use the handwritten RBParser for now
(I would like to use PetitParser…). 
The next would be to replace the Shout Parser+Tokenstream… we already in all tools create an AST
as soon as you select a method anyway. (the is for per-AST-Node Navigation + the “suggestions” menu).

RBParser already has #parseFaultyMethod:, this means it can generate an AST even for incomplete input
(with an error node). e.g. you can parse the expression ‘1+’:


There is already a SHRBTextStyler which uses it, we should finish that and replace the Shout parser.

Marcus


Reply | Threaded
Open this post in threaded view
|

Re: ||

Uko2
Yes, I’ve reported that already and it was fixed in Pharo 4

Uko

On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:


On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):


<Untitled.png>

In general, I really am convinced that we should continue to reduce the number of Smalltalk parsers
in the system. Imagine there would be only *one*, then bugs like this would never happen, we would
have less code to maintain and every improvement would benefit directly all subsystems that use 
the Parser or the AST.

We already did that for the tools (RB) and the Compiler. We use the handwritten RBParser for now
(I would like to use PetitParser…). 
The next would be to replace the Shout Parser+Tokenstream… we already in all tools create an AST
as soon as you select a method anyway. (the is for per-AST-Node Navigation + the “suggestions” menu).

RBParser already has #parseFaultyMethod:, this means it can generate an AST even for incomplete input
(with an error node). e.g. you can parse the expression ‘1+’:

<Untitled.png>

There is already a SHRBTextStyler which uses it, we should finish that and replace the Shout parser.

Marcus



Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4
In reply to this post by Marcus Denker-4

On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:


On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):

I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there
I will search for it.

Another question: In the code I saw. ReadOnlyVariableBinding. I removed that in Pharo relatively early as it was not used:
half of the classes were stored that binding (old ones) all newer ones where just associations.
The code to make a binding "read only" was never called.

Is this now used in Squeak? Is it worth the complexity?

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4

On 03 Feb 2015, at 18:36, Marcus Denker <[hidden email]> wrote:


On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:


On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):

I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there
I will search for it.

It seems to be this one:


integrated in Pharo4 update #420

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: ||

Levente Uzonyi-2
In reply to this post by Marcus Denker-4
On Tue, 3 Feb 2015, Marcus Denker wrote:

>
>       On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:
>
>
>       On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>     code as in the double bars forming the end of block arguments and the beginning of block temporaries in
>
>
> This is fixed in Pharo4 (I think we did that in Pharo3 already):
>
> I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there…
> I will search for it.
>
> Another question: In the code I saw. ReadOnlyVariableBinding. I removed that in Pharo relatively early as it was not used:
> half of the classes were stored that binding (old ones) all newer ones where just associations.
> The code to make a binding "read only" was never called.
>
> Is this now used in Squeak? Is it worth the complexity?
Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of
classes are instances of the ClassBinding class.
Without using separate class it's a bit cumbersome (and less OO) to decide
if an assignment to a global variable should be allowed or not. E.g.:

  Foo := 1.

should work if Foo is a global, but not a behavior. It should raise an
error if it's a behavior.

Levente

>
> Marcus
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ||

Eliot Miranda-2
In reply to this post by Marcus Denker-4
Hi Marcus,

    thanks!  When I visit the fogbugz page there's a line that says "slice in inbox" but no link to any file containing the slice I can see.  How do I track down the slice file itself?

On Tue, Feb 3, 2015 at 9:48 AM, Marcus Denker <[hidden email]> wrote:

On 03 Feb 2015, at 18:36, Marcus Denker <[hidden email]> wrote:


On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:


On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):

I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there
I will search for it.

It seems to be this one:


integrated in Pharo4 update #420

Marcus



--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4


On Tue, Feb 3, 2015 at 7:06 PM, Eliot Miranda <[hidden email]> wrote:
Hi Marcus,

    thanks!  When I visit the fogbugz page there's a line that says "slice in inbox" but no link to any file containing the slice I can see.  How do I track down the slice file itself?

The slice has the issue number as part of it's name. So you can just search for that in the inbox.

To the the changes, sometimes I just download the version one before integration ( 40 #419 here) from http://files.pharo.org/image/40/ and do a merge there.

     Marcus

 
On Tue, Feb 3, 2015 at 9:48 AM, Marcus Denker <[hidden email]> wrote:

On 03 Feb 2015, at 18:36, Marcus Denker <[hidden email]> wrote:


On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:


On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,

    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):

I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there
I will search for it.

It seems to be this one:


integrated in Pharo4 update #420

Marcus



--
best,
Eliot



--
Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4
In reply to this post by Levente Uzonyi-2


On Tue, Feb 3, 2015 at 6:51 PM, Levente Uzonyi <[hidden email]> wrote:
On Tue, 3 Feb 2015, Marcus Denker wrote:


      On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:


      On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi All,
    code as in the double bars forming the end of block arguments and the beginning of block temporaries in


This is fixed in Pharo4 (I think we did that in Pharo3 already):

I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there…
I will search for it.

Another question: In the code I saw. ReadOnlyVariableBinding. I removed that in Pharo relatively early as it was not used:
half of the classes were stored that binding (old ones) all newer ones where just associations.
The code to make a binding "read only" was never called.

Is this now used in Squeak? Is it worth the complexity?

Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of classes are instances of the ClassBinding class.
Without using separate class it's a bit cumbersome (and less OO) to decide if an assignment to a global variable should be allowed or not. E.g.:

        Foo := 1.

should work if Foo is a global, but not a behavior. It should raise an error if it's a behavior.


I thought this is how ReadOnlyVariableBinding was supposed to be used: classes would use it, globals not.

   Marcus



Reply | Threaded
Open this post in threaded view
|

Re: ||

Levente Uzonyi-2
On Wed, 4 Feb 2015, Marcus Denker wrote:

>
>
> On Tue, Feb 3, 2015 at 6:51 PM, Levente Uzonyi <[hidden email]> wrote:
>       On Tue, 3 Feb 2015, Marcus Denker wrote:
>
>
>                   On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:
>
>
>                   On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:
>
>             Hi All,
>                 code as in the double bars forming the end of block arguments and the beginning of block temporaries in
>
>
>             This is fixed in Pharo4 (I think we did that in Pharo3 already):
>
>             I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there…
>             I will search for it.
>
>             Another question: In the code I saw. ReadOnlyVariableBinding. I removed that in Pharo relatively early as it was not used:
>             half of the classes were stored that binding (old ones) all newer ones where just associations.
>             The code to make a binding "read only" was never called.
>
>             Is this now used in Squeak? Is it worth the complexity?
>
>
> Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of classes are instances of the ClassBinding class.
> Without using separate class it's a bit cumbersome (and less OO) to decide if an assignment to a global variable should be allowed or not. E.g.:
>
>         Foo := 1.
>
> should work if Foo is a global, but not a behavior. It should raise an error if it's a behavior.
>
>
> I thought this is how ReadOnlyVariableBinding was supposed to be used: classes would use it, globals not.
Probably that was the goal, but it was not implemented correctly, and the
name ClassBinding fits better the use case than ReadOnlyVariableBinding.

Levente

>
>    Marcus
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ||

Levente Uzonyi-2
In reply to this post by Marcus Denker-4
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?

Levente

On Tue, 3 Feb 2015, Marcus Denker wrote:

>
>> On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi All,
>>
>>     code as in the double bars forming the end of block arguments and the beginning of block temporaries in
>>
>
> This is fixed in Pharo4 (I think we did that in Pharo3 already):
>
>
>
>
> In general, I really am convinced that we should continue to reduce the number of Smalltalk parsers
> in the system. Imagine there would be only *one*, then bugs like this would never happen, we would
> have less code to maintain and every improvement would benefit directly all subsystems that use
> the Parser or the AST.
>
> We already did that for the tools (RB) and the Compiler. We use the handwritten RBParser for now
> (I would like to use PetitParser…).
> The next would be to replace the Shout Parser+Tokenstream… we already in all tools create an AST
> as soon as you select a method anyway. (the is for per-AST-Node Navigation + the “suggestions” menu).
>
> RBParser already has #parseFaultyMethod:, this means it can generate an AST even for incomplete input
> (with an error node). e.g. you can parse the expression ‘1+’:
>
>
>
> There is already a SHRBTextStyler which uses it, we should finish that and replace the Shout parser.
>
> Marcus
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ||

Richard Sargent
Administrator
In reply to this post by Levente Uzonyi-2
Levente Uzonyi-2 wrote
On Tue, 3 Feb 2015, Marcus Denker wrote:

>
>       On 03 Feb 2015, at 09:17, Marcus Denker <[hidden email]> wrote:
>
>
>       On 02 Feb 2015, at 21:47, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>     code as in the double bars forming the end of block arguments and the beginning of block temporaries in
>
>
> This is fixed in Pharo4 (I think we did that in Pharo3 already):
>
> I should search the issue in the issue tracker… it seems to be Pharo4, so just 1296 closed issues to check there…
> I will search for it.
>
> Another question: In the code I saw. ReadOnlyVariableBinding. I removed that in Pharo relatively early as it was not used:
> half of the classes were stored that binding (old ones) all newer ones where just associations.
> The code to make a binding "read only" was never called.
>
> Is this now used in Squeak? Is it worth the complexity?

Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of
classes are instances of the ClassBinding class.
Without using separate class it's a bit cumbersome (and less OO) to decide
if an assignment to a global variable should be allowed or not. E.g.:

  Foo := 1.

should work if Foo is a global, but not a behavior. It should raise an
error if it's a behavior.
I have mixed feelings about that. In most Smalltalks one can write something like the following and expect it to work.

| original |
original := SomeClass.
[SomeClass := SomeReplacementClass.
... some code involving SomeClass (typically a passed in Block) ...
] ensure: [SomeClass := original]

That is, the name of the thing is not the thing itself.

Of course, as long as one could write Smalltalk at: #SomeClass put: SomeReplacementClass, it would still be possible to achieve the same effect. (And of course, "Smalltalk" could be any namespace.)


Levente

>
> Marcus
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4
In reply to this post by Levente Uzonyi-2

> On 04 Feb 2015, at 22:04, Levente Uzonyi <[hidden email]> 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.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4
In reply to this post by Richard Sargent

>>>
>>> Is this now used in Squeak? Is it worth the complexity?
>>
>> Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of
>> classes are instances of the ClassBinding class.
>> Without using separate class it's a bit cumbersome (and less OO) to decide
>> if an assignment to a global variable should be allowed or not. E.g.:
>>
>> Foo := 1.
>>
>> should work if Foo is a global, but not a behavior. It should raise an
>> error if it's a behavior.
>
> I have mixed feelings about that. In most Smalltalks one can write something
> like the following and expect it to work.
>
> | original |
> original := SomeClass.
> [SomeClass := SomeReplacementClass.
> ... some code involving SomeClass (typically a passed in Block) ...
> ] ensure: [SomeClass := original]
>
> That is, the name of the thing is not the thing itself.
>
> Of course, as long as one could write /Smalltalk at: #SomeClass put:
> SomeReplacementClass/, it would still be possible to achieve the same
> effect. (And of course, "Smalltalk" could be any namespace.)
>

I think the original idea was to make the system more resilient for end-user
Scripting. To make sure people do not do by accident

        True := nil.


        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: ||

Marcus Denker-4
In reply to this post by Marcus Denker-4

> On 05 Feb 2015, at 10:04, Marcus Denker <[hidden email]> wrote:
>
>
>> On 04 Feb 2015, at 22:04, Levente Uzonyi <[hidden email]> 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.
>

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.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: ||

Thierry Goubier


2015-02-05 10:12 GMT+01:00 Marcus Denker <[hidden email]>:

> On 05 Feb 2015, at 10:04, Marcus Denker <[hidden email]> wrote:
>
>
>> On 04 Feb 2015, at 22:04, Levente Uzonyi <[hidden email]> 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.
>

Another way to see it: How would the original Smalltalk be designed if they would have had 4GB RAM in 1978?

Badly for today's machines :)
 

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…

You're spoiled by your nice and expensive macbooks :)

Honestly, on some of today's machines, you'd better avoid long methods or GT tools stuff because they are slow.

SmaCC code generation is slow.

PluggableTreeMorph is slow.

Nautilus is slow.

Loading large configurations is slow.

Roassal complex graphs are slow.

Serge's modeling stuff is slow.

PetitParser has performance problems.

BitBlt is slow (and Cairo has bugs).
 

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.

Being radical in the context of Pharo is offering to remove stuff or layers :):)

Thierry

Reply | Threaded
Open this post in threaded view
|

Re: ||

Sven Van Caekenberghe-2

> On 05 Feb 2015, at 10:46, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-02-05 10:12 GMT+01:00 Marcus Denker <[hidden email]>:
>
> > On 05 Feb 2015, at 10:04, Marcus Denker <[hidden email]> wrote:
> >
> >
> >> On 04 Feb 2015, at 22:04, Levente Uzonyi <[hidden email]> 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.
> >
>
> Another way to see it: How would the original Smalltalk be designed if they would have had 4GB RAM in 1978?
>
> Badly for today's machines :)
>  
>
> 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…
>
> You're spoiled by your nice and expensive macbooks :)
>
> Honestly, on some of today's machines, you'd better avoid long methods or GT tools stuff because they are slow.
>
> SmaCC code generation is slow.
>
> PluggableTreeMorph is slow.
>
> Nautilus is slow.
>
> Loading large configurations is slow.
>
> Roassal complex graphs are slow.
>
> Serge's modeling stuff is slow.
>
> PetitParser has performance problems.
>
> BitBlt is slow (and Cairo has bugs).
>  
>
> 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.
>
> Being radical in the context of Pharo is offering to remove stuff or layers :):)
>
> Thierry

It is obviously a compromise (or a continuum) between abstractions and performance.

But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later.



Reply | Threaded
Open this post in threaded view
|

Re: ||

kilon.alios
And there is also the matter of hardware evolution.

When I was running Pharo on my 2007 imac 20'' with dual core 2.GHZ , Morphic was slow. And by slow I mean that I could see it was struggling to move windows around. I could see windows flickering trying to render themselves moving around.

But now with my 2014 imac even though the screen is double the size and the resolution much bigger (27'' retina) , Morphic is now quite fast. The reason is of course the fact that the CPU is a quad core at 3 Ghz thats almost a 3x times increase in speed and it really shows.

Even when Pharo take full the huge area of 27'' Morphic is responsive and quite fast. 

8 cores are not much further down the road either. And unlike the native GUI of MACOS , Morphic does not take advantage of GPU acceleration that can offer speed us even 10 times compared to a modern CPU. 

So I think that even if we keep performance in Pharo at same level, things will get noticeably better through the evolution of hardware alone. 

I do agree that Efficiency and especially ease of use must be the main focus.

On Thu, Feb 5, 2015 at 11:55 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 05 Feb 2015, at 10:46, Thierry Goubier <[hidden email]> wrote:
>
>
>
> 2015-02-05 10:12 GMT+01:00 Marcus Denker <[hidden email]>:
>
> > On 05 Feb 2015, at 10:04, Marcus Denker <[hidden email]> wrote:
> >
> >
> >> On 04 Feb 2015, at 22:04, Levente Uzonyi <[hidden email]> 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.
> >
>
> Another way to see it: How would the original Smalltalk be designed if they would have had 4GB RAM in 1978?
>
> Badly for today's machines :)
>
>
> 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…
>
> You're spoiled by your nice and expensive macbooks :)
>
> Honestly, on some of today's machines, you'd better avoid long methods or GT tools stuff because they are slow.
>
> SmaCC code generation is slow.
>
> PluggableTreeMorph is slow.
>
> Nautilus is slow.
>
> Loading large configurations is slow.
>
> Roassal complex graphs are slow.
>
> Serge's modeling stuff is slow.
>
> PetitParser has performance problems.
>
> BitBlt is slow (and Cairo has bugs).
>
>
> 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.
>
> Being radical in the context of Pharo is offering to remove stuff or layers :):)
>
> Thierry

It is obviously a compromise (or a continuum) between abstractions and performance.

But there should remain a focus on efficiency (not just speed but also memory), it is hard to fix these things years later.




Reply | Threaded
Open this post in threaded view
|

Re: ||

Thierry Goubier


2015-02-05 11:14 GMT+01:00 kilon alios <[hidden email]>:
And there is also the matter of hardware evolution.

When I was running Pharo on my 2007 imac 20'' with dual core 2.GHZ , Morphic was slow. And by slow I mean that I could see it was struggling to move windows around. I could see windows flickering trying to render themselves moving around.

But now with my 2014 imac even though the screen is double the size and the resolution much bigger (27'' retina) , Morphic is now quite fast. The reason is of course the fact that the CPU is a quad core at 3 Ghz thats almost a 3x times increase in speed and it really shows.

Even when Pharo take full the huge area of 27'' Morphic is responsive and quite fast. 

Which means if I see you complaining of speed issues, then it must be really bad :)

Thierry
1234