- Pharo-dev - lists.pharo.org

Re: [Pharo-project] new to pharo

by Alain Plantec

> > ok, I'm starting by chasing all senders to the isMorphic message I've a .cs that touch a lot of methods everywhere**. now, what is the procedure ? can I put my .cs somewhere, give it to somebody, make a .mcz with it ? (I do not known how) sorry for all these stupid questions, I try to understand the update process. thanks alain ** for all #isMorphic senders: "self isMorphic ifTrue: [XXXXX] ifFalse: [YYYYY]" is replaced with "XXXXX"

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Damien Cassou

On Fri, May 30, 2008 at 6:17 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > No I don't agree. Because it is not likely that there is a test for Matrix > that will show a potential bug. I just wanted to point out that it is > important to precisely look at the effect of such "global" transformations. > (E.g. like Edgar tried to replace all #== with #= IIRC ;) > > With your proposed change, I think it is unlikely you will break anything, > but you cannot say for sure without detailled *manual* checking. The > difficulty is that you theoretically needed to verify that there is never > passed a Matrix instance to "ReadStream on:". I don't understand why you are choosing this example of Matrix. Since Matrix is not an Array nor a String, it is impossible that a code like 'ReadStream on: aMatrix' ever worked. In fact, this reasoning could be applied to any other class which is neither Array nor String or one of their subclasses. > Also to consider with such changes is that you may break external code that > you don't know of. How? If don't remove any method. Existing code should still work. Do you have any example in mind? >To sum up, I'm not against such improvements at all, but > they have to be done carefully, i.e., the argument that tests will show any > problem does not hold. I knew the tests argument did not hold because there are so few tests in Squeak, I was joking :-). I'm trying to do the changes carrefully, that's why I commited things package after package instead of doing it globally. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Bill Schwab

Damien, I don't think I care how we do it (Nile should be fine), so long as we end up with good stream behavior. In my mind, that means breaking some things (on an informal survey, I find a lot of stuff that should not care because it never hits the nil return value), and I am volunteering to help fix what I help break, provided we agree up front to use the transformed code (assuming it works). I doubt the latter will a problem with this group, as long as we plan and then do the work. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 05/30/08 12:02 PM >>> On Fri, May 30, 2008 at 5:54 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, > > The only potential problem is that you assume tests will catch everything. However, I think streams are broken, and I will certainly help fix what we break in getting them right. I guess the change I'm applying won't cause any problem but I can't be sure. I won't loose time fixing Streams as I would prefer installing Nile if everybody agree. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Bill Schwab

Adrian, Fair enough, but some house cleaning is also in order, and it *will* break some external code. If we fail to do the right things, we will have just another failed fork. Do the right things, and people will do right things to their code to get the benefits of a successful open Smalltalk. Just my 2 asCents. BTW, I *think* you will find that anyone wanting to fix external code can simply grab an image with it, use the what ever transformations we end up defining on their code (installing the RB might be a challenge??), export the fixed code, and file it into Pharo. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> adi(a)netstyle.ch 05/30/08 12:17 PM >>> On May 30, 2008, at 15:37 , Damien Cassou wrote: > On Fri, May 30, 2008 at 2:18 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> Have you verified that your change does not inadvertently modify any >> behavior? Its not likely, but changes like this can introduce >> subtle bugs. >> For instance, Matrix overrides readStream. So if there exists any >> use of >> "ReadStream on: aMatrix" that is there to bypass the overridden >> behavior, >> the code will break. > > It should not break anything (if it does, the test will fail and I > will fix things :-)). In fact, ReadStream only deals with > SequenceableStreams so it should be ok. Do you agree? No I don't agree. Because it is not likely that there is a test for Matrix that will show a potential bug. I just wanted to point out that it is important to precisely look at the effect of such "global" transformations. (E.g. like Edgar tried to replace all #== with #= IIRC ;) With your proposed change, I think it is unlikely you will break anything, but you cannot say for sure without detailled *manual* checking. The difficulty is that you theoretically needed to verify that there is never passed a Matrix instance to "ReadStream on:". Also to consider with such changes is that you may break external code that you don't know of. To sum up, I'm not against such improvements at all, but they have to be done carefully, i.e., the argument that tests will show any problem does not hold. Cheers, Adrian > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Adrian Lienhard

