[Pharo-project] A radical proposal (to cut down dead code)
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 <alain.plantec@yahoo.com>wrote:
+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.
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.
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 <pharo@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
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.
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."
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@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.
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
Go on, then I will try DrGeo on it. I would love to reduce the size image of the DrGeo4XO, the image is still 14MB after cleaning. Hilaire 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.
-- Education 0.2 -- http://blog.ofset.org/hilaire
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 <hilaire.fernandes@gmail.com>
Go on, then I will try DrGeo on it.
I would love to reduce the size image of the DrGeo4XO, the image is still 14MB after cleaning.
Hilaire
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.
-- Education 0.2 -- http://blog.ofset.org/hilaire
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.
I like the idea although I think it is dangerous. I think we could provide a layer of backward compatibility. It is dead code so these are things that are there but unused. So removing them does not force any other change. A removal could be done this way: - 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
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 -- View this message in context: http://forum.world.st/A-radical-proposal-to-cut-down-dead-code-tp3557448p355... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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-tp3557448p355... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
2011/5/29 askoh <askoh@askoh.com>:
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.
By the way, I think this is very interesting - as squeak depends on an image that's "there", being bootstrapped in the old days. GNU Smalltalk takes the approach of having a vm based compiler that bootstrap on request. "Java" having a centrally bootstrapped set of libraries by oracle (sun)...
Options are good, but one algorithm that tries to get it all right is probably asking for trouble. Dolphin has an elaborate stripper, but I found that slicing out unreferenced packages would typically give me a 4 MB or so executable. I was able to strip further, but it took time and raised the possibility of runtime failures. Which tests drive the stripping? They could easily be broader than strictly necessary, causing otherwise unneeded things to be retained. I agree with Stef that good packaging is the place to start. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Markus Fritsche [fritsche.markus@googlemail.com] Sent: Sunday, May 29, 2011 4:57 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A radical proposal (to cut down dead code) 2011/5/29 askoh <askoh@askoh.com>:
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.
How far along are we with making good packages for Pharo? 60%?? -- View this message in context: http://forum.world.st/A-radical-proposal-to-cut-down-dead-code-tp3557448p355... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On May 30, 2011, at 1:58 AM, askoh wrote:
How far along are we with making good packages for Pharo? 60%??
To obtain what? What are your constraints? Did you try to unload packages? Our goal is to bootstrap an image and we will go there step by step. One step is to remove StringHolder and friends from the image and replace them by something less messy Stef
-- View this message in context: http://forum.world.st/A-radical-proposal-to-cut-down-dead-code-tp3557448p355... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Regarding this subject I think: 1. There's impossible to authoritatively classify anything as "dead code" unless there's a reference standard of what's core and what's not core (like, Java defines the JFCs). At this point it would be useful to have a reference standard of "core classes" and their "core messages/methods". 2. Having a reference model, it would be nice to have a way preventing modifications of core classes inside official distribution. Meaning: to be considered part of an official pharo distribution, code must not alter foundation classes. That shouldn't be an issue due to huge support for inheritance provided by smalltalk. So, if need arises to have, let's say, a new message/method inside something like Array or OrderedCollection or whathever, it's easy to do that simply creating MyNewLittleOrderedCollection... It's not hard to verify integrity of core classes using digital signatures. 3. There should be an official policy for marking code as "obsolete" or "deprecated". I guess that once a model of reference classes is established, it's easier to start profiling things and finding what's alive and what's dead (not used anymore inside an official distribution). It also prevents the uncontrolled growth of "core stuff" as consequence of ad-hoc solutions. A plus advantage of defining a set of core classes is that it makes easy to fully document and analyze them. It allows to ensure several things that are required for any system to be used in the development of serious commercial software: 1. Profiling (theoretical/measured): known algorithms 2. Security 1. Regarding continuous operation and up time 2. Regarding "civilized" use of resources (memory, IO) 3. Regarding integrity of data 4. Regarding misuse & unforeseen uses of classes/messages/resources 5. Regarding privacy 6. etc... 3. It makes it possible to have serious end user documentation, clearly specifying functionality, interfaces, cases of use, limits, error conditions, etc. (side comment: it never went into my mind de discourse of "documentation is the code" (moreover when some code is not easily understandable)). My 2¢ CdAB
[It's] impossible to authoritatively classify anything as "dead code" unless there's a reference standard of what's core and what's not core...
Yeah, in the meantime I define "dead" as "not run for some amount of time". -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
On Mon, May 30, 2011 at 6:50 PM, Craig Latta <craig@netjam.org> wrote:
[It's] impossible to authoritatively classify anything as "dead code" unless there's a reference standard of what's core and what's not core...
Yeah, in the meantime I define "dead" as "not run for some amount of time".
Surely "dead" means not used in the transitive closure of useful packages. I don't see anyone in this thread proposing to trawl Monticello repositories looking for the latest versions of packages and then analysing what messages these packages send. IMO, only by doing this will you be able to define what's used in the image. One could try and relate the messages used to the publish date of packages to try and get some idea of the up-to-date-ness of messages. One can perhaps attempt to make some determination of the liveness of the package by asking the community (basing this on e.g. last time it was downloaded creates the heisenbug of package trawling needing to download packages. Am I mad or is the set of packages out there in Monitcello repositories and on SqueakMap what really constitutes the working set that the base image needs to support? best, Eliot
-C
-- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
On May 31, 2011, at 4:27 AM, Eliot Miranda wrote:
On Mon, May 30, 2011 at 6:50 PM, Craig Latta <craig@netjam.org> wrote:
[It's] impossible to authoritatively classify anything as "dead code" unless there's a reference standard of what's core and what's not core...
Yeah, in the meantime I define "dead" as "not run for some amount of time".
Surely "dead" means not used in the transitive closure of useful packages. I don't see anyone in this thread proposing to trawl Monticello repositories looking for the latest versions of packages and then analysing what messages these packages send. IMO, only by doing this will you be able to define what's used in the image. One could try and relate the messages used to the publish date of packages to try and get some idea of the up-to-date-ness of messages. One can perhaps attempt to make some determination of the liveness of the package by asking the community (basing this on e.g. last time it was downloaded creates the heisenbug of package trawling needing to download packages.
Yes. I hope that we will be able to use a Ring based code database + metacello configuration repository for that.
Am I mad or is the set of packages out there in Monitcello repositories and on SqueakMap what really constitutes the working set that the base image needs to support?
best, Eliot
-C
-- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
Em 30/05/2011 23:27, Eliot Miranda < eliot.miranda@gmail.com > escreveu:
On Mon, May 30, 2011 at 6:50 PM, Craig Latta <craig@netjam.org> wrote:
[It's] impossible to authoritatively classify anything as "dead
code" unless there's a reference standard of what's core and what's not core... Yeah, in the meantime I define "dead" as "not run for some amount of time".
Surely "dead" means not used in the transitive closure of useful packages. Â I don't see anyone in this thread proposing to trawl Monticello repositories looking for the latest versions of packages and then analysing what messages these packages send.
Perhaps could we use this insight and reverse the consequent and the antecedent: how about have Monticello when having packages deposited create a database of messages sent? To start it could be just a set and afterwards we could go after the "real thing" with a kind of associative tree so we could know which packages are clients of which methods. my 0.1999999..... -- Cesar Rabak
On 31 May 2011 05:27, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mon, May 30, 2011 at 6:50 PM, Craig Latta <craig@netjam.org> wrote:
[It's] impossible to authoritatively classify anything as "dead code" unless there's a reference standard of what's core and what's not core...
  Yeah, in the meantime I define "dead" as "not run for some amount of time".
Surely "dead" means not used in the transitive closure of useful packages. Â I don't see anyone in this thread proposing to trawl Monticello repositories looking for the latest versions of packages and then analysing what messages these packages send. Â IMO, only by doing this will you be able to define what's used in the image. Â One could try and relate the messages used to the publish date of packages to try and get some idea of the up-to-date-ness of messages. Â One can perhaps attempt to make some determination of the liveness of the package by asking the community (basing this on e.g. last time it was downloaded creates the heisenbug of package trawling needing to download packages. Am I mad or is the set of packages out there in Monitcello repositories and on SqueakMap what really constitutes the working set that the base image needs to support?
Unless you intentionally want to replace old code with new, and possibly with different API. Then scheme for automatic scanning all users of some code could show you unwanted results. Anyways , i think it is futile to attempt to implement an automated analyzis tool for that. Only developer could say what is dead (or what should be dead) anyways. Of course, things like Ring will help us to analyze the code and track its change history. But still, a final decision, what to call "dead" and what "alive" will always be up to humans.
best, Eliot
-- Best regards, Igor Stasenko AKA sig.
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.
I see that process ("imprinting") as useful in a first attempt at defining modules for a large existing subsystem, or for ad-hoc transfer of behavior between systems (at a demo, for example). But in normal use, one will start from a system in which everything is already factored clearly, nothing unnecessary is hanging around, and the goal is simply not to mess that up. :) -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
Hi Aik-Siong-- I agree with Markus that dead code is a huge problem, in its obstruction to understanding.
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?
Yes. My intent is that no one need ever strip an image again. thanks, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment. Laurent. On Sat, May 28, 2011 at 3:35 PM, Marcus Denker <marcus.denker@inria.fr>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.
On 31 May 2011 21:44, laurent laffont <laurent.laffont@gmail.com> wrote:
Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment.
Laurent, have you tried to run lint rule checker in pharo image? I tried once and if i remember correctly, there are like 30000 notices. Now, what you think, is it possible for any human to visit all of them step by step analyze and then fix the code? It is enormous amount of data (and most of it is just white noise, or insignificant detail). Now how to filter that noise and address the only things which you should take care of? And since we're continuting development, every time you doing an update, this stuff should be revisited, compared and cross-checked again. And we don't have such facility: take image A and B, and compare their lint output. I imagine this would require a quite sophisticated database , with UI on top of that, which will allow you to navigate through these notices mark them as invalid, or fixed etc etc.. What i mean that automated tools is cool. But they cannot solve all our problems: every such issue should be analyzed and considered by developer. Because we're still not yet at the point, where system can reason about itself and automatically improve itself without need of our attention :) If this day will come, then it will be the end of humanity (at least in its current form - homo sapiens sapiens ;)
Laurent.
-- Best regards, Igor Stasenko AKA sig.
On Tue, May 31, 2011 at 9:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 May 2011 21:44, laurent laffont <laurent.laffont@gmail.com> wrote:
Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment.
Laurent, have you tried to run lint rule checker in pharo image?
No - I talk about test coverage, not lint. I don't think lint worth running on a full image. Test coverage is really useful. Indeed, I use test coverage on my projects every day. Lint once a year :) Laurent.
I tried once and if i remember correctly, there are like 30000 notices. Now, what you think, is it possible for any human to visit all of them step by step analyze and then fix the code? It is enormous amount of data (and most of it is just white noise, or insignificant detail). Now how to filter that noise and address the only things which you should take care of? And since we're continuting development, every time you doing an update, this stuff should be revisited, compared and cross-checked again. And we don't have such facility: take image A and B, and compare their lint output. I imagine this would require a quite sophisticated database , with UI on top of that, which will allow you to navigate through these notices mark them as invalid, or fixed etc etc.. What i mean that automated tools is cool. But they cannot solve all our problems: every such issue should be analyzed and considered by developer. Because we're still not yet at the point, where system can reason about itself and automatically improve itself without need of our attention :) If this day will come, then it will be the end of humanity (at least in its current form - homo sapiens sapiens ;)
Laurent.
-- Best regards, Igor Stasenko AKA sig.
Em 31-05-2011 16:12, Igor Stasenko escreveu:
On 31 May 2011 21:44, laurent laffont <laurent.laffont@gmail.com> wrote:
Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment. Laurent, have you tried to run lint rule checker in pharo image? I tried once and if i remember correctly, there are like 30000 notices. Now, what you think, is it possible for any human to visit all of them step by step analyze and then fix the code? It is enormous amount of data (and most of it is just white noise, or insignificant detail). Now how to filter that noise and address the only things which you should take care of? Here comes the importance of having a foundation or any other kind of entity enabled to run for financial resources necessary to keep people, doing these "insane tasks" :) as well as physical resources (computers with versions of OS, etc)... And since we're continuting development, every time you doing an update, this stuff should be revisited, compared and cross-checked again. And we don't have such facility: take image A and B, and compare their lint output. Here comes the importance of agreeing about a closed (in terms of scope) and reduced (in terms of size (ie, # of classes and messages)) core that can be frozen while cleaning is done. Otherwise it's like manufacturing an airplane while it's flying from factory to owner... which increases the "insanity factor" several orders of magnitude. I imagine this would require a quite sophisticated database , with UI on top of that, which will allow you to navigate through these notices mark them as invalid, or fixed etc etc.. What i mean that automated tools is cool. But they cannot solve all our problems: every such issue should be analyzed and considered by developer. Because we're still not yet at the point, where system can reason about itself and automatically improve itself without need of our attention :) If this day will come, then it will be the end of humanity (at least in its current form - homo sapiens sapiens ;)
Laurent.
Additionally, one issue with metacello is that it incorporates both infra-structure stuff and things that are more like end-user applications. It's not a tradition to keep things orthogonal: there is code that inserts/deletes/modifies things in places that should constitute foundations. For instance, some time ago there was discussion about ad-hoc (thus mostly undocumented) methods/messages in places like OrderedCollection... What's the sense in this state of affairs? IMHO it's an ad-hoc situation and cleaning process must fix & transform it into a sustainable situation. That's overcoming past.
CdAB
On 1 June 2011 00:42, Casimiro de Almeida Barreto <casimiro.barreto@gmail.com> wrote:
Em 31-05-2011 16:12, Igor Stasenko escreveu:
On 31 May 2011 21:44, laurent laffont <laurent.laffont@gmail.com> wrote:
Another idea (don't know how hard it is) is to have test coverage + comment coverage in Hudson. Then we can start to consider that dead code = code with no test or no comment. Laurent, have you tried to run lint rule checker in pharo image? I tried once and if i remember correctly, there are like 30000 notices. Now, what you think, is it possible for any human to visit all of them step by step analyze and then fix the code? It is enormous amount of data (and most of it is just white noise, or insignificant detail). Now how to filter that noise and address the only things which you should take care of? Here comes the importance of having a foundation or any other kind of entity enabled to run for financial resources necessary to keep people, doing these "insane tasks" :) as well as physical resources (computers with versions of OS, etc)... And since we're continuting development, every time you doing an update, this stuff should be revisited, compared and cross-checked again. And we don't have such facility: take image A and B, and compare their lint output. Here comes the importance of agreeing about a closed (in terms of scope) and reduced (in terms of size (ie, # of classes and messages)) core that can be frozen while cleaning is done. Otherwise it's like manufacturing an airplane while it's flying from factory to owner... which increases the "insanity factor" several orders of magnitude.
Nice allegory. I like it. I personally insane enough, that i would like to be able to manufacture airplane while it flying from factory to owner. Because life is short, and you not always sure that fix you just made is final one.. maybe there are some more, which you may need to add in a last minute :) Code is just another form of data, and smalltalk is an exceptionally brilliant proof of it. And as any data we should learn how to transform it without breaking it into meaningless pieces. I'd like to know, how we can teach system (and ourselves) to understand that whole is more than just a sum of elementary parts. A system can be extremely modular. Modules can be as little as one module per class (or even per object). But the thing is, no matter how small the bricks and how well (an fully) you studied every piece which you put into system. Because when these pieces start interacting with each other - they creating a multidimentional space, where it is no longer possible to prove anything: - are your system secure? - is it stable? - is it bug free? - is it performant? etc etc
I imagine this would require a quite sophisticated database , with UI on top of that, which will allow you to navigate through these notices mark them as invalid, or fixed etc etc.. What i mean that automated tools is cool. But they cannot solve all our problems: every such issue should be analyzed and considered by developer. Because we're still not yet at the point, where system can reason about itself and automatically improve itself without need of our attention :) If this day will come, then it will be the end of humanity (at least in its current form - homo sapiens sapiens ;)
Laurent.
Additionally, one issue with metacello is that it incorporates both infra-structure stuff and things that are more like end-user applications. It's not a tradition to keep things orthogonal: there is code that inserts/deletes/modifies things in places that should constitute foundations. For instance, some time ago there was discussion about ad-hoc (thus mostly undocumented) methods/messages in places like OrderedCollection... What's the sense in this state of affairs? IMHO it's an ad-hoc situation and cleaning process must fix & transform it into a sustainable situation. That's overcoming past.
CdAB
-- Best regards, Igor Stasenko AKA sig.
participants (21)
-
Alain Plantec -
Alexandre Bergel -
askoh -
Casimiro de Almeida Barreto -
Craig Latta -
csrabak＠bol.com.br -
Eliot Miranda -
Gastón Dall' Oglio -
Hilaire Fernandes -
Igor Stasenko -
Janko Mivšek -
laurent laffont -
Marcus Denker -
Markus Fritsche -
Norbert Hartl -
Ramiro Diaz Trepat -
Schwab,Wilhelm K -
Stefan Marr -
Stéphane Ducasse -
Tudor Girba -
Yanni Chiu