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

Re: {Spam?} [Pharo-project] [Update] 10055 + new release

by Michael Rueger

On Fri, Aug 15, 2008 at 8:51 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > I think the answer is probably to pass the *class* of the exception. > The default then simply sends the correct #signalWith: message with the > file name as an argument. Hmm, but the instance might hold additional information. Michael

Aug. 15, 2008

[Pharo-project] Controller no view member anymore

by Hilaire Fernandes

Hello, I saw that in recent change, I guess MVC clean up, the Controller class has lost it view instance variable. Are there any reason doing that change? For reference, http://en.wikipedia.org/wiki/Model-view-controller Hilaire -- http://blog.ofset.org/hilaire

Aug. 15, 2008

Re: {Spam?} [Pharo-project] [Update] 10055 + new release

by Bill Schwab

I think the answer is probably to pass the *class* of the exception. The default then simply sends the correct #signalWith: message with the file name as an argument. 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 >>> m.rueger(a)acm.org 08/15/08 11:39 AM >>> Alexandre Bergel wrote: > At the first glance readOnlyFileNamed:ifNone: seems to be a useful > primitive. But this having the file absent might be just one case. You > could have ifNotReadable:, ifParentFolderNotReadable:. > Also, an error when writing in a file may occur in many different > situation (disk full, file read only, ...). > You may also want to provide handler for each of these situation (e.g., > writeFileNamed: aName with: stream ifDiskFull: [...] > ifAlreadyExistingFile: [...]... Agree... >> I agree you are improving on the existing code, but I would prefer >> something like >> >> file := fd readOnlyFileNamed:name ifNone:[ ^self ]. a solution would be to pass in any Exception into the ifNone: block: file := fd readOnlyFileNamed:name ifNone:[:ex| ^self ]. Then depending on whether you are actually interested in the exact reason the file couldn't be created you could look at the exception. Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 15, 2008

Re: [Pharo-project] Worth considering?

by Keith Hodges

Hilaire Fernandes wrote: > Ah, it is really weird, I just retry from a fresh Pharo image, > installing MC1.5 from universe, then Magma through MC Configurations, > and it worked! > Last time I try in June it do not worked, may my image was crawling > under various MC versions... > > Sorry guy! > and thanks, I reactivated MC1.5 in my setup script > http://community.ofset.org/index.php/IStoa.net#Installation_scripts > > Hilaire > > I didnt expect it to work that easily ;-) Since I have probably not been keeping Universes up to date. The best fully supported means of loading MC1.5 is LPF http://installer.pbwiki.com/LevelPlayingField I havent tried it with Pharo, but I think Matthew has. Keith

Aug. 15, 2008

Re: [Pharo-project] Worth considering?

by Hilaire Fernandes

Ah, it is really weird, I just retry from a fresh Pharo image, installing MC1.5 from universe, then Magma through MC Configurations, and it worked! Last time I try in June it do not worked, may my image was crawling under various MC versions... Sorry guy! and thanks, I reactivated MC1.5 in my setup script http://community.ofset.org/index.php/IStoa.net#Installation_scripts Hilaire 2008/8/15 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > Hilaire Fernandes wrote: >> >> 2008/8/15 Keith Hodges <keith_hodges(a)yahoo.co.uk>: >> >> >>> >>> For goodness sake why dont you use MC1.5 ? >>> >> >> Because Monticello configurations does not work with it. >> >> Hilaire >> >> __ > > Oh for goodness sake, thats the whole point of MC1.5 that all these things > WORK, I merged the fixes from 3 forks of MC and we have put several months > of development into it. MC1 (in its possibly dying day) has never been so > good. MC1.6 with atomic loading is on its way. > > To reiterate Monticello Configurations has been working with MC1.5 since > September last year! > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

Aug. 15, 2008

Re: [Pharo-project] Worth considering?

by Keith Hodges

Hilaire Fernandes wrote: > 2008/8/15 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > > >> For goodness sake why dont you use MC1.5 ? >> > > Because Monticello configurations does not work with it. > > Hilaire > > __ Oh for goodness sake, thats the whole point of MC1.5 that all these things WORK, I merged the fixes from 3 forks of MC and we have put several months of development into it. MC1 (in its possibly dying day) has never been so good. MC1.6 with atomic loading is on its way. To reiterate Monticello Configurations has been working with MC1.5 since September last year! Keith

Aug. 15, 2008

[Pharo-project] New update :)

by StÃ©phane Ducasse

hi guys There is a new update.... removing a lot of duplicated code and some fixes. We also set the preference not to server mode. Have fun. Stef PS: we added some new issues. So feel free to help.

Aug. 15, 2008

Re: [Pharo-project] Worth considering?

by Hilaire Fernandes

2008/8/15 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > For goodness sake why dont you use MC1.5 ? Because Monticello configurations does not work with it. Hilaire

Aug. 15, 2008

Re: [Pharo-project] Worth considering?

by Keith Hodges

Hilaire Fernandes wrote: > I guess you understood these two packages are not mine. It was > suggested by Chris Muller to get Monticello Configuration working > properly. > > Is it still ok I push these ones in the Inbox? > > Hilaire > > For goodness sake why dont you use MC1.5 ? Keith

Aug. 15, 2008

Re: {Spam?} [Pharo-project] [Update] 10055 + new release

by Michael Rueger

Alexandre Bergel wrote: > At the first glance readOnlyFileNamed:ifNone: seems to be a useful > primitive. But this having the file absent might be just one case. You > could have ifNotReadable:, ifParentFolderNotReadable:. > Also, an error when writing in a file may occur in many different > situation (disk full, file read only, ...). > You may also want to provide handler for each of these situation (e.g., > writeFileNamed: aName with: stream ifDiskFull: [...] > ifAlreadyExistingFile: [...]... Agree... >> I agree you are improving on the existing code, but I would prefer >> something like >> >> file := fd readOnlyFileNamed:name ifNone:[ ^self ]. a solution would be to pass in any Exception into the ifNone: block: file := fd readOnlyFileNamed:name ifNone:[:ex| ^self ]. Then depending on whether you are actually interested in the exact reason the file couldn't be created you could look at the exception. Michael

Aug. 15, 2008