- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] speed up with:do: by not checking size

by Eliot Miranda

On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-09-03 14:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > with:do: on SequencableCollection checks that both collections have the >> same size (it raises an Error if not). >> >> with: otherCollection do: twoArgBlock >> "Evaluate twoArgBlock with corresponding elements from this >> collection and otherCollection." >> otherCollection size = self size ifFalse: [self error: >> 'otherCollection must be the same size']. >> 1 to: self size do: >> [:index | >> twoArgBlock value: (self at: index) >> value: (otherCollection at: index)] >> >> I think we should not do that: >> >> 1) it is slow >> > > Are you sure about that one? The check is a constant cost disregarding the > collection length, and, anyway, self size is reused just after that. > > >> 2) when the other is larger, is would work and just omit the rest > > 3) if it is smaller, you will get an error anyway >> > > I have a feeling I'm not in Pharo anymore, but in R instead ;) > +2. There are clear safety advantages in the check. If you want the "faster" protocol why not define withSomeOf:do: or some such? > Thierry > > >> >> There are just three methods doing such a size check: >> >> with:do: >> with:collect: >> reverseWith:do: >> (the last one actually raises a SizeMismatch exception, it is the >> sole user of that exception) >> >> Is there a reason why this makes sense? >> >> I added an issue with a slice to clean it up: >> >> >> https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… >> >> Marcus >> >> >> >> >> >> > -- best, Eliot

Sept. 3, 2014

Re: [Pharo-dev] Undeclared dictionary

by Yuriy Tymchuk

one more question. How can you find out if method references a thing like that? Because if you do: #refersToLiteral: and pass a key from Undeclared you may also match a symbol which is completely ok. Is there a way to check only for variables? 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] speed up with:do: by not checking size

by Thierry Goubier

2014-09-03 14:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > with:do: on SequencableCollection checks that both collections have the > same size (it raises an Error if not). > > with: otherCollection do: twoArgBlock > "Evaluate twoArgBlock with corresponding elements from this collection > and otherCollection." > otherCollection size = self size ifFalse: [self error: > 'otherCollection must be the same size']. > 1 to: self size do: > [:index | > twoArgBlock value: (self at: index) > value: (otherCollection at: index)] > > I think we should not do that: > > 1) it is slow > Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. > 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway > I have a feeling I'm not in Pharo anymore, but in R instead ;) Thierry > > There are just three methods doing such a size check: > > with:do: > with:collect: > reverseWith:do: > (the last one actually raises a SizeMismatch exception, it is the > sole user of that exception) > > Is there a reason why this makes sense? > > I added an issue with a slice to clean it up: > > > https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… > > Marcus > > > > > >

Sept. 3, 2014

[pharo-project/pharo-core] d5f98f: 40199

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d5f98f303c8bfe7e4be72f9323a630415cca5b90 https://github.com/pharo-project/pharo-core/commit/d5f98f303c8bfe7e4be72f93… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-03 (Wed, 03 Sep 2014) Changed paths: M ReleaseTests.package/ReleaseTest.class/instance/testing/testObsoleteClasses.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script199.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40199.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40199 13947 fix testObsoleteClasses https://pharo.fogbugz.com/f/cases/13947 http://files.pharo.org/image/40/40199.zip

Sept. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2014

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

by ClÃ©ment Bera

