April 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Connectors minimal version into pharo

by Fernando olivero

Great! Once i have something working i'll post the package in squeaksource. I will try to remove the fsm dependency and try to avoid having so many extensions, and have a minimal functionality. Connectors is a full blown system, i just need to draw simple constrained connection between morphs without the graph support. Fernando On Apr 12, 2010, at 2:00 PM, StÃ©phane Ducasse wrote: > > On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote: > >> Hi all, i just wanted to re post the fix underscore code Lukas posted a while ago. >> >> I've just imported Connectors package into pharo, (i'm trying to get a minimal version working ), > > excellent! > I'm interesting in a mini version of that ;) > >> and stumbled upon the problem of the underscores.. >> but now thanks to SmallInt rules it was easy and fast to overcome this problem! >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 12, 2010

Re: [Pharo-project] Automatic generation of abstract methods

by Simon Denier

On 12 avr. 2010, at 14:26, Cyrille Delaunay wrote: > Hello, > > Would it be difficult to generate automatically superclass-abstract methods (with an empty contents) when creating a new subclass? > For example, imagine I want to make my own subclass of Collection. As there is a lot of methods in this class and probably abstract methods, it would be cool to see them directly in my subclass without having to look to Collection method one by one (?). > I'm probably not the first to ask this question, but in case it is, that's done:) Normally there is already a refactoring for that. Context menu>refactor class>realize -- Simon

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by Marcus Denker

On Apr 12, 2010, at 2:16 PM, Torsten Bergmann wrote: > On 12 April 2010 14:30, StÃ©phane Ducasse <stephane.ducasse at inria.fr> wrote: >> There was a break on enter code somewhere. >> Does anybody remember? > > Maybe you mean: > > http://map.squeak.org/package/07469ced-289a-4b6f-bd17-27ec567e681a/autovers… Yes, I added this to Squeak 3.6 or 3.7 or 3.8 (don't remember). It never got too much use... partly because the UI parts are not that nicely done, partly because it can only break at the beginning of a method. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 12, 2010

[Pharo-project] Automatic generation of abstract methods

by Cyrille Delaunay

Hello, Would it be difficult to generate automatically superclass-abstract methods (with an empty contents) when creating a new subclass? For example, imagine I want to make my own subclass of Collection. As there is a lot of methods in this class and probably abstract methods, it would be cool to see them directly in my subclass without having to look to Collection method one by one (?). I'm probably not the first to ask this question, but in case it is, that's done:)

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by Marcus Denker

On Apr 12, 2010, at 2:12 PM, Igor Stasenko wrote: > On 12 April 2010 14:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> There was a break on enter code somewhere. >> Does anybody remember? >> >> I remember some code of igor to do that. >> Would be good to resurrect that. >> > well, i still having that code somewhere. > the problem with using #run:with:in: > that you can't put a breakpoint inside an arbitrary place in method. > You can break on entering a method (or leaving it). You could just store the AST in your fake method, put the halt as an annotation, then interpret the AST with a special interpreter that checks for the annotation. Phillippe did a evaluation-visitor for the RB AST, and the RB AST allows for properties to be set on any node. The code is in the Reflectivity package (part of the Persephone "JIT"), so we would have already large parts of the needed infrastructure. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 12, 2010

[Pharo-project] Inserting halts using pragmas?

by Torsten Bergmann

On 12 April 2010 14:30, StÃ©phane Ducasse <stephane.ducasse at inria.fr> wrote: > There was a break on enter code somewhere. > Does anybody remember? Maybe you mean: http://map.squeak.org/package/07469ced-289a-4b6f-bd17-27ec567e681a/autovers… -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Peter Hugosson-Miller

