- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] New release is out 10050
by StÃ©phane Ducasse July 19, 2008

July 19, 2008

Hello Pharoers [ANN] New release is out 10050 update10047 Fixing the release. Adrian made a few cosmetic changes and tagged testUnimplementedNonPrimitiveCalls as expected failure Original description: - added allClassesWithUnimplementedCalls to SystemNavigation to return structured classes with unimplemented calls - added convenience method PackageOrganizer>>allPackagesContainingUnimplementedCalls - adjusted ReleaseTest>>testUnimplemented... to exclude TestCase classes ------------------------------------------------------ update10048 Fix the Scriptloader logStream + Collection tests http://bugs.squeak.org/view.php?id=6355 + Pharo Flaps ------------------------------------------------------ update10049 7073 CollectionAndCollectionTest * [http://bugs.squeak.org/view.php?id=6367 M6367] * seems good [http://bugs.squeak.org/view.php?id=5700 M5700] Add 2 tests for RunArray class + at:put: See : http://bugs.squeak.org/view.php?id=6070 ------------------------------------------------------ update10050 This update includes a set of Mantis fixes (that also went into Squeak 3.10): http://code.google.com/p/pharo/issues/detail?id=27 http://code.google.com/p/pharo/issues/detail?id=31 http://code.google.com/p/pharo/issues/detail?id=32 http://code.google.com/p/pharo/issues/detail?id=30 mark testUnwindDebuggerWithStep as expected failure

1 0

[Pharo-project] Enough changes to release?
by Damien Cassou July 19, 2008

July 19, 2008

Hi, I don't know when you decide to release Pharo versions, but it might be interesting to do that now. The previous version is 2 week old and the changes take a long time to load. Bye -- 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)

2 1

[Pharo-project] About HTMLFileStream
by StÃ©phane Ducasse July 19, 2008

July 19, 2008

Hello I was browsing and browsing code and I found HTMLFileStream Apparently positionableStream introduces command: just for this class. I have the impression that if we want a good htmlwriter we could extract it from seaside. But HTMLFileStream looks outdated. So I would propose to remove it. Any thoughts on that one? Stef

2 2

Re: [Pharo-project] about ensuring file closing
by Bill Schwab July 19, 2008

July 19, 2008

Stef, I do not doubt that the image is littered with such problems. On several occasions, I lost 10-15 minutes tracking down errors that resulted from unopened files. It is all a continuation of my streams "rant" (a well-intentioned one, of course). Meaning no disrespect to the milestones (in particular, streams being slated for the future), I have undertaken an effort similar to what you propose: putting an end to silent failures and lack of protection. As a streams addict, I need stable semantics, and have thus embarked on my #nextOne, #nextMany:, etc. solution to reaching that goal. It also became clear that FileStream was quite unfriendly, so I started adding Dolphin-compatible methods, at least to a point. My primary goal is to have errors arise when appropriate vs. waiting for potentially/apparently disconnected collateral damage to occur. Dolphin's semantics will not be completely appropriate for Squeak, because there are OS (in)dependencies to consider. I want that to work well so I can treat my Redmond allergy. I urge Smalltalkers to avoid #next and #next: like the plague, but one could always use my changes and ignore the replacements. A very incomplete but gradually evolving change set is available on request. 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 07/18/08 3:40 AM >>> I was looking at the ensure: usage in the image. And I found this one (besides the third line :) and I was wondering if it would not make sense to check them all (ensure:, forceNewFileNamed:.....) because if forceNewFileNamed: returns nil the ensure will not work. writeEncoded: bytes | file | fileName ifNil:[^self]. false ifTrue:[^self]. file := FileStream forceNewFileNamed: fileName. [file nextPutAll: bytes] ensure:[file close]. I was also looking at readOnlyFileNamed: and it does not return nil readOnlyFileNamed: fileName "Open an existing file with the given name for reading." | fullName f | fullName := self fullName: fileName. f := self new open: fullName forWrite: false. ^ f isNil ifFalse: [f] ifTrue: ["File does not exist..." ((FileDoesNotExistException fileName: fullName) readOnly: true) signal]. "StandardFileStream readOnlyFileNamed: 'kjsd.txt' " I found some inconsistencies: For example BMPReadWriter>>nextPutImage: aForm as a stream close as the last messages while all the other methods do not and should be protected by an ensure: may be we could have a task for going over the implementation of fileStream and also the ensure: uses. Stef

2 1

[Pharo-project] A board for pharo
by StÃ©phane Ducasse July 19, 2008

July 19, 2008

Hello everybody We are happy to announce a board for Pharo! So far, Pharo has mainly been "directed" by Stef who initiated the project. Now that the community grows and Pharo makes progress, the board will bring some more structure into the decision making process. We don't have bylaws or any rules written down yet but the idea is to run it similar to the Apache board. That is, new board members are elected by existing board members. The rational is that we want to assure continuity to be able to steadily push Pharo forward. The current board members are: - Marcus Denker - Stefane Ducasse - Adrian Lienhard - Michael Rueger Stef

7 12

[Pharo-project] Deprecation class comment is wrong
by StÃ©phane Ducasse July 18, 2008

July 18, 2008

