June 2008 - Pharo-dev - lists.pharo.org

RE: [Pharo-project] EToys

by Gary Chambers

Damien, I don't, particularly! Just wondering what the approach is here... quite happy to rip it out altogether (might get a bit zealous with it!). Early indications are that around 200 methods can be dropped from Morph alone! Will wait for the inbox to settle first before applying my investigations to Pahro though. Regards, Gary. > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of Damien > Cassou > Sent: 03 June 2008 4:29 PM > To: An open mailing list to discuss any topics related to an > open-sourceSmalltalk > Subject: Re: [Pharo-project] EToys > > > On Mon, Jun 2, 2008 at 4:24 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > No reload of Etoy (as its current state) is important else it will > > reintroduce > > cruft. > > Why do you want to be able to reload Etoys? > > -- > 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 3, 2008

Re: [Pharo-project] EToys

by Damien Cassou

On Mon, Jun 2, 2008 at 4:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No reload of Etoy (as its current state) is important else it will > reintroduce > cruft. Why do you want to be able to reload Etoys? -- 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 3, 2008

Re: [Pharo-project] Missing development tools in Pharo

by Oscar Nierstrasz

My bad! I missed it on this page with a million links -- though I shouldn't since it is right under the pharo releases! Thanks. - on On Jun 3, 2008, at 14:53, Serge Stinckwich wrote: > Hi Oscar, > you can use the Pharo-dev image built by Damien to do that. > > 2008/6/3 Oscar Nierstrasz <oscar(a)iam.unibe.ch>: >> >> I am missing some things in Pharo, starting with the Refactoring >> Browser and >> the VB-regex package. >> >> I sympathize with the principle of keeping Pharo small, but it >> would be >> really nice if we had in the Squeak flap some buttons to load in >> much of >> this standard stuff. How hard would it be to do this? It will >> surely be >> needed for Pharo development itself, no? >> >> - on >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > http://blog.doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 3, 2008

Re: [Pharo-project] Missing development tools in Pharo

by Serge Stinckwich

Hi Oscar, you can use the Pharo-dev image built by Damien to do that. 2008/6/3 Oscar Nierstrasz <oscar(a)iam.unibe.ch>: > > I am missing some things in Pharo, starting with the Refactoring Browser and > the VB-regex package. > > I sympathize with the principle of keeping Pharo small, but it would be > really nice if we had in the Squeak flap some buttons to load in much of > this standard stuff. How hard would it be to do this? It will surely be > needed for Pharo development itself, no? > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich http://blog.doesnotunderstand.org/

June 3, 2008

[Pharo-project] Missing development tools in Pharo

by Oscar Nierstrasz

I am missing some things in Pharo, starting with the Refactoring Browser and the VB-regex package. I sympathize with the principle of keeping Pharo small, but it would be really nice if we had in the Squeak flap some buttons to load in much of this standard stuff. How hard would it be to do this? It will surely be needed for Pharo development itself, no? - on

June 3, 2008

[Pharo-project] Tools-AlexandreBergel.83 adds a dependency to OmniBrowser

by Damien Cassou

There is a reference to OB specific classes in Tools-AlexandreBergel.83. OB must not be part of pharo in my opinion. -- 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 3, 2008

RE: [Pharo-project] EToys

by Gary Chambers

Looking at the repository the "base" packages are being saved (forked from mainstream Squeak). Which is what I expected. Given the amount of stuff in the inbox I'll have to wait till things have settled down before applying the EToys removal. Bound to be some overlap with other's stuff (MVC removal, for instance). In the meantime I'll continue investigating (as part of work for producing normal Squeak "deployment" images). Regards, Gary. > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of > Stephane Ducasse > Sent: 02 June 2008 5:10 PM > To: An open mailing list to discuss any topics related to an > open-sourceSmalltalk > Subject: Re: [Pharo-project] EToys > > > > I assume for the SLICES thing to work we are essentially forking base > > packages like Morphic? > > No this is just that when people publish a fix that touches several > packages > it was a hell to identify them. Now with a slice we can get the slice > and all the packages that > are reltaed > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 3, 2008

[Pharo-project] why removing testhex?

by StÃ©phane Ducasse

