- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/

by Victor Rodriguez

On Fri, Jun 6, 2008 at 3:45 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: ... > Thank you very much for that. Did you see you could assign tags to > wiki pages? These tags are: I saw the tags, and I tried to categorize all the wiki pages with whatever seemed appropriate, although I was going for speed not accuracy. As a matter of fact, I added a new tag, "Wiki-Needs-Cleaning", and put it in all the migrated pages. My hope is that it will invite people to clean up the pages, but I'll do it myself when I get a chance. Since we can redefine the tags, we can probably come up with something that makes sense for us. We can have a tag for "fixes in other projects", "tasks", etc... I'll see if I can come up with some ideas when I go over the pages again. BTW, I couldn't resist abusing my increased admin rights and took the liberty to setup forwarding of comments made wiki pages to the list. This way people can suggest changes they are unsure or unable to make themselves. Saludos, VÃctor. > Featured = Listed on project home page > Phase-Requirements = Project vision and requirements > Phase-Design = Project design and key concerns > Phase-Implementation = Developers' guide > Phase-QA = Testing plans and QA strategies > Phase-Deploy = How to install and configure the program > Phase-Support = Plans for user support and advocacy > Deprecated = Most users should NOT reference this > > The system allows us to add new tags. Do you have ideas? > > -- > 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 >

June 7, 2008

Re: [Pharo-project] About on:

by Bill Schwab

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

June 6, 2008

Re: [Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/

by Adrian Lienhard

Thanks Victor, Looks good. I improved the visual structure of the HowToContribute page (http://code.google.com/p/pharo/wiki/HowToContribute) Cheers, Adrian On Jun 6, 2008, at 05:27 , Victor Rodriguez wrote: > 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 6, 2008

Re: [Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/

by Damien Cassou

On Fri, Jun 6, 2008 at 5:27 AM, Victor Rodriguez <victorr(a)gmail.com> wrote: > 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. Thank you very much for that. Did you see you could assign tags to wiki pages? These tags are: Featured = Listed on project home page Phase-Requirements = Project vision and requirements Phase-Design = Project design and key concerns Phase-Implementation = Developers' guide Phase-QA = Testing plans and QA strategies Phase-Deploy = How to install and configure the program Phase-Support = Plans for user support and advocacy Deprecated = Most users should NOT reference this The system allows us to add new tags. Do you have ideas? -- 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)

June 6, 2008

Re: [Pharo-project] Re: Wiki pages moved to http://code.google.com/p/pharo/

by Damien Cassou

On Fri, Jun 6, 2008 at 5:31 AM, Victor Rodriguez <victorr(a)gmail.com> wrote: > On Thu, Jun 5, 2008 at 11:27 PM, Victor Rodriguez <victorr(a)gmail.com> wrote: > ... >> Please help cleaning up the new wiki! > > BTW, I forgot to mention that I couldnÂ´t fix the front page. Someone > please do it, or take the leap of faith and make me an administrator. > :-) You should be able to do it now. -- 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)

June 6, 2008

Re: [Pharo-project] About on:

by StÃ©phane Ducasse

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 >

June 6, 2008

Re: [Pharo-project] 40 kb limt on Mails

by StÃ©phane Ducasse

me I accepted the email but apparently did not show up Can you resend it but to me? Stef On Jun 6, 2008, at 4:24 PM, Norbert Hartl wrote: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 6, 2008

Re: [Pharo-project] About on:

by Bill Schwab

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

June 6, 2008

Re: [Pharo-project] About on:

by Victor Rodriguez

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 >

June 6, 2008

[Pharo-project] 40 kb limt on Mails

by Norbert Hartl

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

June 6, 2008