On Mon, Apr 12, 2010 at 2:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/4/12 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > > > > > > On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> Oh.. again.. > >> @Ralph: if you don't want sets with nils, just don't put them there. > >> Why this isn't obvious for you? > >> Take a Squeak , which already supporting nils in sets. > >> Have you seen ANY reported breakage of existing code because of this? > >> > >> On 12 April 2010 05:25, Levente Uzonyi <leves(a)elte.hu> wrote: > >> > On Sun, 11 Apr 2010, Ralph Boland wrote: > >> > > >> >>> Hi levente/igor > >> >> > >> >>> this hashedCollection is still on my radar. Now I was wondering if I > >> >>> should > work first on Set with nil or HashedCollection. > >> >>> Any idea/suggestion? > >> >> > >> >>> Stef > >> >> > >> >> I think moving Dictionary out from under Set is a great idea. > >> >> However I am not convinced having a class HashedCollection > >> >> to share common code between Set and Dictionary is worth it. > >> >> I would just tolerate the code duplication because these classes > >> >> are so important. Given that Squeak is going to support > >> > > >> > I don't see your point here. In Squeak that would mean duplicating 17 > + > >> > 9 > >> > methods (instance/class side) + the two instance variables for no > >> > reason. > >> > > >> >> HashedCollection though, I would hate to see yet another difference > >> >> between Pharo and Squeak. I expect that the difference is unlikely > >> >> to break code shared between Pharo and Squeak though. > >> >> > >> >> I was always against allowing the addition of nil to sets. > >> >> This change means that every time I accidentally add nil to a set > >> >> the error will go undetected and will be difficult to track down once > >> >> the problem is discovered. > >> > > >> > Collections are still not ment to be bug detectors... Btw, do you > notice > >> > if > >> > you add nil as a key to a Dictionary? (or add nil to an > >> > OrderedCollection?) > >> > > >> >> My solution to escape this change in my code will be to subclass > >> >> Set and any of its subclasses that I use and add code in the > subclasses > >> >> to test for addition of nil and report an error when it happens. > >> >> This will allow bugs to show up sooner. > >> > > >> > You can (ab)use PluggableSet if you really need this by adding the nil > >> > check > >> > to the hashBlock. > >> > > >> >> An alternative is just to modify Set itself by adding a test for > >> >> adding nil to a set and then reporting an error. This change will > >> >> break > >> >> down of course once there are instances of actually adding nil to a > set > >> >> in Squeak/Pharo. > >> >> Are there any such occurrences is Squeak 4.1? > >> > > >> > Who knows, nil can be everywhere: #(1 2 nil) asSet. > >> > > >> >> Now that this feature will be in Squeak 4.1, however, we again have > >> >> the problem of divergence of code between Pharo and Squeak. The > >> >> problem won't be there immediately but eventually this feature > >> >> will actually be used in Squeak. > >> >> Of course the issue here is how often it is useful to allow > >> >> addition of nil to a Set. For the approximately 100,000 lines of > >> >> code I have written in Smalltalk the answer is 0 explaining my > >> >> opposition to this change. For some others though the answer > >> >> must be different. > >> >> For me this change will delay my moving my code from Squeak > >> >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). > >> >> Note that I use Sets and Dictionaries a lot. When my Squeak project > >> >> runs 80% of the time is spent on Set/Dictionary operations. > >> > > >> > You could have added nil as a key to a Dictionary and that went > >> > undetected... > >> > > >> > > >> > Levente > >> > > >> >> > >> >> Regards, > >> >> > >> >> Ralph Boland > >> >> > >> >> _______________________________________________ > >> >> Pharo-project mailing list > >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> >> > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > Heh, well I understand Ralph's point quite well, since I know that in the > > project I'm working on there are places in the code that depend on the > fact > > that sets can't contain nil. So the following would break if VisualAge > added > > that possibility: > > #( 1 2 3 4 nil 6 7 nil) asSet asArray > > #( 1 2 3 4 nil 6 7 nil) asSet > in squeak before adding sets-with-nils you won't see such code , > because this will throw an error. > And so, nobody used it in that way before. > I mean, there is no code in old squeak codebase which putting nils > into sets intentionally. > So, either you intentionally puting nils there - and its completely OK, > or you intentionally do not putting them (as all old code does) - > which is also , completely OK. > > > > => #(1 2 3 4 6 7) > > I'm not deciding one way or the other which way is right, just adding an > > observation. > > -- > > Cheers, > > Peter > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Sig, I agree with you! My example was of some code that would not survive the transition: using a asSet as a cheap way to get rid of the *possible* nils in a collection. In fact, I think I'm going to take a look at our code and do something about it now, just in case... Thanks for the heads-up -- Cheers, Peter

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by Igor Stasenko

On 12 April 2010 14:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > There was a break on enter code somewhere. > Does anybody remember? > > I remember some code of igor to do that. > Would be good to resurrect that. > well, i still having that code somewhere. the problem with using #run:with:in: that you can't put a breakpoint inside an arbitrary place in method. You can break on entering a method (or leaving it). But this is not the main problem. Main problem is UI. It should be made convenient enough for use, because if its not accessible from UI, its no matter how highly advanced/cool implementation is, since nobody will use it anyway :) > Stef > > On Apr 12, 2010, at 10:27 AM, Fernando olivero wrote: > >> Hi, Â can we inserts halt's into methods without modifying source code, using pragmas maybe? >> >> Has there been work on this? >> >> Thanks, >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

