May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Yanni Chiu

On 28/05/11 10:16 AM, Stefan Marr wrote: > Hi Marcus: > > > On 28 May 2011, at 15:35, Marcus Denker wrote: > >> There is *a lot* of dead code in the image. >> >> This way we can, within 2-3 interations, remove *a lot* of dead code. > Which tools do you imagine to allow your users to keep up with the pace of the changes of system? I use two automated builds. One stream builds on fixed versions of PharoCore + other stuff. I use this for day-to-day development. The other stream builds my stuff on the latest PharoCore. I manually update to the latest, so there is some lag, but I still find out fairly soon, when a change has affected my stuff. If something is broken, then I would try to make my stuff work in both streams. If that looks like a bad approach, then I could lobby for a change/undo of whatever broke my stuff - while active development of that Pharo version is still ongoing. That's the theory. My build has been broken for 10 days now. That's a matter of hours available and priorities, but I think the process is sound.

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Alexandre Bergel

Marcus, I like the idea. Who should identify the dead code? What role will you have? Should we send you the list of methods we need? Or do you want to take the ten most downloaded project, run their tests and identify what is used, remove dead code and ask us to try? If you have a bit of time, then just do it. Just tell us how we can help you. I have no problem to regularly send reports. I did it for romain and David already. My advice: whatever the complains people can do right now about breaking old code, this is a kind of action that can radically change the face of Pharo, for a better future. Cheers, Alexandre Le 28 mai 2011 Ã 09:35, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > Hi, > > There is *a lot* of dead code in the image. > > I guess around 1/3 of the code base in Core is just not used at all (especially Morphic). > > One thing I would like to do is to put, at the beginning of a development cycle, > a call > > self doesAnyOneUseThisTaggedIn: 'pharo 1.3'. > > at the beginning of *all* unsent methods. And keep it even in the released image. > > This way we can, within 2-3 interations, remove *a lot* of dead code. > > Methods where people tell us that they need them, we should tag > with <api> or <public> or something like that. > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by StÃ©phane Ducasse

>> The idea of doing Pharo was never to support Squeak's code base (whch is impossible). > I know your goals, but the question still holds: How do you envision that a user of your system can port her codebase over to the next Pharo version, without going through manual costly painful hours of figuring out what changed and why it changed. > > I know you want a better system, that's cool. > > But I just want a tool that works. If it gets cooler with every iteration, nice. If there is a tool which allows me to do the transition from one version to another semi-automated, even better. > > Otherwise, I will probably stick with an old version until the pain of staying with the old system is bigger than the migration pain. The PhD of veronica is just about that. This is why Ring is designed, once Ring is integrated we will be able to build new generation tools and probably use Torch. Right now pseudo class and friends are not a solution > I am sure you heard all that before. Thus, my question: Can you envision a tool that allows me to keep up with you guys? Torch + UnitTests and we will not change everything all the time. Stef > > Thanks > Stefan > > > >> >> Marcus >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Stefan Marr

Hi Marcus: On 28 May 2011, at 16:24, Marcus Denker wrote: >> On 28 May 2011, at 15:35, Marcus Denker wrote: >>> There is *a lot* of dead code in the image. >>> >>> This way we can, within 2-3 interations, remove *a lot* of dead code. >> Which tools do you imagine to allow your users to keep up with the pace of the changes of system? >> > The question is how we can have a future with the current system. Have a look at Morphic. This is one > huge pile of Crap... > > The idea of doing Pharo was never to support Squeak's code base (whch is impossible). I know your goals, but the question still holds: How do you envision that a user of your system can port her codebase over to the next Pharo version, without going through manual costly painful hours of figuring out what changed and why it changed. I know you want a better system, that's cool. But I just want a tool that works. If it gets cooler with every iteration, nice. If there is a tool which allows me to do the transition from one version to another semi-automated, even better. Otherwise, I will probably stick with an old version until the pain of staying with the old system is bigger than the migration pain. I am sure you heard all that before. Thus, my question: Can you envision a tool that allows me to keep up with you guys? Thanks Stefan > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 28, 2011

