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

[Pharo-project] Fwd: New update

by StÃ©phane Ducasse

> > > > 0006834: Delay class>>timeoutSemaphore:afterMSecs: doesn't. > Description The implementation for Delay > class>>timeoutSemaphore:afterMSecs: doesn't even use its first > parameter, so it can't do what it says it does. > > This method should be deprecated or removed entirely. > Additional Information + tests > > + obsolete references identified by norbert > > Stef > > >

June 2, 2008

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

by Bill Schwab

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. 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. 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

June 2, 2008

[Pharo-project] Lots of modifications waiting in PharoInbox

by Serge Stinckwich

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/

June 2, 2008

[Pharo-project] Merging 6834

by StÃ©phane Ducasse

I'm merging 0006834: Delay class>>timeoutSemaphore:afterMSecs: doesn't. Description The implementation for Delay class>>timeoutSemaphore:afterMSecs: doesn't even use its first parameter, so it can't do what it says it does. This method should be deprecated or removed entirely. Additional Information + tests

June 2, 2008

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

Re: [Pharo-project] EToys

by StÃ©phane Ducasse

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 >

June 2, 2008

Re: [Pharo-project] Mvc removing step1

by StÃ©phane Ducasse

Hi alain excellent. Did you try to reload your slice? 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

[Pharo-project] Fwd: I tried to load

by StÃ©phane Ducasse

Begin forwarded message: > From: "Gary Chambers" <gary(a)pinesoft.co.uk> > Date: June 2, 2008 2:48:17 PM CEDT > To: "stephane ducasse" <stephane.ducasse(a)free.fr> > Subject: RE: I tried to load > > 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... > > Regards, Gary. > >> -----Original Message----- >> From: stephane ducasse [mailto:stephane.ducasse@free.fr] >> Sent: 22 May 2008 6:13 PM >> To: Gary Chambers >> Subject: Re: I tried to load >> >> >> Thanks I will check. >> I can load 60 without any problems. >> >> Stef >> >>> Sounds like an MC load order problem again. >>> The change was for double-dispatching of use of fill-styles back to >>> the >>> fill-style itself to support more complex/composite fill styles. >>> >>> Best to try to load with the MCPackageLoader>>basicLoad modification >>> and as >>> few windows etc. as possible. >>> >>> Let me know if your problems persist and I'll give it a go too. >>> >>> Regards, Gary. >> >> > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA >

June 2, 2008

RE: [Pharo-project] EToys

by Gary Chambers

Thanks. I've managed a simple proof of concept with some simple changes that should help in rooting out its tendrils :-) (main EToys package unloaded without image "crash") Gary. > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]On Behalf Of Serge > Stinckwich > Sent: 02 June 2008 2:22 PM > To: An open mailing list to discuss any topics related to an > open-sourceSmalltalk > Subject: Re: [Pharo-project] EToys > > > 2008/6/2 Gary Chambers <gazzaguru2(a)btinternet.com>: > > 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

June 2, 2008

Re: [Pharo-project] EToys

by Serge Stinckwich

2008/6/2 Gary Chambers <gazzaguru2(a)btinternet.com>: > 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/

June 2, 2008

[Pharo-project] EToys

by Gary Chambers

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. Regards, Gary.

June 2, 2008

[Pharo-project] Mvc removing step1

by Alain Plantec

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

June 2, 2008

[Pharo-project] Fwd: Discussion about Nile in Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Date: June 1, 2008 9:34:45 PM CEDT > To: <stephane.ducasse(a)inria.fr> > Cc: <knight(a)acm.org>, <damien.cassou(a)gmail.com> > Subject: Re: Discussion about Nile in Pharo > > Stef, > > I agree, though I would exchange the order. The RB fix of #next is > simple, and I doubt there will ever be a completely painless time to > do it. So I would do the rename, add the new/changed methods, and > then convert to Nile, having updated its semantics prior to the > conversion. > > 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 > >>>> StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 06/01/08 3:07 PM >>> > I think that you should > > - use the mailing-list > - separate two things > - the use of Nile as default > - the fix of the behavior next: > > Stef > > On Jun 1, 2008, at 3:27 PM, Bill Schwab wrote: > >> Damien, >> >> That is a great next step. Dumb question: do I already have an >> account by virtue of being on the list, or do I need to create one? >> >> Your rewrite to cope with #on: is fascinating, but I continue to >> wonder whether it is necessary. In fact, I _think_ I would prefer >> to rename the Nile classes (either up front or probably post-install >> via the RB) to be generic. While I too prefer idioms such as Array >> writeStream and aCollection readStream, #on: is perfectly ok, though >> clumsy. What we should do depends on your goal, and of course on >> what works best. >> >> Changing to Nile via #readStream and #writeStream has its >> advantages, but the rewrite has made me greedy :) I am thinking of >> something like the following: >> >> (1) prepare the image by renaming methods (#next -> #nextOrNil:, >> #next -> #nextAvailable:) to reflect current silently-truncating >> semantics >> >> (2) add the silent truncating methods to Nile; add #on: methods to >> Nile, including comments referencing the shortcut methods >> >> (3) change Nile's #next, #next: to raise errors; noting that after >> (1), the image will call the truncating methods, and only new code >> will see the errors >> >> (4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or >> perhaps better yet just ask the RB to rename the Nile classes, so >> that one codes in terms of ReadStream, WriteStream, catches >> EndOfStream. We can provide a defined set of RB steps that anyone >> can use in a throw-away image to prepare code that we did not fix >> for them; it should basically be step (1). >> >> Comments? If you at all agree, feel free to edit and put it on the >> Wiki while I figure out how to access it. >> >> 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" <damien.cassou(a)gmail.com> 06/01/08 6:30 AM >>> >> Hi Bill, >> >> I writing a wiki page where I explain what we can do to slowly >> install Nile: >> https://gforge.inria.fr/plugins/wiki/index.php?refs=NileInstallation&id=129… >> >> You can help me with the redaction. >> >> -- >> 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 2, 2008

Re: [Pharo-project] SqueakSource down ?

by Serge Stinckwich

No problem Adrian, i can wait ;-) 2008/6/1 Adrian Lienhard <adi(a)netstyle.ch>: > yes, again the server is not responding anymore. Unfortunately, we canot do > anything until the server admin guys come in tomorrow morning. > > Adrian > > On Jun 1, 2008, at 21:18 , Serge Stinckwich wrote: > >> SqueakSource down ? >> >> -- >> 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 > -- Serge Stinckwich http://blog.doesnotunderstand.org/

June 1, 2008

Re: [Pharo-project] SqueakSource down ?

by Adrian Lienhard

yes, again the server is not responding anymore. Unfortunately, we canot do anything until the server admin guys come in tomorrow morning. Adrian On Jun 1, 2008, at 21:18 , Serge Stinckwich wrote: > SqueakSource down ? > > -- > 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 1, 2008

[Pharo-project] SqueakSource down ?

by Serge Stinckwich

SqueakSource down ? -- Serge Stinckwich http://blog.doesnotunderstand.org/

June 1, 2008