[Pharo-project] browse hierarchyImplementors raise an error

by Cyrille Delaunay

Hello, In a Pharo-1.0-10515-rc3 image, In the standard class browser, when you click on the green arrow at the left of a method, to browse hierarchyImplementor, an error occur. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2305

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Igor Stasenko

2010/4/12 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > > > On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Oh.. again.. >> @Ralph: if you don't want sets with nils, just don't put them there. >> Why this isn't obvious for you? >> Take a Squeak , which already supporting nils in sets. >> Have you seen ANY reported breakage of existing code because of this? >> >> On 12 April 2010 05:25, Levente Uzonyi <leves(a)elte.hu> wrote: >> > On Sun, 11 Apr 2010, Ralph Boland wrote: >> > >> >>> Hi levente/igor >> >> >> >>> this hashedCollection is still on my radar. Now I was wondering if I >> >>> should > work first on Set with nil or HashedCollection. >> >>> Any idea/suggestion? >> >> >> >>> Stef >> >> >> >> I think moving Dictionary out from under Set is a great idea. >> >> However I am not convinced having a class HashedCollection >> >> to share common code between Set and Dictionary is worth it. >> >> I would just tolerate the code duplication because these classes >> >> are so important. Â Given that Squeak is going to support >> > >> > I don't see your point here. In Squeak that would mean duplicating 17 + >> > 9 >> > methods (instance/class side) + the two instance variables for no >> > reason. >> > >> >> HashedCollection though, I would hate to see yet another difference >> >> between Pharo and Squeak. I expect that the difference is unlikely >> >> to break code shared between Pharo and Squeak though. >> >> >> >> I was always against allowing the addition of nil to sets. >> >> This change means that every time I accidentally add nil to a set >> >> the error will go undetected and will be difficult to track down once >> >> the problem is discovered. >> > >> > Collections are still not ment to be bug detectors... Btw, do you notice >> > if >> > you add nil as a key to a Dictionary? (or add nil to an >> > OrderedCollection?) >> > >> >> My solution to escape this change in my code will be to subclass >> >> Set and any of its subclasses that I use and add code in the subclasses >> >> to test for addition of nil and report an error when it happens. >> >> This will allow bugs to show up sooner. >> > >> > You can (ab)use PluggableSet if you really need this by adding the nil >> > check >> > to the hashBlock. >> > >> >> An alternative is just to modify Set itself by adding a test for >> >> adding nil to a set and then reporting an error. Â This change will >> >> break >> >> down of course once there are instances of actually adding nil to a set >> >> in Squeak/Pharo. >> >> Are there any such occurrences is Squeak 4.1? >> > >> > Who knows, nil can be everywhere: #(1 2 nil) asSet. >> > >> >> Now that this feature will be in Squeak 4.1, however, we again have >> >> the problem of divergence of code between Pharo and Squeak. Â The >> >> problem won't be there immediately but eventually this feature >> >> will actually be used in Squeak. >> >> Of course the issue here is how often it is useful to allow >> >> addition of nil to a Set. Â For the approximately 100,000 lines of >> >> code I have written in Smalltalk the answer is 0 explaining my >> >> opposition to this change. Â For some others though the answer >> >> must be different. >> >> For me this change will delay my moving my code from Squeak >> >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). >> >> Note that I use Sets and Dictionaries a lot. Â When my Squeak project >> >> runs 80% of the time is spent on Â Set/Dictionary operations. >> > >> > You could have added nil as a key to a Dictionary and that went >> > undetected... >> > >> > >> > Levente >> > >> >> >> >> Regards, >> >> >> >> Ralph Boland >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Heh, well I understand Ralph's point quite well, since I know that in the > project I'm working on there are places in the code that depend on the fact > that sets can't contain nil. So the following would break if VisualAge added > that possibility: > #( 1 2 3 4 nil 6 7 nil) asSet asArray #( 1 2 3 4 nil 6 7 nil) asSet in squeak before adding sets-with-nils you won't see such code , because this will throw an error. And so, nobody used it in that way before. I mean, there is no code in old squeak codebase which putting nils into sets intentionally. So, either you intentionally puting nils there - and its completely OK, or you intentionally do not putting them (as all old code does) - which is also , completely OK. > Â => #(1 2 3 4 6 7) > I'm not deciding one way or the other which way is right, just adding an > observation. > -- > Cheers, > Peter > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010