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. |
+10000
Le 28/05/2011 15:35, Marcus Denker 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. > > |
OK for me.
Laurent.
On Sat, May 28, 2011 at 3:42 PM, Alain Plantec <[hidden email]> wrote: +10000 |
In reply to this post by Marcus Denker-4
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. > > |
In reply to this post by Marcus Denker-4
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 |
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 <[hidden email]> wrote: Hi Marcus: |
In reply to this post by Marcus Denker-4
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? > 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. |
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 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 |
>> 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 > > |
In reply to this post by Marcus Denker-4
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 <[hidden email]> 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. > > |
In reply to this post by Stefan Marr-4
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. |
In reply to this post by Marcus Denker-4
On 28. 05. 2011 15:35, Marcus Denker wrote:
> 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. To automatically track any usage of such methods, add also: - email a stack of any such method call to cleanup watcher - tag such method and count its usage out of those emails - after a year or so purge all untagged methods This way image can actually be cleaned up without much angry guys out there, also without a lot of work if cleanup is automated. Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
In reply to this post by Yanni Chiu
Hi,
In Moose we do the same. Moose builds on the latest stable Pharo, and we use this for daily development. We also use a manual update of the latest Pharo to control the deltas and understand their consequences. We migrated from Pharo 1.2 to Pharo 1.3 in about an estimated of 10h of work including testing / deploying. This was mostly due to the radical but fantastic changes in Announcements :). From 1.1 to 1.2 it was even less. So, although lots of things change behind the Pharo hood, the overall compatibility is quite high. And Moose stresses the system. So, I would not overestimate the effort of migrating. Cheers, Doru On 28 May 2011, at 17:06, Yanni Chiu wrote: > 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. > > -- www.tudorgirba.com "Value is always contextual." |
In reply to this post by Marcus Denker-4
CONTENTS DELETED
The author has deleted this message.
|
Hello. I do not know about Torch, Moose, and related tools, and I even as a novice in the art of smalltalk, I will tell an idea. If it seems very silly then simply discarded:) I also believe that sending information on that part of the system we use is vital for you to make any decisions with less risk of breakage of the tools that we ourselves use. This allows you to create statistics to revalidate the code identified as unused, or else find that use is being given. I also think they should not be sent anonymously, so as to inquire the user that sent about what use is giving the system and determine if it is a compelling reason to consider. But it should be simple and automatic for a user to send this information, much as do common applications, and should be enabled if you want it or not. But, if a user does not report about his use of the system, then can not claim to be supportive. All this collecting and sending information can only be done efficiently with a transparent tool for the user. It would be nice to know if it already exists how to use it for that purpose. 2011/5/28 Hilaire Fernandes <[hidden email]> Go on, then I will try DrGeo on it. |
In reply to this post by Marcus Denker-4
Am 28.05.2011 um 15:35 schrieb Marcus Denker: > 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. > - create a monticello package "removal20110529" - Let a tool that identified a bunch of methods change the method category to "*removal20110529" - store the monticello package - unload it which will remove the methods. This way the removals would chronologically stacked in monticello packages. A developer can now go back in time if he has problems until the point the code works again. Furthermore this would be a documentation when we removed which code. Norbert |
Administrator
|
In reply to this post by Marcus Denker-4
Dead code in the development image is not a serious problem. They may be used by specific applications.
What is desirable is to remove dead code from application images that are ready for distribution. VisualWorks has RuntimePackager to strip the application image before distribution. Pharo should have something like that. The alternative is to build an application by importing needed code into a bare bone image. Is Spoon trying to do this? All the best, Aik-Siong Koh |
In reply to this post by Marcus Denker-4
On May 29, 2011, at 9:09 PM, askoh wrote: > Dead code in the development image is not a serious problem. It is: it makes *understanding* nearly impossible. And it makes cleaning up impossible. It's not just un-used, it's *very* badly structured, in addition. There is unused code, but than there is used code that needs to be cleaned up to be faster and more compact. All the dead code makes this nearly impossible to do, as the dead code uses the system, sometimes in ways that are very strange. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
In reply to this post by askoh
On May 29, 2011, at 9:09 PM, askoh wrote: > Dead code in the development image is not a serious problem. They may be used > by specific applications. > > What is desirable is to remove dead code from application images that are > ready for distribution. VisualWorks has RuntimePackager to strip the > application image before distribution. Pharo should have something like > that. > > The alternative is to build an application by importing needed code into a > bare bone image. this is what we will do in the future. But there is no magic building good package is the way to go. > Is Spoon trying to do this? > > All the best, > Aik-Siong Koh > > -- > View this message in context: http://forum.world.st/A-radical-proposal-to-cut-down-dead-code-tp3557448p3559376.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
In reply to this post by askoh
2011/5/29 askoh <[hidden email]>:
> Is Spoon trying to do this? AFAIK, yes. As far as I understand, Craig is using a modified VM to identify sent messages and to automagically mirror them from a master to a slave image; making testcases very crucial in the process. To make a tailored image, you run all the testcases and the "needed" behavior automagically gets pushed/ pulled into the slave image. Save the slave, and you can run it indepentently. "Spoon" way - mark each sent message (within the vm) - execute a full test cycle - see what has been marked- "Tinkering way" - modify all CompiledMethods to send a "self registerAsSent: self selector object: self" by code and run a full test Two ways I could think off right now, not really deep into it. |
Free forum by Nabble | Edit this page |