[Pharo-project] Fwd: Discussion about Nile in Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Date: June 1, 2008 4:32:46 PM CEDT > To: <damien.cassou(a)gmail.com> > Cc: <knight(a)acm.org>, <stephane.ducasse(a)inria.fr> > Subject: Re: Discussion about Nile in Pharo > > Damien, > > A partial reply. Interesting point about the various collection > classes. Perhaps we can double-dispatch to make the creation work, > something like > > ReadStream on:aCollection > ^aCollection readStream. > > ReadStream and friends would exist, but concrete classes would be > instantiated. Could that work? It would be along the lines of > Squeak's file directories, where the programmer can think in > abstractions and the code does the right thing (and instantiates the > correct classes) for the platform. > > As far as #next, my proposal is to avoid the error altogether by > transforming (RB) old code so that it uses #nextOrNil and will work > as before, but without abusing the contentious selector. > Untransformed old code would likely break, but there would be a > procedure for using a throw-away Squeak image to fix it for > inclusion in Pharo, and we would have already done transformed code > considered to be part of Pharo. My instinct tells me to get it done > up front, for fear that the backward-compatibility arguments would > prevent doing it in the future. I am not usually a disk-pack > arsonist, but in this case, the sooner the better IMHO. Again, a > few messages to the RB, and nothing changes except we rename the > abused selector. Everything continues to work; new code can work as > it should. > > I can check with Dolphin, but I do not believe #peek* are affected. > It could get interesting for sockets where new elements could be in > transit, but the general feel of peek is to look and either move > past the element or leave the position unchanged; the latter would > probably be what happens. I will ponder and look at the other > 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 > >>>> "Damien Cassou" <damien.cassou(a)gmail.com> 06/01/08 9:47 AM >>> > On Sun, Jun 1, 2008 at 3:27 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> > wrote: >> That is a great next step. Dumb question: do I already have an >> account by virtue of being on the list, or do I need to create one? > > You have to create an account I think. Then, you has to ask the pharo > project to join. We will receive a mail and will be able to accept > your request (or refuse, we will see :-D). > > >> Your rewrite to cope with #on: is fascinating, but I continue to >> wonder whether it is necessary. In fact, I _think_ I would prefer >> to rename the Nile classes (either up front or probably post- >> install via the RB) to be generic. While I too prefer idioms such >> as Array writeStream and aCollection readStream, #on: is perfectly >> ok, though clumsy. What we should do depends on your goal, and of >> course on what works best. > > > I do not agree for the following reasons: > > - in Nile, there is just one class which is the equivalent of > ReadStream, WriteStream and ReadWriteStream. It is named > NSCollectionStream. There is no one-to-one relation. > - in Nile, there are specific classes to handle strings and arrays, > NSStringStream and NSArrayStream.How do you change the existing source > code to use the right stream class depending on the collection class? > > >> Changing to Nile via #readStream and #writeStream has its >> advantages, but the rewrite has made me greedy :) I am thinking of >> something like the following: >> >> (1) prepare the image by renaming methods (#next -> #nextOrNil:, >> #next -> #nextAvailable:) to reflect current silently-truncating >> semantics > > > - I'm not sure we should do this change now. I would prefer waiting > that Nile is the default Stream implementation. That way, we avoid > changing the Squeak Stream library. Moreover, I think people need more > time to think about throwing errors with #next. They need to see how > that change will affect their code in practice. Moreover, this change > might introduce a lot of new methods like peekIfAvailable and others. > > >> (2) add the silent truncating methods to Nile; > >> add #on: methods to Nile, including comments referencing the >> shortcut methods > > > #on: is already in Nile and it is the only way to create a new > collection stream. > > >> (3) change Nile's #next, #next: to raise errors; noting that after >> (1), the image will call the truncating methods, and only new code >> will see the errors >> >> (4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or >> perhaps better yet just ask the RB to rename the Nile classes, so >> that one codes in terms of ReadStream, WriteStream, catches >> EndOfStream. We can provide a defined set of RB steps that anyone >> can use in a throw-away image to prepare code that we did not fix >> for them; it should basically be step (1). >> >> Comments? If you at all agree, feel free to edit and put it on the >> Wiki while I figure out how to access it. > > > > -- > 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 1, 2008

[Pharo-project] Fwd: Discussion about Nile in Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Date: June 1, 2008 3:27:45 PM CEDT > To: <damien.cassou(a)gmail.com> > Cc: <knight(a)acm.org>, <stephane.ducasse(a)inria.fr> > Subject: Re: Discussion about Nile in Pharo > > Damien, > > That is a great next step. Dumb question: do I already have an > account by virtue of being on the list, or do I need to create one? > > Your rewrite to cope with #on: is fascinating, but I continue to > wonder whether it is necessary. In fact, I _think_ I would prefer > to rename the Nile classes (either up front or probably post-install > via the RB) to be generic. While I too prefer idioms such as Array > writeStream and aCollection readStream, #on: is perfectly ok, though > clumsy. What we should do depends on your goal, and of course on > what works best. > > Changing to Nile via #readStream and #writeStream has its > advantages, but the rewrite has made me greedy :) I am thinking of > something like the following: > > (1) prepare the image by renaming methods (#next -> #nextOrNil:, > #next -> #nextAvailable:) to reflect current silently-truncating > semantics > > (2) add the silent truncating methods to Nile; add #on: methods to > Nile, including comments referencing the shortcut methods > > (3) change Nile's #next, #next: to raise errors; noting that after > (1), the image will call the truncating methods, and only new code > will see the errors > > (4) either Smalltalk at:#ReadStream put:NSReadStream, etc., or > perhaps better yet just ask the RB to rename the Nile classes, so > that one codes in terms of ReadStream, WriteStream, catches > EndOfStream. We can provide a defined set of RB steps that anyone > can use in a throw-away image to prepare code that we did not fix > for them; it should basically be step (1). > > Comments? If you at all agree, feel free to edit and put it on the > Wiki while I figure out how to access it. > > 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" <damien.cassou(a)gmail.com> 06/01/08 6:30 AM >>> > Hi Bill, > > I writing a wiki page where I explain what we can do to slowly > install Nile: > https://gforge.inria.fr/plugins/wiki/index.php?refs=NileInstallation&id=129… > > You can help me with the redaction. > > -- > 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 1, 2008

