[Pharo-project] [update 1.1] #11097
11097 ----- Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed)
On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker@acm.org> wrote:
11097 -----
Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed)
Marcus, when you this kind of removal (unsent methods), do you check also on Dev and Web image? or just core ? Cheers, Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Dec 12, 2009, at 3:56 PM, Mariano Martinez Peck wrote:
On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker@acm.org> wrote: 11097 -----
Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed)
Marcus, when you this kind of removal (unsent methods), do you check also on Dev and Web image? or just core ?
right now I only check the core... :-) But the methods removed are of the kind that they really should not be part of a public API.... And should we remove too much: bringing back is simple. Marcus
On Sat, Dec 12, 2009 at 3:59 PM, Marcus Denker <denker@acm.org> wrote:
On Dec 12, 2009, at 3:56 PM, Mariano Martinez Peck wrote:
On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker@acm.org> wrote: 11097 -----
Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed)
Marcus, when you this kind of removal (unsent methods), do you check also
on Dev and Web image? or just core ?
right now I only check the core... :-)
But the methods removed are of the kind that they really should not be part of a public API....
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests. Cheers, Mariano
And should we remove too much: bringing back is simple.
Marcus _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes I think that you have two kind of unsent methods - the one that are not sent - the one that are not sent but were really specific to an experiment: uniClasses, project, automatic conversion... :) Stef On Dec 12, 2009, at 6:37 PM, Mariano Martinez Peck wrote:
On Sat, Dec 12, 2009 at 3:59 PM, Marcus Denker <denker@acm.org> wrote:
On Dec 12, 2009, at 3:56 PM, Mariano Martinez Peck wrote:
On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <denker@acm.org> wrote: 11097 -----
Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed)
Marcus, when you this kind of removal (unsent methods), do you check also on Dev and Web image? or just core ?
right now I only check the core... :-)
But the methods removed are of the kind that they really should not be part of a public API....
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Cheers,
Mariano
And should we remove too much: bringing back is simple.
Marcus _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Yes... but there is really stuff that nobody needs. For the other, we should just put removals on the bugtracker and make sure that we check with the main image before removal... In general, I hope to revisit the idea of supporting software evolution in the language... see e.g. the paper http://scg.unibe.ch/scgbib?query=Nier08b&display=abstract for some thoughts of what is needed. Marcus
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker@acm.org> wrote:
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Yes... but there is really stuff that nobody needs.
Yes, of course. But for example, the other day ifNil:ifNotNilDo: and ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for example O2. Cheers, Mariano
For the other, we should just put removals on the bugtracker and make sure that we check with the main image before removal...
In general, I hope to revisit the idea of supporting software evolution in the language... see e.g. the paper http://scg.unibe.ch/scgbib?query=Nier08b&display=abstract for some thoughts of what is needed.
Marcus _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote:
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker@acm.org> wrote:
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Yes... but there is really stuff that nobody needs.
Yes, of course. But for example, the other day ifNil:ifNotNilDo: and ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for example O2.
No, I just change all senders of those methods... to use the one without Do:, which is inlined and thus much faster. And nicer. But I left the methods for now. (I did not even deprecate them, as they tend to be used a lot) Marcus
On Dec 13, 2009, at 5:39 PM, Marcus Denker wrote:
On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote:
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker@acm.org> wrote:
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Yes... but there is really stuff that nobody needs.
Yes, of course. But for example, the other day ifNil:ifNotNilDo: and ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for example O2.
No, I just change all senders of those methods... to use the one without Do:, which is inlined and thus much faster. And nicer.
... and that was for ifNotEmptyDo:, refactoring to call ifNotNil: ist on the TODO (hundrets of senders... ParseTreeRewriter to the rescue. Marcus
On Sun, Dec 13, 2009 at 5:39 PM, Marcus Denker <denker@acm.org> wrote:
On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote:
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker@acm.org> wrote:
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in
itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Yes... but there is really stuff that nobody needs.
Yes, of course. But for example, the other day ifNil:ifNotNilDo: and ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for example O2.
No, I just change all senders of those methods... to use the one without Do:, which is inlined and thus much faster. And nicer. But I left the methods for now. (I did not even deprecate them, as they tend to be used a lot)
Sorry, I misunderstood you then. I thought you have removed them :)
Marcus _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker@acm.org> wrote:
IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests.
Yes... but there is really stuff that nobody needs.
For the other, we should just put removals on the bugtracker and make sure that we check with the main image before removal...
+1
In general, I hope to revisit the idea of supporting software evolution in the language... see e.g. the paper http://scg.unibe.ch/scgbib?query=Nier08b&display=abstract for some thoughts of what is needed.
Marcus _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse