- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About on:
by Bill Schwab June 8, 2008

June 8, 2008

Hello all, You will find a first draft of the proposal on the Wiki. It needs some more work, but should suffice as a start. 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 >>> victorr(a)gmail.com 06/08/08 10:19 AM >>> On Sun, Jun 8, 2008 at 9:20 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, > > I saw and replied to Victor's invitation first, so we should probably just wait for him to do it. I have added you as a member. Best Regards, VÃctor RodrÃguez. > Thanks! > > 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 06/07/08 2:18 PM >>> > Just send me your google email address and I will add you. > > On Fri, Jun 6, 2008 at 10:01 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: >> Stef, >> >> I appear to have a working google account, and it seems willing to let >> me add comments to wiki pages. Is there more to do to enable me to >> edit? >> >> 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 6/6/2008 1:53:17 PM >>> >> Yes bill I think that this is important that we get one page with the >> >> proposal >> because we should find a way to make progress. >> May be with a stream factory or other method names as you suggest (if >> >> I understand correctly) >> This is important that we do not lose the ideas and proposal. >> >> Stef >> >> On Jun 6, 2008, at 6:49 PM, Victor Rodriguez wrote: >> >>> On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> >> >>> wrote: >>>> Lukas, >>>> >>>> Re "I hope that we do not have to implement our own stream >>>> hierarchy as >>>> well." >>>> >>>> I do not intend to be confrontational, but you are over-reacting. >>>> Nothing I am proposing would force you to create a stream >> hierarchy. >>>> Worry not, as I do not see my proposal being accepted anyway. I >> will >>>> simply add protocol that meets my needs, convert to it, and move >> on. >>> >>> Perhaps the Pharo project is not yet ready for your proposal, with >> so >>> many things yet to be done, but who knows what might happen in the >>> future? What about documenting your proposal in the wiki? >>> >>> Best Regards, >>> >>> Victor Rodriguez. >>> >>> >>>> If by your proposal, you mean relying on a default action to >> preserve >>>> behavior, that is not a solution. The whole point of exceptions is >> >>>> to >>>> fail loudly vs. (potentially) passing garbage into code that might >> or >>>> might not recognize what happened. The default action makes it too >> >>>> easy >>>> to miss. The very thing that keeps you happy subjects my customers >> >>>> to >>>> risk that I consider to be unacceptable, especially given that >>>> there are >>>> simple (if tedious) solutions that will avoid the problem. >>>> >>>> My particular RB limitations are based on what is built into >> Dolphin, >>>> and an old version at that. I need to see what Damien has on >>>> offer. My >>>> understanding is that the "comment abuse" is greatly reduced >>>> relative to >>>> what I have experienced. Failing that, there are other text- >>>> processing >>>> methods. >>>> >>>> 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 >>>> >>>>>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >>>>> The changes I propose would be almost trivial for them to adopt, >> and >>>>> might actually make their lives easier in targeting Dolphin, >> should >>>> they >>>>> wish to do so. >>>> >>>> Yes, I agree. The rewrite engine can fix all these things. >>>> >>>>> All arguments in favor of preserving current behavior have been >>>>> based >>>> on >>>>> backward compatibility - nothing on merits. >>>> >>>> I am only saying that keeping things backward compatible in >> critical >>>> position makes everything easier. Frankly, I like the solution I >>>> proposed and that apparently other people have thought out as well. >>>> You can use both semantics, depending on what makes more sense in >>>> your >>>> context. And best of all, it does not break existing code. I am >>>> missing a reason why Alan Knight think this solution is not good. >>>> >>>>> or Seaside, I would certainly keep Seaside going, though I suspect >>>> the >>>>> Seaside developers would accomodate us in trying to align the >>>> dialects. >>>> >>>> We never forced anybody to align their dialect. If possible, we >>>> always >>>> changed our own code. We introduced compatibility layers that >> porters >>>> can fill or we simply built our own classes. I hope that we do not >>>> have to implement our own stream hierarchy as well. >>>> >>>>> [*] I assume that I will write Dolphin code to export something >> that >>>>> Pharo can load. If any of you know of a good solution to that >>>> problem, >>>>> please let me know. In case you are wondering why the renaming is >>>> all >>>>> done in Pharo, it is because it hopefully does a better job of >>>> leaving >>>>> formatting in tact - D5's version of the RB is fairly hostile in >>>>> that >>>>> regard. >>>> >>>> The rewrite engine in Squeak/Pharo reformats all code it touches. >>>> VisualWorks has some improvements in that area. I discussed with >> John >>>> Brant and he said that these improvements are part of the >> open-source >>>> refactoring browser, however the problem is that Cincom modified >> the >>>> code and that the original improvements are not part of the >> download >>>> on John's website. Therefor it is not clear, what code is clean and >>>> what code is commercial. >>>> >>>> Cheers, >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 >> >>>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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 > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] About on:
by Bill Schwab June 8, 2008

June 8, 2008

Damien, I saw and replied to Victor's invitation first, so we should probably just wait for him to do it. Thanks! 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 06/07/08 2:18 PM >>> Just send me your google email address and I will add you. On Fri, Jun 6, 2008 at 10:01 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > I appear to have a working google account, and it seems willing to let > me add comments to wiki pages. Is there more to do to enable me to > edit? > > 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 6/6/2008 1:53:17 PM >>> > Yes bill I think that this is important that we get one page with the > > proposal > because we should find a way to make progress. > May be with a stream factory or other method names as you suggest (if > > I understand correctly) > This is important that we do not lose the ideas and proposal. > > Stef > > On Jun 6, 2008, at 6:49 PM, Victor Rodriguez wrote: > >> On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> > >> wrote: >>> Lukas, >>> >>> Re "I hope that we do not have to implement our own stream >>> hierarchy as >>> well." >>> >>> I do not intend to be confrontational, but you are over-reacting. >>> Nothing I am proposing would force you to create a stream > hierarchy. >>> Worry not, as I do not see my proposal being accepted anyway. I > will >>> simply add protocol that meets my needs, convert to it, and move > on. >> >> Perhaps the Pharo project is not yet ready for your proposal, with > so >> many things yet to be done, but who knows what might happen in the >> future? What about documenting your proposal in the wiki? >> >> Best Regards, >> >> Victor Rodriguez. >> >> >>> If by your proposal, you mean relying on a default action to > preserve >>> behavior, that is not a solution. The whole point of exceptions is > >>> to >>> fail loudly vs. (potentially) passing garbage into code that might > or >>> might not recognize what happened. The default action makes it too > >>> easy >>> to miss. The very thing that keeps you happy subjects my customers > >>> to >>> risk that I consider to be unacceptable, especially given that >>> there are >>> simple (if tedious) solutions that will avoid the problem. >>> >>> My particular RB limitations are based on what is built into > Dolphin, >>> and an old version at that. I need to see what Damien has on >>> offer. My >>> understanding is that the "comment abuse" is greatly reduced >>> relative to >>> what I have experienced. Failing that, there are other text- >>> processing >>> methods. >>> >>> 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 >>> >>>>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >>>> The changes I propose would be almost trivial for them to adopt, > and >>>> might actually make their lives easier in targeting Dolphin, > should >>> they >>>> wish to do so. >>> >>> Yes, I agree. The rewrite engine can fix all these things. >>> >>>> All arguments in favor of preserving current behavior have been >>>> based >>> on >>>> backward compatibility - nothing on merits. >>> >>> I am only saying that keeping things backward compatible in > critical >>> position makes everything easier. Frankly, I like the solution I >>> proposed and that apparently other people have thought out as well. >>> You can use both semantics, depending on what makes more sense in >>> your >>> context. And best of all, it does not break existing code. I am >>> missing a reason why Alan Knight think this solution is not good. >>> >>>> or Seaside, I would certainly keep Seaside going, though I suspect >>> the >>>> Seaside developers would accomodate us in trying to align the >>> dialects. >>> >>> We never forced anybody to align their dialect. If possible, we >>> always >>> changed our own code. We introduced compatibility layers that > porters >>> can fill or we simply built our own classes. I hope that we do not >>> have to implement our own stream hierarchy as well. >>> >>>> [*] I assume that I will write Dolphin code to export something > that >>>> Pharo can load. If any of you know of a good solution to that >>> problem, >>>> please let me know. In case you are wondering why the renaming is >>> all >>>> done in Pharo, it is because it hopefully does a better job of >>> leaving >>>> formatting in tact - D5's version of the RB is fairly hostile in >>>> that >>>> regard. >>> >>> The rewrite engine in Squeak/Pharo reformats all code it touches. >>> VisualWorks has some improvements in that area. I discussed with > John >>> Brant and he said that these improvements are part of the > open-source >>> refactoring browser, however the problem is that Cincom modified > the >>> code and that the original improvements are not part of the > download >>> on John's website. Therefor it is not clear, what code is clean and >>> what code is commercial. >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 > >>> >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- 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

2 1

Re: [Pharo-project] About on:
by Bill Schwab June 7, 2008

June 7, 2008

Stef, I appear to have a working google account, and it seems willing to let me add comments to wiki pages. Is there more to do to enable me to edit? 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 6/6/2008 1:53:17 PM >>> Yes bill I think that this is important that we get one page with the proposal because we should find a way to make progress. May be with a stream factory or other method names as you suggest (if I understand correctly) This is important that we do not lose the ideas and proposal. Stef On Jun 6, 2008, at 6:49 PM, Victor Rodriguez wrote: > On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> > wrote: >> Lukas, >> >> Re "I hope that we do not have to implement our own stream >> hierarchy as >> well." >> >> I do not intend to be confrontational, but you are over-reacting. >> Nothing I am proposing would force you to create a stream hierarchy. >> Worry not, as I do not see my proposal being accepted anyway. I will >> simply add protocol that meets my needs, convert to it, and move on. > > Perhaps the Pharo project is not yet ready for your proposal, with so > many things yet to be done, but who knows what might happen in the > future? What about documenting your proposal in the wiki? > > Best Regards, > > Victor Rodriguez. > > >> If by your proposal, you mean relying on a default action to preserve >> behavior, that is not a solution. The whole point of exceptions is >> to >> fail loudly vs. (potentially) passing garbage into code that might or >> might not recognize what happened. The default action makes it too >> easy >> to miss. The very thing that keeps you happy subjects my customers >> to >> risk that I consider to be unacceptable, especially given that >> there are >> simple (if tedious) solutions that will avoid the problem. >> >> My particular RB limitations are based on what is built into Dolphin, >> and an old version at that. I need to see what Damien has on >> offer. My >> understanding is that the "comment abuse" is greatly reduced >> relative to >> what I have experienced. Failing that, there are other text- >> processing >> methods. >> >> 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 >> >>>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >>> The changes I propose would be almost trivial for them to adopt, and >>> might actually make their lives easier in targeting Dolphin, should >> they >>> wish to do so. >> >> Yes, I agree. The rewrite engine can fix all these things. >> >>> All arguments in favor of preserving current behavior have been >>> based >> on >>> backward compatibility - nothing on merits. >> >> I am only saying that keeping things backward compatible in critical >> position makes everything easier. Frankly, I like the solution I >> proposed and that apparently other people have thought out as well. >> You can use both semantics, depending on what makes more sense in >> your >> context. And best of all, it does not break existing code. I am >> missing a reason why Alan Knight think this solution is not good. >> >>> or Seaside, I would certainly keep Seaside going, though I suspect >> the >>> Seaside developers would accomodate us in trying to align the >> dialects. >> >> We never forced anybody to align their dialect. If possible, we >> always >> changed our own code. We introduced compatibility layers that porters >> can fill or we simply built our own classes. I hope that we do not >> have to implement our own stream hierarchy as well. >> >>> [*] I assume that I will write Dolphin code to export something that >>> Pharo can load. If any of you know of a good solution to that >> problem, >>> please let me know. In case you are wondering why the renaming is >> all >>> done in Pharo, it is because it hopefully does a better job of >> leaving >>> formatting in tact - D5's version of the RB is fairly hostile in >>> that >>> regard. >> >> The rewrite engine in Squeak/Pharo reformats all code it touches. >> VisualWorks has some improvements in that area. I discussed with John >> Brant and he said that these improvements are part of the open-source >> refactoring browser, however the problem is that Cincom modified the >> code and that the original improvements are not part of the download >> on John's website. Therefor it is not clear, what code is clean and >> what code is commercial. >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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

2 1

[Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/
by Victor Rodriguez June 7, 2008

June 7, 2008

Hello all, I have "moved" all the wiki pages from the INRIA gforge wiki to the google code one. I believe I got all the pages, but it won't hurt if someone can double check, which will be very easy, because I left a "wiki has moved" message in all moved pages. I did some very minor cleanup, mostly making sure lists and links appear correctly, but most pages still need to be fixed. Please help cleaning up the new wiki! I suggest for us to be very aggressive on keeping the wiki in a good shape. On second thought, make that *very very* aggresive :-). I know it is a lot of work, but there is nothing worse than a messy wiki. Conversely, nothing speaks better of an open source project than a clean and useful wiki. Ã votre service, VÃctor RodrÃguez.

4 7

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Lukas, Re "I hope that we do not have to implement our own stream hierarchy as well." I do not intend to be confrontational, but you are over-reacting. Nothing I am proposing would force you to create a stream hierarchy. Worry not, as I do not see my proposal being accepted anyway. I will simply add protocol that meets my needs, convert to it, and move on. If by your proposal, you mean relying on a default action to preserve behavior, that is not a solution. The whole point of exceptions is to fail loudly vs. (potentially) passing garbage into code that might or might not recognize what happened. The default action makes it too easy to miss. The very thing that keeps you happy subjects my customers to risk that I consider to be unacceptable, especially given that there are simple (if tedious) solutions that will avoid the problem. My particular RB limitations are based on what is built into Dolphin, and an old version at that. I need to see what Damien has on offer. My understanding is that the "comment abuse" is greatly reduced relative to what I have experienced. Failing that, there are other text-processing methods. 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 >>> renggli(a)gmail.com 06/06/08 9:13 AM >>> > The changes I propose would be almost trivial for them to adopt, and > might actually make their lives easier in targeting Dolphin, should they > wish to do so. Yes, I agree. The rewrite engine can fix all these things. > All arguments in favor of preserving current behavior have been based on > backward compatibility - nothing on merits. I am only saying that keeping things backward compatible in critical position makes everything easier. Frankly, I like the solution I proposed and that apparently other people have thought out as well. You can use both semantics, depending on what makes more sense in your context. And best of all, it does not break existing code. I am missing a reason why Alan Knight think this solution is not good. > or Seaside, I would certainly keep Seaside going, though I suspect the > Seaside developers would accomodate us in trying to align the dialects. We never forced anybody to align their dialect. If possible, we always changed our own code. We introduced compatibility layers that porters can fill or we simply built our own classes. I hope that we do not have to implement our own stream hierarchy as well. > [*] I assume that I will write Dolphin code to export something that > Pharo can load. If any of you know of a good solution to that problem, > please let me know. In case you are wondering why the renaming is all > done in Pharo, it is because it hopefully does a better job of leaving > formatting in tact - D5's version of the RB is fairly hostile in that > regard. The rewrite engine in Squeak/Pharo reformats all code it touches. VisualWorks has some improvements in that area. I discussed with John Brant and he said that these improvements are part of the open-source refactoring browser, however the problem is that Cincom modified the code and that the original improvements are not part of the download on John's website. Therefor it is not clear, what code is clean and what code is commercial. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] 40 kb limt on Mails
by Norbert Hartl June 6, 2008

June 6, 2008

Hi, I sent a mail yesterday evening that was about 43 kb in size (I've attached a changeset). The list sent me a notice that the maximum limit on this list is 40kb and it waits for approval of the list admin. Is that a feasible size if you take into account that there can be changeset that some sends to the list? Who is this list admin? Stephane? Norbert

2 1

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Victor, I will be happy to do that, as soon as I figure out how to get access to it :) Marginal attempts at humor not withstanding, I need to update my web page links to make things easier on me - hopefully that will happen today. 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 >>> victorr(a)gmail.com 6/6/2008 11:49 AM >>> On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Lukas, > > Re "I hope that we do not have to implement our own stream hierarchy as > well." > > I do not intend to be confrontational, but you are over-reacting. > Nothing I am proposing would force you to create a stream hierarchy. > Worry not, as I do not see my proposal being accepted anyway. I will > simply add protocol that meets my needs, convert to it, and move on. Perhaps the Pharo project is not yet ready for your proposal, with so many things yet to be done, but who knows what might happen in the future? What about documenting your proposal in the wiki? Best Regards, Victor Rodriguez. > If by your proposal, you mean relying on a default action to preserve > behavior, that is not a solution. The whole point of exceptions is to > fail loudly vs. (potentially) passing garbage into code that might or > might not recognize what happened. The default action makes it too easy > to miss. The very thing that keeps you happy subjects my customers to > risk that I consider to be unacceptable, especially given that there are > simple (if tedious) solutions that will avoid the problem. > > My particular RB limitations are based on what is built into Dolphin, > and an old version at that. I need to see what Damien has on offer. My > understanding is that the "comment abuse" is greatly reduced relative to > what I have experienced. Failing that, there are other text-processing > methods. > > 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 > >>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >> The changes I propose would be almost trivial for them to adopt, and >> might actually make their lives easier in targeting Dolphin, should > they >> wish to do so. > > Yes, I agree. The rewrite engine can fix all these things. > >> All arguments in favor of preserving current behavior have been based > on >> backward compatibility - nothing on merits. > > I am only saying that keeping things backward compatible in critical > position makes everything easier. Frankly, I like the solution I > proposed and that apparently other people have thought out as well. > You can use both semantics, depending on what makes more sense in your > context. And best of all, it does not break existing code. I am > missing a reason why Alan Knight think this solution is not good. > >> or Seaside, I would certainly keep Seaside going, though I suspect > the >> Seaside developers would accomodate us in trying to align the > dialects. > > We never forced anybody to align their dialect. If possible, we always > changed our own code. We introduced compatibility layers that porters > can fill or we simply built our own classes. I hope that we do not > have to implement our own stream hierarchy as well. > >> [*] I assume that I will write Dolphin code to export something that >> Pharo can load. If any of you know of a good solution to that > problem, >> please let me know. In case you are wondering why the renaming is > all >> done in Pharo, it is because it hopefully does a better job of > leaving >> formatting in tact - D5's version of the RB is fairly hostile in that >> regard. > > The rewrite engine in Squeak/Pharo reformats all code it touches. > VisualWorks has some improvements in that area. I discussed with John > Brant and he said that these improvements are part of the open-source > refactoring browser, however the problem is that Cincom modified the > code and that the original improvements are not part of the download > on John's website. Therefor it is not clear, what code is clean and > what code is commercial. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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 > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Lukas, The changes I propose would be almost trivial for them to adopt, and might actually make their lives easier in targeting Dolphin, should they wish to do so. The current semantics are <candidMode>watered-down to the point of being pointless, all in the name of being backwardly compatible with something that was questionable even before the existence of tools for exceptions and handling of same</candidMode>. All arguments in favor of preserving current behavior have been based on backward compatibility - nothing on merits. It will be interesting to see what happens when it comes time to de-cruft morphic - *that* will break external code. I will grant you one thing though: if I were to choose between breaking old morphic code or Seaside, I would certainly keep Seaside going, though I suspect the Seaside developers would accomodate us in trying to align the dialects. All they would need to do is use a selector to match the semantics they have learned to accept. It is the first disk pack I would burn - well, maybe just after underscore assignment has been scorched down to the sub-atomic level :) I will probably end up taking some of my own advice. Once my code can move to Pharo[*], I will probably load it into a throw-away image, using the RB therein to rename selectors. The first step would be to get #next and #next: "out of the way," by naming them #nextOrNil and #nextAvailable: - that's what they do. Load my code, and then rename #next to #nextOne and #next: to #nextMany:. These methods would signal EndOfStreamError (new name) to steer clear of default actions. Filing out and loading the resulting code should allow me to safely avoid the (to me deprecated) #next and #next:. It is a shame though, as they are the natural selectors one would want to use. Some slips detection based on packages and/or developer name would help me catch myself should I revert. It is precisely the risk of using the simpler/misleading selectors that has me convinced the breaking change is needed. Failing that, I need to at least solve it for my own code, and I will of course make that available to all. [*] I assume that I will write Dolphin code to export something that Pharo can load. If any of you know of a good solution to that problem, please let me know. In case you are wondering why the renaming is all done in Pharo, it is because it hopefully does a better job of leaving formatting in tact - D5's version of the RB is fairly hostile in that regard. 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 >>> renggli(a)gmail.com 6/5/2008 11:10:07 AM >>> > ANSI is a standard and there are cases where it is wrong (commitee decisions > = compromise) I agree, however changing the behavior of #next means that we will not be able to develop Seaside on Pharo. Seaside takes great advantage that Squeak is ANSI compatible. Lukas > > On Jun 5, 2008, at 3:27 PM, Bill Schwab wrote: > > > > Lukas, > > > > I have blind copied someone who can comment, or not at his discretion, > > on Cincom's view on this; he never said he was commenting off the > > record, but I try to err toward assuming that. I got the distinct sense > > that they are contemplating a change of some type and are also > > struggling with backward compatibility. > > > > You are correct about ANSI; I was shocked to see what they did. > > Without reservation, I assert the standard is wrong. Exception handling > > was created to allow the widespread elimination of precisely the > > condition that arises when #next reads off the end of a stream. I can > > always (and probably will if we do not fix this) deprecate #next and > > #next: in my own work, but that still leaves inconsistencies between and > > within dialects. > > > > 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 > > > > > > > > > > > > > > > > > > renggli(a)gmail.com 6/5/2008 7:18 AM >>> > > > > > > > > > Yes, but it is not consistent, and they are apparently not happy > > > > > > > > > with it. > > > > Why? Can you give any pointers? > > > > > > > Object Arts' solution is consistent both with itself and with yoga of > > > > > structured exception handling. However, at this point, it appears that > > you do not want to make the change, so I will stop pressing. > > > > As far as I see this is inconsistent with the ANSI standard. > > > > Cheers, > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > 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 > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Alan, I appreciate your time and respect your opinion. However, I do indeed consider ANSI's handling of #next to be wrong. Since I appear to be the outlier here, I will proceed with my backup plan unless I hear otherwise. You are of course correct that I *can* test for the end of stream every time I use #next, but I argue that the entire point of exceptions is to enable things like #next to be used safely, meaning without trusting the programmer to do such things. Note that the exceptions have to have teeth (no default action) in order to provide protection. If you have not read it, I highly recommend Maguier's Writing Solid Code. Be warned about the sub-title: "Microsoft's Techniques for Writing Bug-free C Programs." I know -- too bad they haven't read it! The publisher's hypocrisy aside, it is an excellent book. The chapter "Candy Machine Interfaces" is particularly relevant. Also, do not miss the disassembler example - great stuff! Then think back to your childhood. I just barely remember matchbooks that had the strike strip on the front; the books were of course REALLY old at the time :) Match books still say "close cover before striking," but some clever person decided to put the strip on the back, forcing the user to put some type of barrier between the strip and the remaining match heads. Another Microsoft document offers insight. At least the original MFC tutorials made a point of using new objects w/o testing for error conditions or null pointers, all thanks to exceptions. When I last looked, they pitched "smooth scrolling" (ways to make the computer draw even more than necessary) instead of tackling the finer points of redraw optimization as they once did. Who knows what else was cut. Kinda pathetic, but I digress. Absent robust and consistent use of exceptions, #next is an accident waiting to happen. The simplest course of action for me is to design something that is safe and consistent, and ensure that I use it over inconsistent alternatives. BTW, I do a LOT of stream I/O, so I do not trust myself any more than I do some idiot striking a match :) Happy Smalltalking! 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 >>> Alan Knight <knight(a)acm.org> 06/05/08 9:12 PM >>> Um, I guess that'd be me, but I'm missing a bit of context here. I guess you're probably not talking about #on:, but about #next, which I had discussed earlier with Bill. I had glanced at the ANSI standard and it appeared to me that it left the behaviour undefined. I don't know if you could characterize that as "wrong". A bad idea, perhaps, but it can't be wrong because it doesn't say anything. With respect to next, what VisualWorks does is raise an EndOfStream exception which is a notification. If not caught, it proceeds with nil. I don't think this is a good idea, and would like to at least make it not common behaviour. But I can't see changing the behaviour that a read past end of stream results in a nil. That assumption is pretty deep in a lot of Smalltalk code, and I think (without checking) that it is what all the dialects except Dolphin do. I note that it's not necessary to avoid the use of next in your own code if you don't like the behaviour. Just use it in conjunction with an atEnd test. At 09:27 AM 6/5/2008, Bill Schwab wrote: >Lukas, > >I have blind copied someone who can comment, or not at his discretion, >on Cincom's view on this; he never said he was commenting off the >record, but I try to err toward assuming that. I got the distinct sense >that they are contemplating a change of some type and are also >struggling with backward compatibility. > >You are correct about ANSI; I was shocked to see what they did. >Without reservation, I assert the standard is wrong. Exception handling >was created to allow the widespread elimination of precisely the >condition that arises when #next reads off the end of a stream. I can >always (and probably will if we do not fix this) deprecate #next and >#next: in my own work, but that still leaves inconsistencies between and >within dialects. > >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 > > >>>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> >> > Yes, but it is not consistent, and they are apparently not happy >with it. > >Why? Can you give any pointers? > >> Object Arts' solution is consistent both with itself and with yoga of >structured exception handling. However, at this point, it appears that >you do not want to make the change, so I will stop pressing. > >As far as I see this is inconsistent with the ANSI standard. > >Cheers, >Lukas > >-- >Lukas Renggli >http://www.lukas-renggli.ch > >_______________________________________________ >Pharo-project mailing list >Pharo-project(a)lists.gforge.inria.fr >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/smalltalk

1 0

June 6, 2008

Begin forwarded message: > From: Alan Knight <knight(a)acm.org> > Date: June 6, 2008 2:05:34 PM CEDT > To: pharo-project-owner(a)lists.gforge.inria.fr > Cc: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Subject: Re: [Pharo-project] About on: > > I guess I'm a non-member and not allowed to post, but it'd probably > be good if you could forward this. > >> Um, I guess that'd be me, but I'm missing a bit of context here. I >> guess you're probably not talking about #on:, but about #next, >> which I had discussed earlier with Bill. >> >> I had glanced at the ANSI standard and it appeared to me that it >> left the behaviour undefined. I don't know if you could >> characterize that as "wrong". A bad idea, perhaps, but it can't be >> wrong because it doesn't say anything. >> >> With respect to next, what VisualWorks does is raise an EndOfStream >> exception which is a notification. If not caught, it proceeds with >> nil. I don't think this is a good idea, and would like to at least >> make it not common behaviour. But I can't see changing the >> behaviour that a read past end of stream results in a nil. That >> assumption is pretty deep in a lot of Smalltalk code, and I think >> (without checking) that it is what all the dialects except Dolphin >> do. >> >> I note that it's not necessary to avoid the use of next in your own >> code if you don't like the behaviour. Just use it in conjunction >> with an atEnd test. >> >> At 09:27 AM 6/5/2008, Bill Schwab wrote: >>> Lukas, >>> >>> I have blind copied someone who can comment, or not at his >>> discretion, >>> on Cincom's view on this; he never said he was commenting off the >>> record, but I try to err toward assuming that. I got the distinct >>> sense >>> that they are contemplating a change of some type and are also >>> struggling with backward compatibility. >>> >>> You are correct about ANSI; I was shocked to see what they did. >>> Without reservation, I assert the standard is wrong. Exception >>> handling >>> was created to allow the widespread elimination of precisely the >>> condition that arises when #next reads off the end of a stream. I >>> can >>> always (and probably will if we do not fix this) deprecate #next and >>> #next: in my own work, but that still leaves inconsistencies >>> between and >>> within dialects. >>> >>> 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 >>> >>> >>> >>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> >>> > > Yes, but it is not consistent, and they are apparently not >>> happy >>> with it. >>> >>> Why? Can you give any pointers? >>> >>> > Object Arts' solution is consistent both with itself and with >>> yoga of >>> structured exception handling. However, at this point, it appears >>> that >>> you do not want to make the change, so I will stop pressing. >>> >>> As far as I see this is inconsistent with the ANSI standard. >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Alan Knight [|], Engineering Manager, Cincom Smalltalk >> knight(a)acm.org >> aknight(a)cincom.com >> http://www.cincom.com/smalltalk > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > knight(a)acm.org > aknight(a)cincom.com > http://www.cincom.com/smalltalk

1 0