2014-09-03 14:44 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I think we should change > > OrderedCollection>>#do: aBlock > "Override the superclass for performance reasons." > > firstIndex to: lastIndex do: [ :index | > aBlock value: (array at: index) ] > I agree. It's easier to read. But if you do that world menu does not work any more :-/ > > Clement, > > Do you happen to know exactly where the world menu building goes wrong ? > I think so. The problem is in methods such as menuCommandOn: aBuilder <worldMenu> (aBuilder group: #SystemChanges) parent: #Tools; order: 0.51; with: [ (aBuilder item: #'Change Sorter') action:[self open]; icon: self taskbarIcon. (aBuilder item: #'Recover lost changes...') icon: Smalltalk ui icons recoverLostChangesIcon; action: [Smalltalk tools changeList browseRecentLog].]. aBuilder withSeparatorAfter. Here you have a with block which add other items to the menu. Then in the method PragmaMenuBuilder>>#interpretRegistration:, while iterating other the registrations, The code "node with: block" line 12 calls PragmaMenuBuilder>>#currentRoot:while: which activates the block, adding new elements to the collection it iterates from in PragmaMenuBuilder>>#interpretRegistration:. Be ready to use haltOnce / inspectOnce to debug these cases :-). > Sven > > On 03 Sep 2014, at 13:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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] Proportional Tab Stops

by Tudor Girba

Thanks! Doru On Wed, Sep 3, 2014 at 3:21 PM, J.F. Rick <self(a)je77.com> wrote: > Sure. I'll add a ticket to Fogbugz since nobody has any real objections to > my proposed solution. Once I have some time, I might try to solve it myself. > > Cheers, > > Jeff > > > On Wed, Sep 3, 2014 at 1:36 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> Tudor Girba wrote: >> >> Hi, >> >> Glad to hear from you. >> >> Thanks for spotting the issue with tabbing. I think your suggestion of >> having tabs spacing being proportional with the font size makes sense. >> Could we interest you in submitting a slice for this? :) >> >> Cheers, >> Doru >> >> >> I think he indicated he did not have time right now :) >> >> Rick, I think that sounds like a good idea. Maybe you could log a ticket >> on Fogbugz, so you can... >> * stay updated with any action on it >> * be involved in testing any proposed solutions >> * when you back into the Pharo groove, if its still an outstanding issue >> you might have a shot at it yourself. >> >> cheers -ben >> >> >> >> >> >> On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick <self(a)je77.com> wrote: >> >>> Hi everyone, >>> >>> I'm writing for two reasons. First, I wanted to let people know that I >>> haven't disappeared. I'm just having to take a break as I finish up with my >>> current academic post. As I am no longer going to be there, Pharo >>> contributions don't help the department. So, I can't justify devoting any >>> time to Pharo. But, I'm still interested in Athens, multitouch support, and >>> Pharo for beginners. In October, I move back to Atlanta and will start a >>> company. At that point, I aim to be back, though I may concentrate a bit >>> more on server technology (full version of newest QRCode specifications >>> half way done). >>> >>> Second, I wanted to mention a slight annoyance and suggest a solution. >>> Background: I taught a class on introduction / intermediate programming in >>> Pharo the last few years. One thing I try to teach my students is to use >>> proper indention for their code. Unlike Python (great syntax for a first >>> language), you do not need to indent in Smalltalk for code to work properly >>> so students don't have to properly use indention to organize their code. >>> For tiny bits of code (as is required in introductory programming), >>> indention is not that important but it gets more important as they advance. >>> Even my better students often used bad indention practices, though I >>> emphasized it in class and all sample code I gave them was properly >>> indented. In class, I often solved problems and demonstrated code. So that >>> students could see what I typed, I increased the size of the font (24pt >>> standard font). Though the font increased, the tab spacing remained the >>> same. So, when I indented with one tab, it looked much smaller than a tab >>> would have looked on their 10pt code editor. I saw people using spaces to >>> indent code, which I never talked about. My guess is that they were trying >>> to replicate the amount of space that my code was indented. They saw that a >>> tab looked too big and used spaces. A simple solution is for tab spacing in >>> code panes to increase proportionally with the font size. I feel like >>> suggesting that as an improvement for Pharo 4. Does that seem reasonable? >>> Are there arguments against it? >>> >>> Cheers, >>> >>> Jeff >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 3, 2014

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

by ClÃ©ment Bera

