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

Re: [Pharo-project] about ensuring file closing

by Bill Schwab

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

July 18, 2008

[Pharo-project] About HTMLFileStream

by StÃ©phane Ducasse

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

July 18, 2008

[Pharo-project] about _ and :=

by StÃ©phane Ducasse

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

July 18, 2008

Re: [Pharo-project] A board for pharo

by Damien Cassou

On Fri, Jul 18, 2008 at 10:26 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > TODO: Pharo duplicated code in importAllIconNamed: and friends Issue #120 > TODO: may be include as ressources the pngSuite - see testPngSuite I don't understand this one > TODO: remove from UndefinedObject from3DS: aDictionary ^aDictionary Patch sent to PharoInbox. Issue #121. Needs a review. > TODO: 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: Issue #122 -- 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)

July 18, 2008

Re: [Pharo-project] Classes in more than one package

by StÃ©phane Ducasse

The problem matthew is how do you keep in sync a package and its packagetests Imagine that in two year from now you want to load a version and get the test of this version green. So I usually have the following pattern (with I borke like an idiot). - Installer-all Installer-core Installer-Tests Then I version all the time only Installer-All Stef On Jul 18, 2008, at 1:37 AM, Matthew Fulmer wrote: > On Thu, Jul 17, 2008 at 06:36:11PM +0200, Alexandre Bergel wrote: >> I discovered the problem. It has nothing to do with Omnibrowser. >> If you load Installer from squeaksource (http://www.squeaksource.com/Installer' >> ), you will notice that the package Installer depends on Installer- >> Core and Installer-Test, two other packages that are loaded when you >> load Installer. >> >> But Installer-Core and -Test are 'sub-package' of Installer, and >> since >> Installer is not empty, MC get confused. > > The Installer package is obsolete. It has been divided up. Use > Installer-Core instead > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 18, 2008

Re: [Pharo-project] A board for pharo

by StÃ©phane Ducasse

yeap! On Jul 18, 2008, at 1:02 AM, Bill Schwab wrote: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 18, 2008

Re: [Pharo-project] A board for pharo

by StÃ©phane Ducasse

Great! I spent yesterday browsing squeak and found a lot of glitches. It really deserves our care and love and we will have a cool system I have rather limited network again :( Here are some notes I took TODO: Pharo duplicated code in importAllIconNamed: and friends TODO: may be include as ressources the pngSuite - see testPngSuite TODO: remove from UndefinedObject from3DS: aDictionary ^aDictionary TODO: 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: So if someone can turn them into task it would be great. stef On Jul 17, 2008, at 5:13 PM, Norbert Hartl wrote: > Hi Stef, > > this little transparency made everything clear for me. Thank you > very much sharing your opinion and your emails. This mail goes > into the archive and answers a lot of questions. Fini! > > I didn't want to opt against some of the board members. Marcus > and Mike I met in person already. And I appreciated already the > work together with Adrien. So, this _is_ indeed a fine board > (for me) ;) > > Norbert > > > On Thu, 2008-07-17 at 16:22 +0200, StÃ©phane Ducasse wrote: >> Hi norbert >> >> >> I think that the board should not be really active right now. >> But may be there will be time where we will need to take decisions. >> My take on that is that I would like to have a really transparent >> process >> similar to what we are doing now: >> - emails in the mailing-list, >> - nice exchange (as for the stream discussions), >> - seriously I do not have any preconceived ideas (even on >> namespace - >> ok on >> namespace I have some ideas :)), >> >> We want to be influenced by contributing people. >> >> Tthe point is that **we** the list active members can take decision >> and >> that in case of deadlock the board can give us some way to take >> decision. >> >> For the fact that this is early or not, I do not know, I'm more >> lenient :) >> so I thought let it go for after, other boarders saw it in another >> way >> and this >> was ok for me too. >> >> At the end, I'm **happy** (in the naive sense) because I do not want >> pharo to >> be my project. I want pharo to be **our** project. But we need to be >> able to >> take decisions and build a vision. So this is why I accepted the >> idea >> of the board. >> >> May be we should discussed it publicly but this was really simple. >> Here is the two emails. >> >> First email: >> >> "Now, I think we should also start thinking about how to manage Pharo >> to not drift >> into the same problems like with Squeak. I here primarily think about >> decision making. >> Who holds the keys and has the power to take final decisions? Do we >> have a board and >> if yes how does it constitute itself or is there just Stef as a >> dictator ;) >> (which may be just fine too)?" >> >> I said that I wanted to have a board (for the reasons I explained >> above). >> >> Second email: >> >> Hi Mike, >> >> Stef, Marcus and I have been discussing about instantiating a board >> for Pharo and thought about asking you to join. >> The idea is that the board is not elected but works by "co-optation", >> meaning the board decides who can join or not. >> >> It probably goes without saying that a board that can efficiently >> take >> decisions is critical if we do not want to get into >> a situation again where different interests block everything ;). >> >> I think at moment Stef is the "owner" of Pharo and he creates this >> board now -- so this should not be understood >> as an unfriendly act by the current participants. >> >> What do you think? >> Adrian >> >> >> >> Now about the board members: >> - Marcus knows much more than me about Smalltalk :) >> - Mike is from industry and we share a common vision (iSqueak, >> YSqueak...) >> - Adrian is running business and academic, so Smalltalk is central >> for him >> >> Now 4 is not a good number for taking decision so we will see, when >> we >> will >> need to fix that. >> >> I sincerly hope that you understand us. For me, it does not change >> anything >> to the vision, motivation..... This is just to protect ourselves >> because >> we got burnt. Now we do not have have an internal mailing-list. >> >> Stef >> >>> Hi, >>> >>> that is very very early for the installation of a "board". What >>> are the topics only a board can do? I think at this stage of project >>> existence it should be a goal to involve everyone participating as >>> much as possible. And I doubt the installation of a board supports >>> this. I think you first need a community that you want to "steer". >>> >>> I have the impression we really should care about transparency. >>> Announcing a board and a board "model" without any prior >>> announcement or >>> discussion is not very sensible to other people involved. >>> I can live with this board but e.g. I want to know what/where put >>> Marcus and Michael in charge? Both are rather absent from this list >>> and Marcus is "recovering slowly". If there were any decisions that >>> must have been made while meeting in personal or by private email. >>> That's what I mean. Please correct me if I missed something >>> important. >>> >>> Maybe it is just whining from my site and not worth it. But I'm >>> really >>> sensible to such things and I (too) must organize very well where to >>> spend my spare time. >>> >>> Norbert >>> >>> On Thu, 2008-07-17 at 09:30 +0200, StÃ©phane Ducasse wrote: >>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 >

July 18, 2008

[Pharo-project] Please verify #118

by Damien Cassou

Can someone please verify: http://code.google.com/p/pharo/issues/detail?id=118 -- 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)

July 18, 2008

[Pharo-project] Enough changes to release?

by Damien Cassou

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)

July 18, 2008

Re: [Pharo-project] about ensuring file closing

by StÃ©phane Ducasse

July 18, 2008