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

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

by Alexandre Bergel

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: [...]... I like you idea, but to make it cover all different improper usage may be hard... Cheers, Alexandre On 15 Aug 2008, at 03:38, Bill Schwab wrote: > Stef, > > I agree you are improving on the existing code, but I would prefer > something like > > file := fd readOnlyFileNamed:name ifNone:[ ^self ]. > > This is analogous to #at:ifAbsent:, which does not set up an exception > handler and raise and handle an exception for something that is > known to > be handled locally. Then, just as #at: _does_ raise an exception, > there > should be > > readOnlyFileNamed:aBlock > ^self > readOnlyFileNamed:name > ifNone:[ FileDoesNotExist signalWith:name. ]. > > #signalWith: might not be the correct syntax (too tired to look<g>), > but > hopefully it makes the point that exceptions should be raised, but > there > should also be "long winded" methods that skip the overhead when it is > possible to do so. > > 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 08/11/08 4:15 PM >>> > ------------------------------------------------------ > update10052 > ISSUE #124 > While browsing at referencer of FileDoesNotExistException, I > discovered the following pattern > that is used in many different places. I find this pretty ugly: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > file := [fd readOnlyFileNamed: keysFileName] > on: FileDoesNotExistException do:[:ex| nil]. > file ifNil:[^self]. "no keys file" > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > The use of exception is completely outwitted. > > I would rather write: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [file := fd readOnlyFileNamed: keysFileName] > on: FileDoesNotExistException do: [:ex| ^ self]. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 15, 2008

Re: [Pharo-project] Re: License agreement

by Lukas Renggli

> I think that mentioning that if the code is published in the pharo > squeaksource repository and on any squeaksource > repository it is MIT. (I have problem to see people using free resources > for private project) > would be a good addition. That's why there is a per-project setting that displays a license text like "Code commited to this repository will be automatically under MIT license." You have to set it though, because there are projects that have other licenses. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 15, 2008

[Pharo-project] Re: License agreement

by StÃ©phane Ducasse

sure I think that mentioning that if the code is published in the pharo squeaksource repository and on any squeaksource repository it is MIT. (I have problem to see people using free resources for private project) would be a good addition. On Aug 15, 2008, at 4:17 AM, Bill Schwab wrote: > Stef, > > I need to sign and send you a copy of the agreement. The terms are > fine > - if I give something away, I intend to do just that, and MIT is fine > (anything not GPL is fine<g>). The only small concern I have is that > the agreement does not specify what distinguishes contributed code. I > gather from elsewhere that loading it into a repository is the > trigger. > Would there be any problem defining that in the agreement? I am > simply > looking ahead to conversations with lawyers; I need to at least talk > to > them about it - they get quite upset if left out of things. > > If you are agreeable to a change, it might be best to wait until we > see > what, if any, other concerns might arise before updating the web site. > > 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 > >

Aug. 15, 2008

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

by Bill Schwab

Stef, I agree you are improving on the existing code, but I would prefer something like file := fd readOnlyFileNamed:name ifNone:[ ^self ]. This is analogous to #at:ifAbsent:, which does not set up an exception handler and raise and handle an exception for something that is known to be handled locally. Then, just as #at: _does_ raise an exception, there should be readOnlyFileNamed:aBlock ^self readOnlyFileNamed:name ifNone:[ FileDoesNotExist signalWith:name. ]. #signalWith: might not be the correct syntax (too tired to look<g>), but hopefully it makes the point that exceptions should be raised, but there should also be "long winded" methods that skip the overhead when it is possible to do so. 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 08/11/08 4:15 PM >>> ------------------------------------------------------ update10052 ISSUE #124 While browsing at referencer of FileDoesNotExistException, I discovered the following pattern that is used in many different places. I find this pretty ugly: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= file := [fd readOnlyFileNamed: keysFileName] on: FileDoesNotExistException do:[:ex| nil]. file ifNil:[^self]. "no keys file" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The use of exception is completely outwitted. I would rather write: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [file := fd readOnlyFileNamed: keysFileName] on: FileDoesNotExistException do: [:ex| ^ self]. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Aug. 15, 2008

Re: [Pharo-project] Worth considering?

by Hilaire Fernandes

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 2008/8/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hilaire > > can you open a ticket and publish the code in the inbox? > http://code.google.com/p/pharo/wiki/HowToContribute > > Stef > > On Aug 13, 2008, at 10:50 PM, Hilaire Fernandes wrote: > >> To load Magma Beta version throught Monticello Configuration by Chris, >> I need the two included fixes in Pharo. >> Does it worth integrating these fixes in Pharo? >> >> Hilaire >> >> -- http://blog.ofset.org/hilaire >> >> <MonticelloConfigurations-cmm.44.mcz><Monticello-SR.315.mcz>_______________________________________________ >> 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 > -- http://blog.ofset.org/hilaire

Aug. 14, 2008

[Pharo-project] From OBrowser cannot save pane code when in prettyprint mode

by Hilaire Fernandes

Does one else has noted this bug? Hilaire -- http://blog.ofset.org/hilaire

Aug. 14, 2008

Re: [Pharo-project] Worth considering?

by StÃ©phane Ducasse

Hilaire can you open a ticket and publish the code in the inbox? http://code.google.com/p/pharo/wiki/HowToContribute Stef On Aug 13, 2008, at 10:50 PM, Hilaire Fernandes wrote: > To load Magma Beta version throught Monticello Configuration by Chris, > I need the two included fixes in Pharo. > Does it worth integrating these fixes in Pharo? > > Hilaire > > -- > http://blog.ofset.org/hilaire > <MonticelloConfigurations-cmm.44.mcz><Monticello-SR. > 315.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2008

[Pharo-project] automatic in stall

by Hilaire Fernandes

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

Aug. 13, 2008

[Pharo-project] Worth considering?

by Hilaire Fernandes

To load Magma Beta version throught Monticello Configuration by Chris, I need the two included fixes in Pharo. Does it worth integrating these fixes in Pharo? Hilaire -- http://blog.ofset.org/hilaire

Aug. 13, 2008

[Pharo-project] Fwd: Issue 219 Object>>isTransparent

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: August 12, 2008 10:00:04 PM CEDT > To: stephane.ducasse(a)free.fr > Subject: Issue 219 Object>>isTransparent > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: August 12, 2008 10:00:02 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: Issue 219 Object>>isTransparent > > > It would be nice that Object does not implement isTransparent. > Apparently when you put Beeper beep in Object>>isTransparent this > method in invoked. It would be good to check whether another > (graphical) object should not implement isTransparent > > From stef and marcus. > > > > >

Aug. 13, 2008