[update 1.1] #11097
Locked
 
|
11097
----- Issue 1577: clean isSpecialWriteBinding (again) Issue 1585: More random dead code removal (76 unsent method removed) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [update 1.1] #11097
|
|
On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <[hidden email]> wrote: 11097 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 [hidden email] 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 <[hidden email]> 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 ? > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [update 1.1] #11097
|
|
On Sat, Dec 12, 2009 at 3:59 PM, Marcus Denker <[hidden email]> 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. Cheers, Mariano And should we remove too much: bringing back is simple. _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> wrote: > > On Dec 12, 2009, at 3:56 PM, Mariano Martinez Peck wrote: > > > > > > > On Sat, Dec 12, 2009 at 3:53 PM, Marcus Denker <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [update 1.1] #11097
|
|
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <[hidden email]> wrote:
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... _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [update 1.1] #11097
|
|
In reply to this post by Marcus Denker-3
On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <[hidden email]> wrote:
+1 In general, I hope to revisit the idea of supporting software evolution in the language... see e.g. the paper _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote: > > > On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> 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. Marcus _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [update 1.1] #11097
|
|
In reply to this post by Marcus Denker-3
On Sun, Dec 13, 2009 at 5:39 PM, Marcus Denker <[hidden email]> wrote:
Sorry, I misunderstood you then. I thought you have removed them :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |