- Pharo-dev - lists.pharo.org

[Pharo-project] A note
by StÃ©phane Ducasse Aug. 20, 2008

Aug. 20, 2008

Hi guys it occurred to me that this may be important to stress the following point. The point of pharo is not to go to a minimal kernel for the sake of it but to get nice abstractions into play. (of course we will remove etoy, remove the extra fat of morphic and reorganize package structures and more....). But let me take an example: with marcus we worked yesterday on making sure that the newcompiler can be compiled and installed as a second compiler so that compiler freaks can use this second compiler as a fallback when they hack the compiler. The point is that we can in the future remove the old compiler and replace it with the new one. What this example illustrates is that we are looking for the smallest compiler but one that is good and have a good interface (use of exception, instead of [^ nil]). Now ideally we would like to have a smallkernel PLUS a set of packages that composes a pharo-core distribution. What we do not want is to fall into the trap of - smaller better - and have packages that are not touched by refactoring. So we would like to have a smallkernel but not smaller plus the ability to load automatically packages so that when we refactor the system we can work on a coherent set of packages. If you have feedback please let us know. Stef

1 0

[Pharo-project] test report for pharo0.1-10050web08.08.1 image
by laurent laffont Aug. 19, 2008

Aug. 19, 2008

Hello, I've generated a test report for pharo0.1-10050web08.08.1 image: http://www.adhocmusic.net/squeak/pharo0.1-10050web08.08.1.tests.html passed: 14475 failures: 44 errors: 83 I had to remove this test as it never ends: MCPackageTest>>#testUnload {tests} There's also a halt in RxPaserTest>>#testMatchesInwW Is this report useful for you ? Which additional informations would you like to see in it ? Regards, -- Laurent Laffont

5 24

[Pharo-project] website
by StÃ©phane Ducasse Aug. 19, 2008

Aug. 19, 2008

I would like to start having a real web site. Samuel? I would have love to have a first shoot before esug. Marcus could you at least put a forward from pharo-project.org -> google? May be we should sit together with the other pharoers at ESUG? Stef

2 4

[Pharo-project] About a better look
by StÃ©phane Ducasse Aug. 19, 2008

Aug. 19, 2008

Adrian Marcus told me that you did a grey look. Do you have that around? Stef

2 3

[Pharo-project] About milestone
by StÃ©phane Ducasse Aug. 19, 2008

Aug. 19, 2008

Hi all I would really like to have soon a first official release. So what do we want to get in/out and before the release: - better look for sure - tests green. I think that this is important to release 0.1 Since I would really like to use the NewCompiler by default and remove the old one. Stef

2 2

[Pharo-project] A thought about Morphic and Seaside
by StÃ©phane Ducasse Aug. 18, 2008

Aug. 18, 2008

Hello guys We were browsing code with marcus and I realized something quite funny about Morphic. Morphic is somehow close to seaside for the following point: There is a list that contains the children. In Seaside you have to return a list containing the children components too. Now this is really interesting to see that a lot of complexity in Morphic code comes from the fact that the programmers avoided to have an instance variable for an element to the pretext that the element was already in the submorphs list. Then you end up with code like label: aString | oldLabel m | (oldLabel := self findA: StringMorph) ifNotNil: [oldLabel delete]. m := StringMorph contents: aString font: TextStyle defaultFont. self extent: m extent + (borderWidth + 6). m position: self center - (m extent // 2). self addMorph: m. m lock label | s | s := ''. self allMorphsDo: [:m | (m isKindOf: StringMorph) ifTrue: [s := m contents]]. ^ s instead of label ^ label label: aString .... where you have to query the submorph of the right kind.... Marcus was mentioning to me that Morphic is a bit like applying GraphTraversal that the law of demeter guy loves so much. And we see the results, an ugly code all over the places. So I will certainly play a bit with this design difference to see what it makes. But I'm sure now it makes a big difference. stef

4 9

[Pharo-project] Fwd: BasicButton for fun
by StÃ©phane Ducasse Aug. 18, 2008

Aug. 18, 2008

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)univ-savoie.fr> > Date: August 17, 2008 10:43:51 PM CEDT > To: An open mailing list to discuss any topics related to an open- > source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> > Subject: BasicButton for fun > > In fact this is fun to see that even font default are inconsistent... > > TextStyle defaultFont is different from Preferences standardButtonFont > > But it may be worth checking the senders of allMorphDo: or submorph... > > > > > > stef

1 0

[Pharo-project] automatic in stall
by Hilaire Fernandes Aug. 17, 2008

Aug. 17, 2008

On a bare bone image (Without the class Installer), is it possible to install automatically Monticello package. On a -dev image I use to do: (Installer monticello http: 'http://www.squeaksource.com/repos' user: 'hlsf' password: 'xxx') install: 'paquage'. Hilaire -- http://blog.ofset.org/hilaire

3 2

Re: {Spam?} [Pharo-project] [Update] 10055 + new release
by Bill Schwab Aug. 15, 2008

Aug. 15, 2008

Ok, the profiler to the rescue. Instantiating some exception sub-classes should tell us whether there is anything to be gained from a factory of some sort. A quick look does not show much going on on instantiation, so it is probably fine to create the appropriate sub-instance and set any useful aspects, and to pass that to the ouch-block. 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 8/15/2008 3:48 PM >>> 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: {Spam?} [Pharo-project] [Update] 10055 + new release
by Bill Schwab Aug. 15, 2008

Aug. 15, 2008

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

2 1