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

Re: [Pharo-project] Move MetaObjectTools from core to PharoDev

by Mariano Martinez Peck

On Tue, Mar 23, 2010 at 6:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Mar 23, 2010, at 4:38 PM, Mariano Martinez Peck wrote: > > > Ok. Done. In http://www.squeaksource.com/ObjectMetaTools > > > > you will find two packages: MethodWrappers and ObjectMetaTools > > > > ObjectMetaTools has ObjectTracer, ObjectViewer and ProtocolCatcher > (brought from Cuis) > > > > MethodWrappers has a first migration of the implementation of > MethodWrappers from here: > > > > http://www.squeaksource.com/ObjectsAsMethodsWrap > > > > It has some changes to the original implementation. > > > > - Instead of storing the old selector and the class in the wrapper, now > it is stored a MethodReference > > are you sure that this is better. > We should really clean methodReference because it holds information sich as > the version string that nobody understand the use > of it > no, I am not sure at all ;) ufffff you are completely right. It was "easier" to have a MethodReference but I didn't realize how many things were being kept there. I wouldn't remove MethodReference. I like the idea of having a lightweight proxy for CompiledMethod. Why you want to remove it ? can we make it better ? For example, now I can add class side methods to create instances but with only the things I need: the selector and the class. does it need a clean ? Thanks for looking at it :) > > > - Give another try to use directly methodDict at:put: to install and > uninstall wrapers, instead of addSelector: withMethod: > > - As an example, now there is an implementation of TestCoverage > > > > > > That's all for now. This is tested in 1.0 and 1.1 :) > > > > Cheers > > > > Mariano > > > > > > On Tue, Mar 23, 2010 at 4:03 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Why not? > > What would be good is to clean a bit the code of ObjectAsMethodWrapper > > May be having a better package name can help. > > > > Stef > > > > > > > > > Stef, I was thinking to put not only ProtocolCatcher but also all your > stuff from ObjectAsMethodWrapper in the same ObjectMetaTools. > > > > > > That way we have a repository with cool stuff > > > > > > what do you think ? > > > > > > cheers > > > > > > Mariano > > > > > > On Sat, Mar 20, 2010 at 5:12 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > > > > > > > On Sat, Mar 20, 2010 at 4:44 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > Thanks I will do that! > > > can you open a ticket because the list is starting to get long of the > stuff to integrate after martin's changes. > > > > > > http://code.google.com/p/pharo/issues/detail?id=2180 > > > > > > BTW did you check if the other class besides ProtocolCatcher are > working? > > > > > > > > > No. No time yet. > > > > > > > > > Stef > > > > > > On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > > > > > > > This package should be removed from core but it should still be > loadable. Thus, when needed, they can be easily installed. On the other > hand, it could be in PharoDev image. > > > > > > > > - MetaObjectTools: This package is moved to PharoDev. It doesnt have > any users in PharoCore > > > > > > > > To fix, evaluate: > > > > > > > > (MCPackage named: 'ObjectMetaTools') unload. > > > > > > > > I created and put such code in > http://www.squeaksource.com/ObjectMetaTools > > > > > > > > To load it again in a Pharo image: > > > > > > > > Gofer new > > > > squeaksource: 'ObjectMetaTools'; > > > > package: 'ObjectMetaTools'; > > > > load. > > > > > > > > During the week I will analyze the CUIS' ProtocolCatcher and see if > it make sense to put it there too. > > > > > > > > Cheers > > > > > > > > Mariano > > > > _______________________________________________ > > > > 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 > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 >

March 23, 2010

Re: [Pharo-project] Move MetaObjectTools from core to PharoDev

by StÃ©phane Ducasse

On Mar 23, 2010, at 4:38 PM, Mariano Martinez Peck wrote: > Ok. Done. In http://www.squeaksource.com/ObjectMetaTools > > you will find two packages: MethodWrappers and ObjectMetaTools > > ObjectMetaTools has ObjectTracer, ObjectViewer and ProtocolCatcher (brought from Cuis) > > MethodWrappers has a first migration of the implementation of MethodWrappers from here: > > http://www.squeaksource.com/ObjectsAsMethodsWrap > > It has some changes to the original implementation. > > - Instead of storing the old selector and the class in the wrapper, now it is stored a MethodReference are you sure that this is better. We should really clean methodReference because it holds information sich as the version string that nobody understand the use of it > - Give another try to use directly methodDict at:put: to install and uninstall wrapers, instead of addSelector: withMethod: > - As an example, now there is an implementation of TestCoverage > > > That's all for now. This is tested in 1.0 and 1.1 :) > > Cheers > > Mariano > > > On Tue, Mar 23, 2010 at 4:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Why not? > What would be good is to clean a bit the code of ObjectAsMethodWrapper > May be having a better package name can help. > > Stef > > > > > Stef, I was thinking to put not only ProtocolCatcher but also all your stuff from ObjectAsMethodWrapper in the same ObjectMetaTools. > > > > That way we have a repository with cool stuff > > > > what do you think ? > > > > cheers > > > > Mariano > > > > On Sat, Mar 20, 2010 at 5:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > > > On Sat, Mar 20, 2010 at 4:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Thanks I will do that! > > can you open a ticket because the list is starting to get long of the stuff to integrate after martin's changes. > > > > http://code.google.com/p/pharo/issues/detail?id=2180 > > > > BTW did you check if the other class besides ProtocolCatcher are working? > > > > > > No. No time yet. > > > > > > Stef > > > > On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > > > > > This package should be removed from core but it should still be loadable. Thus, when needed, they can be easily installed. On the other hand, it could be in PharoDev image. > > > > > > - MetaObjectTools: This package is moved to PharoDev. It doesnt have any users in PharoCore > > > > > > To fix, evaluate: > > > > > > (MCPackage named: 'ObjectMetaTools') unload. > > > > > > I created and put such code in http://www.squeaksource.com/ObjectMetaTools > > > > > > To load it again in a Pharo image: > > > > > > Gofer new > > > squeaksource: 'ObjectMetaTools'; > > > package: 'ObjectMetaTools'; > > > load. > > > > > > During the week I will analyze the CUIS' ProtocolCatcher and see if it make sense to put it there too. > > > > > > Cheers > > > > > > Mariano > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

Re: [Pharo-project] Here's my problems...

by Igor Stasenko

2010/3/23 Marcus Denker <marcus.denker(a)inria.fr>: > > On Mar 23, 2010, at 4:52 PM, Igor Stasenko wrote: > >> On 23 March 2010 12:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Mar 19, 2010, at 2:12 PM, Igor Stasenko wrote: >>> >>>> So far so good.. >>>> found DNU: >>>> Utilities noteMethodSubmission: #Comment forClass: cls >>>> >>>> while filing in the .st code >>>> >>> >>> Hmm... the class SetElement does not exisit and is not defined in the changeset? >>> >> No, it is different story. I filed out a full class into .st file , >> and then used it to file-in into image. >> > I think it was a regression when merging some code... the method should not be called on Utitlities > > Can you try the attached fix? > Its now loading ok. > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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.

March 23, 2010

Re: [Pharo-project] Here's my problems...

by Marcus Denker

On Mar 23, 2010, at 4:52 PM, Igor Stasenko wrote: > On 23 March 2010 12:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Mar 19, 2010, at 2:12 PM, Igor Stasenko wrote: >> >>> So far so good.. >>> found DNU: >>> Utilities noteMethodSubmission: #Comment forClass: cls >>> >>> while filing in the .st code >>> >> >> Hmm... the class SetElement does not exisit and is not defined in the changeset? >> > No, it is different story. I filed out a full class into .st file , > and then used it to file-in into image. > I think it was a regression when merging some code... the method should not be called on Utitlities Can you try the attached fix? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] Here's my problems...

by Igor Stasenko

On 23 March 2010 12:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 19, 2010, at 2:12 PM, Igor Stasenko wrote: > >> So far so good.. >> found DNU: >> Utilities noteMethodSubmission: #Comment forClass: cls >> >> while filing in the .st code >> > > Hmm... the class SetElement does not exisit and is not defined in the changeset? > No, it is different story. I filed out a full class into .st file , and then used it to file-in into image. > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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.

March 23, 2010

Re: [Pharo-project] GSoC next steps

by Mariano Martinez Peck

No. Just wait. Those students send us emails (in private) and we put them there so that not to loose them between hundred of emails. Please wait. They won't have any advantage among others. Cheers Mariano 2010/3/23 Carla F. Griggio <carla.griggio(a)gmail.com> > Hola Mariano! > > I see that despite student applications are not open yet, there are some > few students registered in the site, saying the projects they are interested > in. Does this matter? Is it ok if we register to the site as Students though > the student applications are not officialy open? > > Thanks, > Carla > > > On Mon, Mar 22, 2010 at 6:13 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > >> >> >> Janko MivÅ¡ek wrote: >> > >> > Hi Geert, >> > >> >> Why a private discussion and/or voting? Isn't the whole point of GSoC >> to >> >> engage the entire Smalltalk community? >> > >> > Smalltalk GSoC Mentors mailing list is actually visible to others, just >> > that it is created in Slovenian and now I can't change the language. If >> > someone knows how... Here is the link: >> > >> > http://groups.google.si/group/smalltalk-gsoc-mentors >> > >> >> Just use .com instead of .si to see the group in English :) >> http://groups.google.com/group/smalltalk-gsoc-mentors >> >> >> >> Janko MivÅ¡ek wrote: >> > >> > Also, I think this list should stay semi-public and it is not for >> > inclusion on the Nabble. Just for interesting public therefore :) This >> > will then be a right balance between privacy of mentors and public >> > interest of community, IMO. >> > >> > Best regards >> > Janko >> > >> >> Are you sure about this semi-public thingy? :) >> >> >> -- >> View this message in context: >> http://n4.nabble.com/GSoC-next-steps-tp1676708p1677352.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 >