[Pharo-project] I added the 3.10.1 list of fixes to the wiki.

by StÃ©phane Ducasse

June 1, 2008

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

by StÃ©phane Ducasse

Good! Stef On Jun 1, 2008, at 3:58 PM, Bill Schwab wrote: > Stef, > > My email server crashed yesterday and was out of action for several > hours. From emails I found this morning, it looks like Damien and I > will cook up a plan on the Wiki. With luck, we will be able to get > the > RB to do the tedious work, and also leave a simple defined procedure > for > converting "old" code that we did not have loaded during the > transformation. Transformed code should work as it always did; new > code > will be able to benefit from consistent semantics and exception > handling. There will also be silently truncating methods for the > situations (and they indeed exist) that call for them. > > More to come. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 05/31/08 4:22 PM >>> > > On May 30, 2008, at 10:46 PM, Bill Schwab wrote: > >> Stef, >> >> Whether or not I agree depends on what you mean. While I think I >> see where Damien is going, my read is that #on: is actually >> negotiable, given that we should be able to either fix (or simply >> replace and than alias) ReadStream - two different ways of solving >> the same problem. But if you concerned about breaking some things >> that Damien and I are committed to fixing as part of the change, >> then I submit that we will be helpless when we move from the >> relatively calm world of streams to the chaos of morphic. > > You lost me. :) > > >> Which part bothers you? > > None :) > >> The plan is to rennovate (sometimes messy) and *then* slowly evolve >> the resulting stable system, right? > > The plan is to move but be careful. This is why I would like you guys > to tell us > what you want to do (or are doing) so that we can document the changes > and everybody can participate > and help also fixing if necessary. I just want more organized > communication when we have a "big" change. > No more. > > 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 1, 2008

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

by StÃ©phane Ducasse

> >> 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

June 1, 2008

Re: [Pharo-project] [ANN][Pharo-dev] First release

by Damien Cassou

On Sun, Jun 1, 2008 at 4:47 PM, Serge Stinckwich <serge.stinckwich(a)doesnotunderstand.org> wrote: > 2008/6/1 Damien Cassou <damien.cassou(a)gmail.com>: >>>>> I hope to have a server soon for the universe >>>> >>>> I think it will be difficult to maintain a universe server (each time >>>> you update a package on the squeak universe, you will have to do it >>>> again for pharo). >> >> A Universe is a set of packages. You want another set. If I change the >> Squeak set, the Pharo set won't be updated. This has some advantages >> (we control what appears in our universe), but has the big >> disadvantage of duplicating my effort to update the Squeak Universe. > > I guess Squeak Universe manage versions ? Why not consider Pharo as a > specific Squeak version ? I think it does not change anything. Once you create a universe (from scratch or from another one), I don't think updates in one goes to the other. -- 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 1, 2008

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

by Adrian Lienhard

On May 31, 2008, at 22:17 , 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. Adrian > > > I will redo a full upgrade in a clean package cache. > > Stef > > On May 31, 2008, at 11:40 AM, Adrian Lienhard wrote: > >> Hi Stef, >> >> Today I tried again to load Pharo starting from a fresh 3.9.1 image >> but I got the same error when loading "10015-Sap- >> FixingInvisibleInTheRest..." (see my mail in this thread from May >> 16). >> >> I had a closer look and the problem is that script106 tries to load >> Protocols-sd.13.mcz, which does not exist in the repository. >> I guess the update worked for you because this file was in your >> local cache. Can you copy this package to the repository? >> >> Adrian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 1, 2008