Hello, Sven you are right, the old compiler was consistent in the sense that it always iterated over all the elements, including the ones added with #add: and #addLast: while iterating over the collection. On the other hand, VW is consistent with the Opal implementation for #to:do: in the sense that they iterate only on the elements of the collection excluding the ones added while iterating. #add:after: and co do not work well if you edit the collection while iterating over it for sure :). It's too late for "don't modify a collection while iterating it" because the system does it, for example, to build the world menu. So I think the solution is in two steps: - removing code which edit the collection while iterating over it. As most frameworks work both on Pharo and VW and that the behavior is different I think there shouldn't be that much, so fixing the Pharo image may be enough. - be consistent in our collection protocol, basically by rewriting do: and reverseDo: like that: FROM: do: aBlock "Override the superclass for performance reasons." | index | index := firstIndex. [index <= lastIndex] whileTrue: [aBlock value: (array at: index). index := index + 1] TO: do: aBlock "Override the superclass for performance reasons." firstIndex to: lastIndex do: [ :index | aBlock value: (array at: index) ] 2014-09-03 14:05 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com>: > > 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

Re: [Pharo-dev] nil pointersTo size

by Ben Coman

Sept. 3, 2014

Re: [Pharo-dev] Proportional Tab Stops

by J.F. Rick

Sure. I'll add a ticket to Fogbugz since nobody has any real objections to my proposed solution. Once I have some time, I might try to solve it myself. Cheers, Jeff On Wed, Sep 3, 2014 at 1:36 PM, Ben Coman <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > > Hi, > > Glad to hear from you. > > Thanks for spotting the issue with tabbing. I think your suggestion of > having tabs spacing being proportional with the font size makes sense. > Could we interest you in submitting a slice for this? :) > > Cheers, > Doru > > > I think he indicated he did not have time right now :) > > Rick, I think that sounds like a good idea. Maybe you could log a ticket > on Fogbugz, so you can... > * stay updated with any action on it > * be involved in testing any proposed solutions > * when you back into the Pharo groove, if its still an outstanding issue > you might have a shot at it yourself. > > cheers -ben > > > > > > On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick <self(a)je77.com> wrote: > >> Hi everyone, >> >> I'm writing for two reasons. First, I wanted to let people know that I >> haven't disappeared. I'm just having to take a break as I finish up with my >> current academic post. As I am no longer going to be there, Pharo >> contributions don't help the department. So, I can't justify devoting any >> time to Pharo. But, I'm still interested in Athens, multitouch support, and >> Pharo for beginners. In October, I move back to Atlanta and will start a >> company. At that point, I aim to be back, though I may concentrate a bit >> more on server technology (full version of newest QRCode specifications >> half way done). >> >> Second, I wanted to mention a slight annoyance and suggest a solution. >> Background: I taught a class on introduction / intermediate programming in >> Pharo the last few years. One thing I try to teach my students is to use >> proper indention for their code. Unlike Python (great syntax for a first >> language), you do not need to indent in Smalltalk for code to work properly >> so students don't have to properly use indention to organize their code. >> For tiny bits of code (as is required in introductory programming), >> indention is not that important but it gets more important as they advance. >> Even my better students often used bad indention practices, though I >> emphasized it in class and all sample code I gave them was properly >> indented. In class, I often solved problems and demonstrated code. So that >> students could see what I typed, I increased the size of the font (24pt >> standard font). Though the font increased, the tab spacing remained the >> same. So, when I indented with one tab, it looked much smaller than a tab >> would have looked on their 10pt code editor. I saw people using spaces to >> indent code, which I never talked about. My guess is that they were trying >> to replicate the amount of space that my code was indented. They saw that a >> tab looked too big and used spaces. A simple solution is for tab spacing in >> code panes to increase proportionally with the font size. I feel like >> suggesting that as an improvement for Pharo 4. Does that seem reasonable? >> Are there arguments against it? >> >> Cheers, >> >> Jeff >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 3, 2014