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

[Pharo-project] How to build on the work on the parser made by gwenael

by StÃ©phane Ducasse

Hi guys Gwenael cleaned the RBParser (manual written parser) and I would like that we do not lose this work. There is also the status of the old compiler (I know that know that eliot use it for COG, it gets a problem for the newcompiler adoption). I would really like to have a roadmap so that we can propose student projects or large projects. stef

Jan. 22, 2009

Re: [Pharo-project] About RBProgramNodeVisitor interface

by StÃ©phane Ducasse

>> What do you think? > > It is uncommon. I shoot myself in the foot when implementing SmallWiki > and following the RB visitor code. > > It is the hell lot of work to change that though. Numerous external > project depend on these visitors and I am sure I forgot half of them: > RefactoringBrowser, OB-Refactory, NewCompiler, Reflectivity, > Persephone, QuasiQuoting, Diesel, ... Furthermore, if the interface is > changed it won't be easily possible to port the latest version of > SmaCC to Pharo anymore. I do not understand the relation between Smacc and the visitor code? Smacc parse and produce the ast Do you mean the new compiler ast checker and other. Now it would be good that we move on. I will probably write a new visitor because I hate this code. May be other people will use it at least I will for my projects. I would like to know how we could automatically transform code from one to the others. else we will be stuck forever with this code. Stef

Jan. 22, 2009

Re: [Pharo-project] Trait bug to fix....

by StÃ©phane Ducasse

Yes I thought about that after my post if the superclass get the method removed... So I think that we should remove the explicit requirement since it is too static in a world like Smalltalk. Stef On Jan 21, 2009, at 11:08 PM, Adrian Lienhard wrote: > > On Jan 21, 2009, at 22:57 , StÃ©phane Ducasse wrote: > >> Adrian why this is not simply that when you compute the composition >> and the method that you should add in B that you do not add >> f if it is an explicit requirement and defined in the superclass? > > Its not that simple because the situation can change at any time. Lets > say, class A does not implement #doSomething when you define B. When > you add the trait T1, #doSomething sending #explicitRequirement is > added to B. Later you implement #doSomething in A. At this moment the > #doSomething has to be removed from B. > > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 22, 2009

Re: [Pharo-project] Trait bug to fix....

by Adrian Lienhard

On Jan 21, 2009, at 22:57 , StÃ©phane Ducasse wrote: > Adrian why this is not simply that when you compute the composition > and the method that you should add in B that you do not add > f if it is an explicit requirement and defined in the superclass? Its not that simple because the situation can change at any time. Lets say, class A does not implement #doSomething when you define B. When you add the trait T1, #doSomething sending #explicitRequirement is added to B. Later you implement #doSomething in A. At this moment the #doSomething has to be removed from B. Adrian

Jan. 21, 2009

Re: [Pharo-project] Trait bug to fix....

by Adrian Lienhard

In the example you posted the class A should not use T. The description of the Mantis report is correct. Adrian On Jan 21, 2009, at 22:53 , StÃ©phane Ducasse wrote: > I'm confused I do not undersatnd why if B is a subclass of A it uses T > too. > I have to check the bugs tracker > > On Jan 21, 2009, at 10:03 PM, Adrian Lienhard wrote: > >> Any suggestion for how to implement this? Without using some >> reflection tricks, this would imply that the marker methods have to >> be >> added and removed depending on the methods added and removed in >> superclasses. This would significantly complicate the implementation. >> >> BTW, this only is an issue if m is implemented as "self >> explicitRequirement". I never really understood why one would want to >> explicitly declare requirements. In the end, the difference is to get >> a different exception than a MNU. If one wants this to see what >> methods still need to be implemented in a class I would rather >> suggest >> to extend the tools to show this (even the ones not explicitly >> declared) and not use explicit declarations. The algorithm by >> Nathanael to do exactly this is already in the image. >> >> Adrian >> >> On Jan 21, 2009, at 21:37 , StÃ©phane Ducasse wrote: >> >>>> T requires m >>>> >>>> A uses: T >>>> m ^#fromA >>>> B subclass: A uses: T >>>> >>>> M new m => error explicit requirement >>> >>> Begin forwarded message: >>> >>>> http://bugs.squeak.org/view.php?id=6534 >>> >>> >>> _______________________________________________ >>> 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

Jan. 21, 2009

Re: [Pharo-project] Trait bug to fix....

by Adrian Lienhard

On Jan 21, 2009, at 22:55 , Alexandre Bergel wrote: > Maybe the solution is to not have this methods. Required methods are > easily inferred. There is no need to ask the user to define methods... exactly Adrian > > > Alexandre > > > On 21 Jan 2009, at 22:03, Adrian Lienhard wrote: > >> Any suggestion for how to implement this? Without using some >> reflection tricks, this would imply that the marker methods have to >> be >> added and removed depending on the methods added and removed in >> superclasses. This would significantly complicate the implementation. >> >> BTW, this only is an issue if m is implemented as "self >> explicitRequirement". I never really understood why one would want to >> explicitly declare requirements. In the end, the difference is to get >> a different exception than a MNU. If one wants this to see what >> methods still need to be implemented in a class I would rather >> suggest >> to extend the tools to show this (even the ones not explicitly >> declared) and not use explicit declarations. The algorithm by >> Nathanael to do exactly this is already in the image. >> >> Adrian >> >> On Jan 21, 2009, at 21:37 , StÃ©phane Ducasse wrote: >> >>>> T requires m >>>> >>>> A uses: T >>>> m ^#fromA >>>> B subclass: A uses: T >>>> >>>> M new m => error explicit requirement >>> >>> Begin forwarded message: >>> >>>> http://bugs.squeak.org/view.php?id=6534 >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 21, 2009

