||
Locked
12
12
 
|
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 |
|
|
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 |
|
|
In reply to this post by Eliot Miranda-2
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 |
|
|
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 |
|
|
It seems to be this one: integrated in Pharo4 update #420 Marcus |
|
|
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? 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 > > |
|
|
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:
best,
Eliot |
|
|
On Tue, Feb 3, 2015 at 7:06 PM, Eliot Miranda <[hidden email]> wrote:
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
|
|
|
In reply to this post by Levente Uzonyi-2
On Tue, Feb 3, 2015 at 6:51 PM, Levente Uzonyi <[hidden email]> wrote:
I thought this is how ReadOnlyVariableBinding was supposed to be used: classes would use it, globals not. Marcus |
|
|
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. name ClassBinding fits better the use case than ReadOnlyVariableBinding. Levente > > Marcus > > > > > |
|
|
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 > > > |
|
|
On 04-02-2015, at 1:04 PM, 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? Make that less than 10mS on a single core Pi... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Diarrhea of the mouth; constipation of the ideas. |
|
|
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 |
|
|
> 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 |
|
|
Seemingly I still can not explain what I mean in away that people get it, so please just ignore this mail. Marcus |
|
|
In reply to this post by Marcus Denker-4
On Thu, 5 Feb 2015, Marcus Denker wrote:
> >> 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. >> 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. 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 > > > |
|
|
> On 05 Feb 2015, at 16:35, Levente Uzonyi <[hidden email]> wrote: > > On Thu, 5 Feb 2015, Marcus Denker wrote: > >> >>> 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. >>> > > 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. > Yes! Marcus |
|
|
In reply to this post by Levente Uzonyi-2
On 5 February 2015 at 15:35, Levente Uzonyi <[hidden email]> wrote:
> On Thu, 5 Feb 2015, Marcus Denker wrote: > >> >>> 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. >>> > > 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 |
|
|
On 05/02/15 16:52, Frank Shearar wrote:
> On 5 February 2015 at 15:35, Levente Uzonyi <[hidden email]> wrote: >> 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 This is an interesting approach. Their problem is not just updating the AST after every keystroke but keeping usable performance when doing code rewriting/refactoring. My first Macintosh, a SE/30 with a 16 MHz 68030, was able to do this with Think Pascal (by Mel Conway) 25 years ago. On my next machine, a 25 MHz 68040LC was fast enough... Stephan |
|
|
In reply to this post by Marcus Denker-4
On Thu, Feb 05, 2015 at 01:54:51PM +0100, Marcus Denker wrote:
> > > On 05 Feb 2015, at 10:12, Marcus Denker <[hidden email]> wrote: > >> > >> On 05 Feb 2015, at 10:04, Marcus Denker <[hidden email]> wrote: > > > > 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. > > > > Seemingly I still can not explain what I mean in away that people get it, so please just ignore this mail. > > Marcus > Your point makes good sense to me. In 1978, a system in which a low-level integer was represented as an object with behavior would have been perceived as a rediculously wasteful idea. And can you imagine someone seriously suggesting something so wasteful as automatic memory management? So if the "same" system was being designed today, it might very well include new concepts that today are perceived as wasteful. Some of those concepts might turn out to be very good thing once we get used to them. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |