- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Some questions on how to help

by StÃ©phane Ducasse

BTW sign the license agreement! This is on this ugly wiki :) Stef On Jun 2, 2008, at 9:28 PM, Norbert Hartl wrote: > 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 >

June 2, 2008

Re: [Pharo-project] Some questions on how to help

by StÃ©phane Ducasse

Hi norbert > 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. I imagine. I wanted to clean the inbox but I had to break some walls in my house this week-end. > 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. Yes we want that > 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? I do not know. :) Now for Number related issues I would - have a look at the fix nicolas produced - ask him - discuss that on this mailing-list and also on the squeak-dev mailing-lis > 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? Excellent. For this you can send a cs or simply state it to the mailing-list I will include the expressions in the next release scripts. > - 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. Yes but apparently this method was not well-categorized. > 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 ;) ) I have the impression :) > 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 :) Sure. My advice is - tests if it make sense - stepwise - careful - discussion on the mailing-list so that other people can have a look and comment. I think that the communication is really key. So reviewing other fixes can really help everybody. So if you go and check the changes in the inbox and comment on them, we will all gain from that. Last time marcus fixes some refs I let. But at the end been two times 2 eyes fixed the problems and we made progress. > > > Norbert > > > > > > _______________________________________________ > 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

[Pharo-project] Some questions on how to help

by Norbert Hartl

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

June 2, 2008

Re: [Pharo-project] Re: [Sapphire-devl] sapphire to pharo :)

by StÃ©phane Ducasse

Excellent! Stef On Jun 2, 2008, at 5:06 PM, Adrian Lienhard wrote: > Stef, I tried again to load Pharo starting with Squeak 3.9.1 using > the update stream and now it works! > > Adrian > > On Jun 1, 2008, at 18:26 , StÃ©phane Ducasse wrote: > >>> >>>> Done. >>>> Can you check? >>> >>> Looks good! I got beyond the problematic script. But I could not >>> load to the latest package because the SqueakSource server went >>> down in the meantime :(. Will check again later. >> >> Yes I noticed that too :) >> I was planning to do a new release. >> >> Stef >> >> >> _______________________________________________ >> 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] Mvc removing step1

by StÃ©phane Ducasse

Excellent I will collect some inbox items now that squeaksource servers are reachable. Stef On Jun 2, 2008, at 4:53 PM, Alain Plantec wrote: > On Monday 2 June 2008 16:21:57 StÃ©phane Ducasse wrote: >> Hi alain >> >> excellent. >> Did you try to reload your slice? > I've just tried it from a fresh Pharo0.1-10028-2008-05-24.image > (after a load code updates). > All seems ok. > After loading, 3 isMorphic sending remain. > they will be treated by next steps. > alain >> >> Stef >> >> On Jun 2, 2008, at 9:37 AM, Alain Plantec wrote: >> >>> Hi all >>> >>> I've upload SLICE-MvcRemoving-Step1 package to PharoInbox: >>> - I update all methods with a #isMorphic send: >>> "Smalltalk isMorphic ifTrue: [XXX] ifFalse: [YYY]" is replaced by >>> "XXX". >>> - I remove some methods which are no more useful as >>> Debugger>>buildMVCDebuggerViewLabel:minSize: >>> >>> alain >>> >>> _______________________________________________ >>> 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] EToys

by StÃ©phane Ducasse

> 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

June 2, 2008

Re: [Pharo-project] Re: [Sapphire-devl] sapphire to pharo :)

by Adrian Lienhard

Stef, I tried again to load Pharo starting with Squeak 3.9.1 using the update stream and now it works! Adrian On Jun 1, 2008, at 18:26 , StÃ©phane Ducasse wrote: >> >>> Done. >>> Can you check? >> >> Looks good! I got beyond the problematic script. But I could not >> load to the latest package because the SqueakSource server went >> down in the meantime :(. Will check again later. > > Yes I noticed that too :) > I was planning to do a new release. > > Stef > > > _______________________________________________ > 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] Mvc removing step1

by Alain Plantec

On Monday 2 June 2008 16:21:57 StÃ©phane Ducasse wrote: > Hi alain > > excellent. > Did you try to reload your slice? I've just tried it from a fresh Pharo0.1-10028-2008-05-24.image (after a load code updates). All seems ok. After loading, 3 isMorphic sending remain. they will be treated by next steps. alain > > Stef > > On Jun 2, 2008, at 9:37 AM, Alain Plantec wrote: > > > Hi all > > > > I've upload SLICE-MvcRemoving-Step1 package to PharoInbox: > > - I update all methods with a #isMorphic send: > > "Smalltalk isMorphic ifTrue: [XXX] ifFalse: [YYY]" is replaced by > > "XXX". > > - I remove some methods which are no more useful as > > Debugger>>buildMVCDebuggerViewLabel:minSize: > > > > alain > > > > _______________________________________________ > > 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] Fwd: I tried to load

by Adrian Lienhard

If you load the code programmatically, then there exists another, simple solution to ignore the progress bar which does not require to change the MC package loader. I added this to the ScriptLoader (that is the class with the update scripts that we used in 3.9 and now in Pharo). Have a look at ScriptLoader>>loadTogether:merge:silently:. I have not tested it with UIEnhancements yet but it solved the problem of loading a package with truetype font changes IIRC. Cheers, Adrian On Jun 2, 2008, at 16:14 , StÃ©phane Ducasse wrote: >> Had a go with Pharo today. UI Enhancements loads OK provided >> MCPackageLoader>>basicLoad is modified to prevent the display of >> progress >> while processing the additions. >> >> I'm thinking of some way of flaging a package for this, though MC >> would need >> quite a few changes to handle it. Perhaps pick up an extra field in >> the >> package dictionary of the mcz and, somehow, pass along to the >> PackageLoader...

June 2, 2008

RE: [Pharo-project] EToys

by Gary Chambers

OK, would be tricky anyway :-) I assume for the SLICES thing to work we are essentially forking base packages like Morphic? 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 3:25 PM > To: An open mailing list to discuss any topics related to an > open-sourceSmalltalk > Subject: Re: [Pharo-project] EToys > > > No reload of Etoy (as its current state) is important else it will > reintroduce > cruft. > I know that juan vuletcich removed etoy totally from squeak 3.7 > > http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html > > >> Just joined the mailing list. > >> > >> Was wonderering if you/we were looking at removing EToys. I'd be > >> happy to > >> help with that (it cuts deep into Morphic so should lead to some > >> simplification). A "patch up" package could be made, perhaps, to > >> reintegrate > >> EToys after loading. > > > > Welcome on board Gary. > > Yes we would like to remove EToys in 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 > > > > > _______________________________________________ > 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