This Warning is signalled by methods which are deprecated. The use of Object>>#deprecatedExplanation: aString and Object>>#deprecated: aBlock explanation: aString is recommended. Idiom: Imagine I want to deprecate the message #foo. foo ^ 'foo' I can replace it with: foo self deprecatedExplanation: 'The method #foo was not good. Use Bar>>newFoo instead.' ^ 'foo' .... but deprecatedExplanation: aString "This method is OBSOLETE. Use #deprecated: instead." self deprecated: 'Use Object>>deprecated: instead of deprecatedExplanation:.'. Preferences showDeprecationWarnings ifTrue: [Deprecation signal: ('{1} has been deprecated. {2}' translated format: {thisContext sender printString. aString})] and deprecated: aBlock explanation: aString "This method is OBSOLETE. Use #deprecated:block: instead." self deprecated: 'Use Object>>deprecated:block: instead of deprecated:explanation:.'. Preferences showDeprecationWarnings ifTrue: [Deprecation signal: ('{1} has been deprecated. {2}' translated format: {thisContext sender printString. aString})]. ^ aBlock value.

1 0

[Pharo-project] about _ and :=
by StÃ©phane Ducasse July 18, 2008

July 18, 2008

Alex if you want to run the FixUnderscore and check if we can reload the package then we would integrate them. Stef

1 0

[Pharo-project] Classes in more than one package
by Alexandre Bergel July 18, 2008

July 18, 2008

I also noticed that there are classe that are contained in more than one package. For example, InstallerTest is contained in the package Installer and Installer-Test. Same thing for the class Installer. It is contained in the package Installer and Installer-core. I guess that packages Installer-Test and Installer-Core must be removed, since there are categories in the package Installer. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

6 12

Re: [Pharo-project] A board for pharo
by Bill Schwab July 18, 2008

July 18, 2008

Adrian, I reserve the right to turn on you without notice<g>, but I see this as positive. I am also glad you pointed out the problems with mob rule in the Squeak Community - that way, I didn't have to do it first. I was considering Stef to chair a default "board" from the beginning, so making it explicit is fine by me. By all means, ditch Etoys, but we should also not obstruct efforts to make it re-loadable, provided that can be done w/o excessive cruft in the image. Deciding what is an acceptable tradeoff between a clean system and an inclusive one requires some authority that must be excercised wisely. Stick to a clean Smalltalk that can be a base for anything from stable products to bleeding edge experiments, and things should go well. Bill ========================== adi(a)netstyle.ch wrote: Hi Norbert, I can understand your concerns. It may look a bit like the announced board members take over without being based on the community. Of course there is no such intent and I think the processes should be transparent and the interests of the community should always be taken into account. Yet, we intentionally chose not to do a democratic setup because of the negative experience we made with Squeak and its SqueakFoundation. The democratic setup and a board that didn't actively steer the direction of development and make decisions paralyzed the community because of the too diverging interests. This situation eventually lead to the decision to start Pharo. Therefore, we really want to make sure that we do not do the same mistakes again. And this is exactly also why I think its important to instantiate a board as early as possible. If we wait until a lot of people have joined (and I can imagine that this will happen as there does not seem to be much progress in Squeak right now), the risk is that we again loose our focus. Just to give an example: even if people come to Pharo and use it for EToys, I still want to be able to remove it. You ask why Marcus and Mike? On the one hand, both bring a lot of experience from managing previous Squeak releases (3.8 and 3.9) and both have a deep know-how from being actively involved in Squeak for many years. On the other hand, with Mike we have another guy from industry, so we have a balance between academia and industry (although I'm also involved in research with my PhD, I consider myself as an industry guy because netstyle.ch/cmsbox is the main reason I'm pushing Pharo). Cheers, Adrian 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

2 1

July 18, 2008

Hi I would like to get your thoughts on the following: Following the blog of ramon and his code in sandstoneDB which extends dataStream as follows: Here is a typical example: fileNamed: aName do: aBlock | file | file := self fileNamed: aName. ^ file ifNil: [ nil ] ifNotNil: [ [ aBlock value: file ] ensure: [ file close ] ] fileNamed: aString "Here is the way to use DataStream and ReferenceStream: rr := ReferenceStream fileNamed: 'test.obj'. rr nextPut: <your object>. rr close. better use: fileNamed:do: " | strm | strm := self on: (FileStream fileNamed: aString). "will be binary" strm byteStream setFileTypeToObject. "Type and Creator not to be text, so can attach correctly to an email msg" ^ strm There is similar pattern in FileStream detectFile: aBlock do: anotherBlock | file | file := aBlock value. ^ file ifNil: [ nil ] ifNotNil: [ [anotherBlock value: file] ensure: [file close]] fileNamed: fileName ^ self concreteStream fileNamed: (self fullName: fileName) fileNamed: fileName do: aBlock "Avi Bryant says, ''This idiom is quite common in other languages that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and Ruby (File.open('foo'){| f|...})). It's time Squeak had it, too.'' Returns the result of aBlock." ^ self detectFile: [ self fileNamed: fileName ] do: aBlock I have a question: - would not be better to even wrap the on: into the first block of the ensure: message? - do we have to close a file even if its creation failed? Stef

4 5