March 23, 2010

Re: [Pharo-project] Move MetaObjectTools from core to PharoDev

by Mariano Martinez Peck

Ok. Done. In http://www.squeaksource.com/ObjectMetaTools you will find two packages: MethodWrappers and ObjectMetaTools ObjectMetaTools has ObjectTracer, ObjectViewer and ProtocolCatcher (brought from Cuis) MethodWrappers has a first migration of the implementation of MethodWrappers from here: http://www.squeaksource.com/ObjectsAsMethodsWrap It has some changes to the original implementation. - Instead of storing the old selector and the class in the wrapper, now it is stored a MethodReference - Give another try to use directly methodDict at:put: to install and uninstall wrapers, instead of addSelector: withMethod: - As an example, now there is an implementation of TestCoverage That's all for now. This is tested in 1.0 and 1.1 :) Cheers Mariano On Tue, Mar 23, 2010 at 4:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Why not? > What would be good is to clean a bit the code of ObjectAsMethodWrapper > May be having a better package name can help. > > Stef > > > > > Stef, I was thinking to put not only ProtocolCatcher but also all your > stuff from ObjectAsMethodWrapper in the same ObjectMetaTools. > > > > That way we have a repository with cool stuff > > > > what do you think ? > > > > cheers > > > > Mariano > > > > On Sat, Mar 20, 2010 at 5:12 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > > > > On Sat, Mar 20, 2010 at 4:44 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Thanks I will do that! > > can you open a ticket because the list is starting to get long of the > stuff to integrate after martin's changes. > > > > http://code.google.com/p/pharo/issues/detail?id=2180 > > > > BTW did you check if the other class besides ProtocolCatcher are working? > > > > > > No. No time yet. > > > > > > Stef > > > > On Mar 20, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > > > > > This package should be removed from core but it should still be > loadable. Thus, when needed, they can be easily installed. On the other > hand, it could be in PharoDev image. > > > > > > - MetaObjectTools: This package is moved to PharoDev. It doesnt have > any users in PharoCore > > > > > > To fix, evaluate: > > > > > > (MCPackage named: 'ObjectMetaTools') unload. > > > > > > I created and put such code in > http://www.squeaksource.com/ObjectMetaTools > > > > > > To load it again in a Pharo image: > > > > > > Gofer new > > > squeaksource: 'ObjectMetaTools'; > > > package: 'ObjectMetaTools'; > > > load. > > > > > > During the week I will analyze the CUIS' ProtocolCatcher and see if it > make sense to put it there too. > > > > > > Cheers > > > > > > Mariano > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > > 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 >

March 23, 2010

[Pharo-project] [ANN 1.1] pre-built Core#11291

by Marcus Denker

https://gforge.inria.fr/frs/download.php/26702/PharoCore-1.1-11291-UNSTABLE… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] GSoC next steps

by Carla F. Griggio

Hola Mariano! I see that despite student applications are not open yet, there are some few students registered in the site, saying the projects they are interested in. Does this matter? Is it ok if we register to the site as Students though the student applications are not officialy open? Thanks, Carla On Mon, Mar 22, 2010 at 6:13 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > > Janko MivÅ¡ek wrote: > > > > Hi Geert, > > > >> Why a private discussion and/or voting? Isn't the whole point of GSoC > to > >> engage the entire Smalltalk community? > > > > Smalltalk GSoC Mentors mailing list is actually visible to others, just > > that it is created in Slovenian and now I can't change the language. If > > someone knows how... Here is the link: > > > > http://groups.google.si/group/smalltalk-gsoc-mentors > > > > Just use .com instead of .si to see the group in English :) > http://groups.google.com/group/smalltalk-gsoc-mentors > > > > Janko MivÅ¡ek wrote: > > > > Also, I think this list should stay semi-public and it is not for > > inclusion on the Nabble. Just for interesting public therefore :) This > > will then be a right balance between privacy of mentors and public > > interest of community, IMO. > > > > Best regards > > Janko > > > > Are you sure about this semi-public thingy? :) > > > -- > View this message in context: > http://n4.nabble.com/GSoC-next-steps-tp1676708p1677352.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010

[Pharo-project] [update 1.1] #11291

by Marcus Denker

11291 ----- Issue 1973: PluggableTreeMorph class#on:list:selected:changeSelected: inconsistency - call #cleanUpForRelease -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010