September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Undeclared dictionary

by Yuriy Tymchuk

Thank you Marcus! This is very helpful. Uko On 03 Sep 2014, at 13:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, can someone explain me how Undeclared dictionary works? > > > So imagine you want to load code where a variable is not defined (e.g. due to loading old code, > or because it references a variable that will only be loaded in a second step). > > In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), > it just loads the wrong code and for every undeclared variable, it adds an entry in the > Undeclared dictionary. > (the bytecode to read and write is the same as used for Globals and Class variables: > pushLiteralVariable, which means "push the value of the association", the store bytecode > for assignment therefore is "store in the value of that association". > > So if you actually run code that has Undeclared, it will work: it will be nil by default, > but when you assign it will store into the Undeclared dictionary. > > When you add a new Global to the SystemDictionary, it will check Undeclared and > move the value over. Same for Class vars. > (this means that loading a class will automatically fix all Undeclared references to it) > > > Because as I look at it, all the values are nil. Is it possible for them to be not nil? > > yes. > > Maybe we should have a âglobal variable commentsâ for this situations :) > > > Ideed. > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de

Sept. 3, 2014

Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix

by Camille Teruel

On 3 sept. 2014, at 11:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello guys, > > I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. > > For example: > > col := #(1 2 3 4 5) asOrderedCollection. > col do: [ :elem | elem trace . > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > => '12345678' > > However: > > col := #(1 2 3 4 5) asOrderedCollection. > col collect: [ :elem | elem trace . > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > => '12345' > > This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. > > Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. > > I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. > > In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. > > I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? The thing is to find alternative implementations that are efficient enough (no copy). Maybe we can get some inspirations from VW for that (how do they do BTW?). You should also check with other kinds of collection because they may act differently than OrderedCollection. So in the end it depends on the amount of effort needed to make all collections consistent with this new requirement and on the resulting overhead. If it's too much, I think that following the old advice "don't modify a collection while iterating it" is enough. If one really needs to do such kind of things he should consider an alternative design like using a zipper for example. Camille > > Clement >

Sept. 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40198 Home: https://github.com/pharo-project/pharo-core

Sept. 3, 2014

[pharo-project/pharo-core] dd8739: 40198

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: dd8739108d56ca8cfd1ee003ca846101eab522c9 https://github.com/pharo-project/pharo-core/commit/dd8739108d56ca8cfd1ee003… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-03 (Wed, 03 Sep 2014) Changed paths: M AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitsmnemonic_operand1_operand2_operand3_.st M ProfStef-Core.package/PharoSyntaxTutorial.class/instance/interactive/prepareDebuggerExample.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script198.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40198.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Debugger.package/EyeDebuggerContextInspector.class/instance/list/generateElements.st Log Message: ----------- 40198 13942 Deselecting stacklist can throw MNU https://pharo.fogbugz.com/f/cases/13942 13945 Author reset should not be called directly https://pharo.fogbugz.com/f/cases/13945 http://files.pharo.org/image/40/40198.zip

Sept. 3, 2014

Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix

by Levente Uzonyi

On Wed, 3 Sep 2014, ClÃ©ment Bera wrote: > Hello guys, > I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. > > For example: > > col := #(1 2 3 4 5) asOrderedCollection. > col do: [ :elem | elem trace . > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > => '12345678' > > However: > > col := #(1 2 3 4 5) asOrderedCollection. > col collect: [ :elem | elem trace . > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > => '12345' > > This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection > protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. In case of #select and #collect: this is only true for elements added with #addLast:, #addFirst:, or #add:, but there are other methods which can have (even worse) side effects (#add:after:, #add:before:, etc). Levente > > Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the > OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. > > I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the > collection while iterating over it. > > In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at > least the ones cross smalltalk) which sounds the most correct. > > I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? > > Clement > > >

Sept. 3, 2014

Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix

by Sven Van Caekenberghe

Clement, I am not sure, but could this not be a compiler issue ? Not with Opal but with the old compiler ?! I mean, if you look at the implementations of OrderedCollection>>#do: and OrderedCollection>>#collect: they basically do the same thing, going from firstIndex to lastIndex, both of which are instance variables, but in the first case, the #do:, the end test is evaluated on each iteration, while in the second case, the #to:do:, the end test should be evaluated only once. Since lastIndex changes while iterating, one iteration sees it, the other not. Looking at the byte codes seems to confirm that: the compilation of the #:to:do is different: Opal correctly moves both instance variables to temps, while the old compiler keeps on referring to the second instance variable (lastIndex) directly on each loop - which is plain wrong IMHO. I am with Marcus that you should not modify a collection that you iterate over. What if you would be inserting values at arbitrary places ? I am with you that both (all) enumerations should be consistent. Like in VW, delegating to the simplest #do: seems best. Sven On 03 Sep 2014, at 11:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello guys, > > I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. > > For example: > > col := #(1 2 3 4 5) asOrderedCollection. > col do: [ :elem | elem trace . > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > => '12345678' > > However: > > col := #(1 2 3 4 5) asOrderedCollection. > col collect: [ :elem | elem trace . > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > => '12345' > > This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. > > Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. > > I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. > > In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. > > I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? > > Clement >

Sept. 3, 2014

Re: [Pharo-dev] Undeclared dictionary

by Marcus Denker

On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, can someone explain me how Undeclared dictionary works? > > So imagine you want to load code where a variable is not defined (e.g. due to loading old code, or because it references a variable that will only be loaded in a second step). In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), it just loads the wrong code and for every undeclared variable, it adds an entry in the Undeclared dictionary. (the bytecode to read and write is the same as used for Globals and Class variables: pushLiteralVariable, which means "push the value of the association", the store bytecode for assignment therefore is "store in the value of that association". So if you actually run code that has Undeclared, it will work: it will be nil by default, but when you assign it will store into the Undeclared dictionary. When you add a new Global to the SystemDictionary, it will check Undeclared and move the value over. Same for Class vars. (this means that loading a class will automatically fix all Undeclared references to it) > Because as I look at it, all the values are nil. Is it possible for them > to be not nil? > > yes. > Maybe we should have a âglobal variable commentsâ for this situations :) > > Ideed. -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Sept. 3, 2014

Re: [Pharo-dev] Proportional Tab Stops

by Ben Coman

Sept. 3, 2014

Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube

by Sven Van Caekenberghe

Yeah, I admit it, I am addicted to Pharo ;-) "A compulsive need to use Pharo in order to function normally. When the use of Pharo is unobtainable, the user suffers from withdrawal." On 03 Sep 2014, at 11:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Man, are you sure that you want to advertise publicly that you are listening to this music? :)) > > Doru > > > On Wed, Sep 3, 2014 at 11:00 AM, stepharo <stepharo(a)free.fr> wrote: > Yes I saw it too :) > > > > On 3/9/14 09:40, Sven Van Caekenberghe wrote: > We should sue this guy ;-) > > https://www.youtube.com/watch?v=S3uktGJVebE > > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Sept. 3, 2014

OrderedCollection protocols are broken: a potential fix

by ClÃ©ment Bera

Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem < 4 ifTrue: [ col add: col size + 1 ]]. => '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem < 4 ifTrue: [ col add: col size + 1 ]]. => '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Clement

Sept. 3, 2014