[Pharo-project] [update 1.3] #13223

by StÃ©phane Ducasse

13223 ----- - Issue 4302: Transcript hard coded removal. http://code.google.com/p/pharo/issues/detail?id=4302 - Issue 3341: use #= for integer comparison instead of #==. Redoing and checking nicolas changes http://code.google.com/p/pharo/issues/detail?id=3341 Ok the tests do not run so I will work on it now. Stef

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Marcus Denker

On May 28, 2011, at 4:17 PM, Stefan Marr wrote: > Hi Marcus: > > > On 28 May 2011, at 15:35, Marcus Denker wrote: > >> There is *a lot* of dead code in the image. >> >> This way we can, within 2-3 interations, remove *a lot* of dead code. > Which tools do you imagine to allow your users to keep up with the pace of the changes of system? > The question is how we can have a future with the current system. Have a look at Morphic. This is one huge pile of Crap... The idea of doing Pharo was never to support Squeak's code base (whch is impossible). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Ramiro Diaz Trepat

Hi Marcus, That's a very nice idea but it is obviously very dangerous in ST, given that it's dynamically typed. You'd be completely relying on the heuristics you gather over some time. Personally, I don't think it should be done in a completelly automated way, some old smalltalkers should always look at what is going to be cut off from the image before doing so. Cheers r. On 28 May 2011 15:16, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi Marcus: > > > On 28 May 2011, at 15:35, Marcus Denker wrote: > > > There is *a lot* of dead code in the image. > > > > This way we can, within 2-3 interations, remove *a lot* of dead code. > Which tools do you imagine to allow your users to keep up with the pace of > the changes of system? > > Best regards > Stefan > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > >

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by Stefan Marr

Hi Marcus: On 28 May 2011, at 15:35, Marcus Denker wrote: > There is *a lot* of dead code in the image. > > This way we can, within 2-3 interations, remove *a lot* of dead code. Which tools do you imagine to allow your users to keep up with the pace of the changes of system? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 28, 2011

Re: [Pharo-project] TilingWM improvements

by GastÃ³n Dall' Oglio

hehehe "see new version de la barra" is "see new version of the bar", in Spanglish :) 2011/5/28 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Laurent, coincidere change this method (o part of): > > TilingWM>>newTopWindowBoundsInArea: aBlock > SystemWindow topWindow bounds: (aBlock value: world clearArea). > > to this one: > > TilingWM>>newTopWindowBoundsInArea: aBlock > | topWindow | > (topWindow := SystemWindow topWindow) isMaximized > ifTrue: [ topWindow expandBoxHit. topWindow bounds: (aBlock value: world > clearArea) ] > ifFalse: [ topWindow bounds: (aBlock value: topWindow bounds) ] > > > For one hand this solve the problem of maximized state on moved window, and > for other hand apply recursive "moving" of window based in their current > bounds (but not usable display area) if that is not in state maximize (I > choose this rule for my convenience). > > --- > > When I load new version of this package, I use the Settings to see new > version de la barra, but the old version keep visible too, and I use > SHIFT-ALT-Click to see the halos and remove this. Is possible clean up of > older versions of bar automatically? > > ---- > > And I see that you comming work in TWMWindowSnapshot :) I like it, I hate > wasting time accommodating the size and position of the windows manually > because I want to have another hearing, again and again! > > >

May 28, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by StÃ©phane Ducasse

I do not know. May be yes. Stef On May 28, 2011, at 3:35 PM, Marcus Denker wrote: > Hi, > > There is *a lot* of dead code in the image. > > I guess around 1/3 of the code base in Core is just not used at all (especially Morphic). > > One thing I would like to do is to put, at the beginning of a development cycle, > a call > > self doesAnyOneUseThisTaggedIn: 'pharo 1.3'. > > at the beginning of *all* unsent methods. And keep it even in the released image. > > This way we can, within 2-3 interations, remove *a lot* of dead code. > > Methods where people tell us that they need them, we should tag > with <api> or <public> or something like that. > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

May 28, 2011