Re: [Pharo-project] [ANN][Pharo-dev] First release

by Serge Stinckwich

2008/6/1 Damien Cassou <damien.cassou(a)gmail.com>: >>>> I hope to have a server soon for the universe >>> >>> I think it will be difficult to maintain a universe server (each time >>> you update a package on the squeak universe, you will have to do it >>> again for pharo). > > A Universe is a set of packages. You want another set. If I change the > Squeak set, the Pharo set won't be updated. This has some advantages > (we control what appears in our universe), but has the big > disadvantage of duplicating my effort to update the Squeak Universe. I guess Squeak Universe manage versions ? Why not consider Pharo as a specific Squeak version ? -- Serge Stinckwich http://blog.doesnotunderstand.org/

June 1, 2008

Re: [Pharo-project] [ANN][Pharo-dev] First release

by Damien Pollet

On Sun, Jun 1, 2008 at 11:42 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > A Universe is a set of packages. You want another set. If I change the > Squeak set, the Pharo set won't be updated. This has some advantages > (we control what appears in our universe), but has the big > disadvantage of duplicating my effort to update the Squeak Universe. What about Keith's Sake packages? Since they are regular smalltalk method they can be managed using MC instead of an ad-hoc server, and maybe the common parts can be modularized using inheritance/delegation... -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

June 1, 2008

[Pharo-project] Resent messages?

by Bill Schwab

Hello all, Did some messages get posted more than once? It beats losing them, but leaves me wondering whether it is my goofy email server or something about the list conversion. FWIW. 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

June 1, 2008

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

by Bill Schwab

Stef, My email server crashed yesterday and was out of action for several hours. From emails I found this morning, it looks like Damien and I will cook up a plan on the Wiki. With luck, we will be able to get the RB to do the tedious work, and also leave a simple defined procedure for converting "old" code that we did not have loaded during the transformation. Transformed code should work as it always did; new code will be able to benefit from consistent semantics and exception handling. There will also be silently truncating methods for the situations (and they indeed exist) that call for them. More to come. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 05/31/08 4:22 PM >>> On May 30, 2008, at 10:46 PM, Bill Schwab wrote: > Stef, > > Whether or not I agree depends on what you mean. While I think I > see where Damien is going, my read is that #on: is actually > negotiable, given that we should be able to either fix (or simply > replace and than alias) ReadStream - two different ways of solving > the same problem. But if you concerned about breaking some things > that Damien and I are committed to fixing as part of the change, > then I submit that we will be helpless when we move from the > relatively calm world of streams to the chaos of morphic. You lost me. :) > Which part bothers you? None :) > The plan is to rennovate (sometimes messy) and *then* slowly evolve > the resulting stable system, right? The plan is to move but be careful. This is why I would like you guys to tell us what you want to do (or are doing) so that we can document the changes and everybody can participate and help also fixing if necessary. I just want more organized communication when we have a "big" change. No more. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 1, 2008

Re: [Pharo-project] new to pharo

by Alain Plantec

On Saturday 31 May 2008 14:24:05 you wrote: > Alain, > > You have COMPLETELY missed the focus of my response; thanks for > objecting so we can clarify it. My point was that it is a great start > on explaining something that is indeed mysterious to many (including > myself!), and deserves to be built up into a Wiki page for future > reference vs. "lost" in an archived list. Excuse me, it seems that I have to improve my english alain > > Please continue questioning the experts, and document what they tell > you. We will have it right when the answer is a link to a page complete > with a FAQ. > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

June 1, 2008

Re: [Pharo-project] [ANN][Pharo-dev] First release

by Damien Cassou

>>> I hope to have a server soon for the universe >> >> I think it will be difficult to maintain a universe server (each time >> you update a package on the squeak universe, you will have to do it >> again for pharo). A Universe is a set of packages. You want another set. If I change the Squeak set, the Pharo set won't be updated. This has some advantages (we control what appears in our universe), but has the big disadvantage of duplicating my effort to update the Squeak Universe. -- 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 1, 2008