On May 30, 2008, at 15:37 , Damien Cassou wrote: > On Fri, May 30, 2008 at 2:18 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> Have you verified that your change does not inadvertently modify any >> behavior? Its not likely, but changes like this can introduce >> subtle bugs. >> For instance, Matrix overrides readStream. So if there exists any >> use of >> "ReadStream on: aMatrix" that is there to bypass the overridden >> behavior, >> the code will break. > > It should not break anything (if it does, the test will fail and I > will fix things :-)). In fact, ReadStream only deals with > SequenceableStreams so it should be ok. Do you agree? No I don't agree. Because it is not likely that there is a test for Matrix that will show a potential bug. I just wanted to point out that it is important to precisely look at the effect of such "global" transformations. (E.g. like Edgar tried to replace all #== with #= IIRC ;) With your proposed change, I think it is unlikely you will break anything, but you cannot say for sure without detailled *manual* checking. The difficulty is that you theoretically needed to verify that there is never passed a Matrix instance to "ReadStream on:". Also to consider with such changes is that you may break external code that you don't know of. To sum up, I'm not against such improvements at all, but they have to be done carefully, i.e., the argument that tests will show any problem does not hold. Cheers, Adrian > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Damien Cassou

On Fri, May 30, 2008 at 5:54 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, > > The only potential problem is that you assume tests will catch everything. However, I think streams are broken, and I will certainly help fix what we break in getting them right. I guess the change I'm applying won't cause any problem but I can't be sure. I won't loose time fixing Streams as I would prefer installing Nile if everybody agree. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Bill Schwab

Damien, The only potential problem is that you assume tests will catch everything. However, I think streams are broken, and I will certainly help fix what we break in getting them right. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 05/30/08 9:37 AM >>> On Fri, May 30, 2008 at 2:18 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Have you verified that your change does not inadvertently modify any > behavior? Its not likely, but changes like this can introduce subtle bugs. > For instance, Matrix overrides readStream. So if there exists any use of > "ReadStream on: aMatrix" that is there to bypass the overridden behavior, > the code will break. It should not break anything (if it does, the test will fail and I will fix things :-)). In fact, ReadStream only deals with SequenceableStreams so it should be ok. Do you agree? -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2008

Re: [Pharo-project] open AtomBouncingMorphs in 3.7 and 3.9 is amazing...

by Bill Schwab

Stef, Let me guess: 3.7 is MUCH faster, right??? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 05/30/08 11:25 AM >>> Hi guys it would be really interesting to understand why there is a so large difference between the two. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2008

Re: [Pharo-project] Replacing 'ReadStream on smth:' by 'smth readStream'

by Bill Schwab

Damien, That would be great. It does me little good in my current version of Dolphin, though I should look at the more recent versions. Making a long story short, D6 broke a lot of my code and reduced compatibility with win2k (the big show-stopper for me at the time), so I never upgraded. I am currently far more bothered by unwanted changes in Windows than I have ever been by deficiencies in Dolphin. IIRC, some of the breaking changes are now understood, so it might pay to have another look, though I still need to run on win2k, just (sadly IMHO) not as much as a few years ago. Another option would be to load code into Pharo and hit it with an up to date RB. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 05/30/08 9:47 AM >>> On Fri, May 30, 2008 at 2:13 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Interesting! As an aside, I have a love/hate relationship with the RB, and almost never let it rewrite any of my Dolphin code. The XP guys will recoil in horror at this, but I have too often been saved by 18 month old comments to have them disrespectfully scattered around my source. If that is fixed, I will become a believer. I *do* use pull up/down to great advantage, and will sometimes use other refactorings on new code that has not had time to accumulate valuable comments. This problem has been fixed some time ago IIRC. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2008

[Pharo-project] open AtomBouncingMorphs in 3.7 and 3.9 is amazing...

by StÃ©phane Ducasse

Hi guys it would be really interesting to understand why there is a so large difference between the two. Stef

May 30, 2008