Hi serge why did you remove testHex? BTW I did not receive your nice license agreement

June 3, 2008

Re: {Spam?} [Pharo-project] Some questions on how to help

by StÃ©phane Ducasse

On Jun 2, 2008, at 11:06 PM, Bill Schwab wrote: > Norbert, > > I have also noted the "return nil on error" in parsers, and (my > current > mission) streams. IMHO, these decisions were questionable before > structured exception handling, and are all the more unfortunate > now. My > preference would be to create something like #readFrom:onError: and > then > re-write #readFrom: in terms of it, raising an error inside the block. > Failing to do that risks intermittent downstream failures due to > "unexpected" garbage values. I like my bad news early, and in > context. Yes this is true that we should get rid of code that predate exception such as default block returning values > Skipping to the end of your message, I am hopeful that Pharo will not > suffer from Squeak's barriers to adoption of good code, but I cannot > promise same. It is probably best to start small and ask up-front > whether people want what you propose. I suspect you will find that > good > work will be included in Pharo. Yes and again writing tests and running them.... :) > > > 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 > > >>>> norbert(a)hartl.name 6/2/2008 2:28:15 PM >>> > Hi, > > I really appreciate the existence of the pharo project. For > me I declared it as a good starting point for me to dive > into the deeper waters of squeak/pharo. My biggest problem > is that I do not know how exactly things have to be done. > I don't want to just submit changes without to know if the > worth it. > > A little story. I started last week to toy around with the > newest pharo release. On the web site I read that all tests > green is a primary goal. So I started to let the test runner > run all tests. After having some trouble I found a failing > test in NumberParsingTest. The test is failing because the > test case expects Number>>readFrom: to throw an error if a > number couldn't be parsed. Searchig the ST80 book I found > nothing about Number>>readFrom:. Searching the web I found > a thread on squeak-dev from january where the outcome was: > > - readFrom: returns 0 on unsuccesful read attempt to satisfy > the parser (sounds like some history thing) > - readExactlyFrom: does throw an error an unsuccesful read > attempt. And it utilizes sqNumberParser > > So what to do? I tried to be least aggressive and fixed the > test case to use readExactlyFrom: (and then splitting the > test case into two because the test does different things). > Not thinking first I would have asked a lot of questions on > this list: > > - Do we want to preserve the current readFrom: ? > - Should we integrate sqNumberParser completely avoiding > mulitple implementations? > - Is it only me having slightly problems having a class > Number which uses a class SqNumberParser instead of > integrating the code into the Number hierarchy? > > Is there a way to get this questions answered without generating > a lot of noise on the list? > > Other questions: > > - I scanned the image for obsolete references and found some. I > don't know how to deal with it in an update. Using > > ServerDirectory resetServers. > FileServices removeObsolete. > PackageOrganizer default unregisterPackageNamed: > 'FlexibleVocabularies' > > I have removed all obsolete references but one. How is this > integrated into the upstream? > > - Trying to solve the last obsolete references I found an obsolete > class referenced in PasteUpMorph. The method which referenced it > is PasteUpMorph>>isSafeToServe. The method is in category > Nebraska. I thought Nebraska has been removed from the system. > Thinking that I would have removed all methods of this category > but one because they have no senders. > One method transferRemoteServerFrom: is referenced from > Project>>enter: returningFlag revert: revertFlag saveForRevert: > saveForRevert > Is it ok to rip this call out (by trying to understand what it > does in class Project ;) ) > > > Some words of advice would be helpful to get a feeling about those > things. I don't have a problem preparing some stuff and put it into > the Inbox. A problem would be to have a patch rejected without > explanation :) > > Norbert > > > > > > _______________________________________________ > 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 2, 2008

Re: [Pharo-project] Lots of modifications waiting in PharoInbox

by StÃ©phane Ducasse

lukas helped but indeed may be when marcus is back from PhD last effort. I will try to take some times with alex to show him before the end of the week. Now what would help is that some people have a look at the changes proposed. Stef On Jun 2, 2008, at 11:01 PM, Serge Stinckwich wrote: > There is now a lots of package modifications waiting in the inbox. > Is Stef the only one to integrate the changes inside Pharo ? > > -- > Serge Stinckwich > http://blog.doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 2, 2008