Re: [Pharo-project] Trait bug to fix....

by StÃ©phane Ducasse

T1>>f self explicitRequirement A is a subclass of Object, NOT using T1 A>>f self doSomething B is a subclass of A using T1 In B, f is still a requirement even if implemented in the superclass. This is because methods in trait T1 take precedence over methods in the superclass. This should not be the case with required methods. Adrian why this is not simply that when you compute the composition and the method that you should add in B that you do not add f if it is an explicit requirement and defined in the superclass? On Jan 21, 2009, at 10:03 PM, Adrian Lienhard wrote: > Any suggestion for how to implement this? Without using some > reflection tricks, this would imply that the marker methods have to be > added and removed depending on the methods added and removed in > superclasses. This would significantly complicate the implementation. I do not understand why you would have to do that? > > > BTW, this only is an issue if m is implemented as "self > explicitRequirement". I never really understood why one would want to > explicitly declare requirements. I thought it was interesting because it made clear the intention and what we had to provide. > In the end, the difference is to get > a different exception than a MNU. If one wants this to see what > methods still need to be implemented in a class I would rather suggest > to extend the tools to show this (even the ones not explicitly > declared) and not use explicit declarations. probably > The algorithm by > Nathanael to do exactly this is already in the image. > > Adrian > > On Jan 21, 2009, at 21:37 , StÃ©phane Ducasse wrote: > >>> T requires m >>> >>> A uses: T >>> m ^#fromA >>> B subclass: A uses: T >>> >>> M new m => error explicit requirement >> >> Begin forwarded message: >> >>> http://bugs.squeak.org/view.php?id=6534 >> >> >> _______________________________________________ >> 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 >

Jan. 21, 2009

Re: [Pharo-project] Trait bug to fix....

by Alexandre Bergel

Maybe the solution is to not have this methods. Required methods are easily inferred. There is no need to ask the user to define methods... Alexandre On 21 Jan 2009, at 22:03, Adrian Lienhard wrote: > Any suggestion for how to implement this? Without using some > reflection tricks, this would imply that the marker methods have to be > added and removed depending on the methods added and removed in > superclasses. This would significantly complicate the implementation. > > BTW, this only is an issue if m is implemented as "self > explicitRequirement". I never really understood why one would want to > explicitly declare requirements. In the end, the difference is to get > a different exception than a MNU. If one wants this to see what > methods still need to be implemented in a class I would rather suggest > to extend the tools to show this (even the ones not explicitly > declared) and not use explicit declarations. The algorithm by > Nathanael to do exactly this is already in the image. > > Adrian > > On Jan 21, 2009, at 21:37 , StÃ©phane Ducasse wrote: > >>> T requires m >>> >>> A uses: T >>> m ^#fromA >>> B subclass: A uses: T >>> >>> M new m => error explicit requirement >> >> Begin forwarded message: >> >>> http://bugs.squeak.org/view.php?id=6534 >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 21, 2009

Re: [Pharo-project] Trait bug to fix....

by StÃ©phane Ducasse

I'm confused I do not undersatnd why if B is a subclass of A it uses T too. I have to check the bugs tracker On Jan 21, 2009, at 10:03 PM, Adrian Lienhard wrote: > Any suggestion for how to implement this? Without using some > reflection tricks, this would imply that the marker methods have to be > added and removed depending on the methods added and removed in > superclasses. This would significantly complicate the implementation. > > BTW, this only is an issue if m is implemented as "self > explicitRequirement". I never really understood why one would want to > explicitly declare requirements. In the end, the difference is to get > a different exception than a MNU. If one wants this to see what > methods still need to be implemented in a class I would rather suggest > to extend the tools to show this (even the ones not explicitly > declared) and not use explicit declarations. The algorithm by > Nathanael to do exactly this is already in the image. > > Adrian > > On Jan 21, 2009, at 21:37 , StÃ©phane Ducasse wrote: > >>> T requires m >>> >>> A uses: T >>> m ^#fromA >>> B subclass: A uses: T >>> >>> M new m => error explicit requirement >> >> Begin forwarded message: >> >>> http://bugs.squeak.org/view.php?id=6534 >> >> >> _______________________________________________ >> 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 >

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Alexandre Bergel

Maybe we could discard Workspace content that are more than 10 days old Just an idea... Alexandre On 21 Jan 2009, at 01:44, Chris Cunningham wrote: > On Tue, Jan 20, 2009 at 12:03 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > It happened to me more than once, that I accidently had some huge > objects hanging in a workspace leading to a memory leak. So > remembering the variables can be a dangerous thing. > > Mainly I was checking to see if there would be issues like this. I > often do researchy things in workspaces which grab only large > amounts of memory (100's of MB), and forget to nil them out > afterwards. Then, weeks (or months) later I need to shrink the > image, and eventually find my way back to the workspace where a > simple nil clears them out. I was worried that if they were held > onto in history, this would be a problem. > > Keeping the strings around would be useful for me - my current image > has about 20 workspaces open (and in 3.10 dev, this results in lots > of minimized window title bars). Being able to store them off in > history would be nice. > > -Chris > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 21, 2009