November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Status about compiler _ changes

by Lukas Renggli

> It should be possible to forbid _ assignment in interactive mode, but > still authorize in batch mode (loading an external package for > example) to make sure those assignments disappear... Yes, but you still wouldn't know if a_1 is an old assignment or a new variable access. Or am I missing something? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 13, 2009

Re: [Pharo-project] Status about compiler _ changes

by Nicolas Cellier

2009/11/13 Lukas Renggli <renggli(a)gmail.com>: >> Now could not we have 3? >> Â Â Â Â Â 3 >> Â Â Â Â Â do 1 (ie no preference) but transform the code from _ into := automatically. >> It would be really great in fact > > That would be the magic solution :-) > > The problem is that it would not be clear how to parse a_1. Is it the > assignment of 1 to a or the access of the variable a_1? > > I don't like the proposal of requiring a delimiter before and after an > underscore assignment: (1) there is existing code where this is not > the case, (2) it complicates the scanning significantly, the same > token represents different things depending on context and an extended > lookahead is required to parse it, and (3) it allows that people > continue to use crappy underscore assignments, there will be a mess > forever. > > Lukas > It should be possible to forbid _ assignment in interactive mode, but still authorize in batch mode (loading an external package for example) to make sure those assignments disappear... > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2009

Re: [Pharo-project] Status about compiler _ changes

by Lukas Renggli

> Now could not we have 3? > Â Â Â Â 3 > Â Â Â Â do 1 (ie no preference) but transform the code from _ into := automatically. > It would be really great in fact That would be the magic solution :-) The problem is that it would not be clear how to parse a_1. Is it the assignment of 1 to a or the access of the variable a_1? I don't like the proposal of requiring a delimiter before and after an underscore assignment: (1) there is existing code where this is not the case, (2) it complicates the scanning significantly, the same token represents different things depending on context and an extended lookahead is required to parse it, and (3) it allows that people continue to use crappy underscore assignments, there will be a mess forever. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 13, 2009

Re: [Pharo-project] Status about compiler _ changes

by Lukas Renggli

> Now could not we have 3? > Â Â Â Â 3 > Â Â Â Â do 1 (ie no preference) but transform the code from _ into := automatically. > It would be really great in fact That would be the magic solution :-) The problem is that it would not be clear how to parse a_1. Is it the assignment of 1 to a or the access of the variable a_1? I don't like the proposal of requiring a delimiter before and after an underscore assignment: (1) there is existing code where this is not the case, (2) it complicates the scanning significantly, the same token represents different things depending on context and an extended lookahead is required to parse it, and (3) it allows that people continue to use crappy underscore assignments, there will be a mess forever. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 13, 2009

Re: [Pharo-project] slow method editor on syntax problems

by Henrik Johansen

Yes, I have. Do I have a fix done, or time to explain it right now? No :) I'll see what I can do this weekend, I have some ideas. Cheers, Henry On Nov 13, 2009, at 3:40 46PM, Johan Brichau wrote: > Hi everyone, > > Editing becomes very slow very rapidly when some (syntax) errors are > present in the edited method. It suffices to have a couple of > undefined variables to make the text editor take 1 second to display a > typed character. Quite annoying... > > I have not yet investigated the issue but since I guess I must not be > the only one to see this happen maybe someone has some thoughts or is > already on the issue (although I could not find an issue on the > tracker). > > I am working with the latest (1.0rc) image. > > cheers! > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2009

Re: [Pharo-project] slow method editor on syntax problems

by Alexandre Bergel

> I have not yet investigated the issue but since I guess I must not be > the only one to see this happen maybe someone has some thoughts or is > already on the issue (although I could not find an issue on the > tracker). +1 You're not the only one Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by merlyn＠stonehenge.com

>>>>> "Igor" == Igor Stasenko <siguctua(a)gmail.com> writes: Igor> You are counting wrong numbers. Please count the time you have to spend Igor> to interpret closures in C++, and then using them run arbitrary code Igor> in the loop, Igor> then we will talk again when you done :) As we used to say in the C vs Perl debate: "Compared to Perl, C will give you the answer faster, but far later." :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Nov. 13, 2009

[Pharo-project] slow method editor on syntax problems

by Johan Brichau

Hi everyone, Editing becomes very slow very rapidly when some (syntax) errors are present in the edited method. It suffices to have a couple of undefined variables to make the text editor take 1 second to display a typed character. Quite annoying... I have not yet investigated the issue but since I guess I must not be the only one to see this happen maybe someone has some thoughts or is already on the issue (although I could not find an issue on the tracker). I am working with the latest (1.0rc) image. cheers! ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Nov. 13, 2009

[Pharo-project] [update 1.1] #11041

by Marcus Denker

11041 ----- Issue 1436: ClassFactoryForTestCase generate classes which name is a String instead of a Symbol Issue 640: Debugger buildMorphicNotifierLabelled:message: calls: eToyFriendly Issue 1425: Inspector does not handle correctly isVariable class with inst var -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 13, 2009

[Pharo-project] New Pharo based on core 10495

by Damien Cassou

http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Nov. 13, 2009