October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Schwab,Wilhelm K

Why should it be free? It might be nice to have an electronic copy, or just permission to scan and release, in escrow. That could be done quietly between Didier and ESUG, and triggered if the book is no longer in print. If it is in print and the code is worth having we should be buying copies. To do otherwise undercuts investment by both the author and the publisher. I bought Numerical Recipes with a much smaller carrot than MIT source. The only reason I did not buy the book long ago is that the mix of topics was not a direct match for me, and because I generally look for C code that I can compile into libraries with clean interfaces. I do more FFT, DWT than anything else; if they are in the book, I missed it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Geert Claes [geert.wl.claes(a)gmail.com] Sent: Friday, October 15, 2010 2:42 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license Maybe a silly question, but it is the "code" of the book "Object Oriented Implementation of Numerical Methods", so the book itself won't be available for free? StÃ©phane Ducasse wrote: > > I want to thanks didier for releasing the code of his book under MIT. > Thanks! > > > Didier Besset wrote: >> >> Begin forwarded message: >>> From: Didier Besset <didier(a)ieee.org> >>> Date: October 14, 2010 8:06:52 PM GMT+02:00 >>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Subject: Disclaimer >>> >>> I hereby release the code of my book "Object Oriented Implementation of >>> Numerical Methods" under the > > MIT license. >>> >>> Didier Besset >> > -- View this message in context: http://forum.world.st/Object-Oriented-Implementation-of-Numerical-Methods-u… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Levente Uzonyi

On Thu, 14 Oct 2010, Eliot Miranda wrote: > 2010/10/14 jaayer <jaayer(a)zoho.com> > >> There was a post on this list back in August complaining about Stack >> inheriting from LinkedList. There was some discussion, but apparently no >> resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core >> Image I just downloaded. Rather than reimplementing it to forward to a >> contained LinkedList, I think it should use an Array internally like >> OrderedCollection does. An Array-based implementation of Stack would be >> faster than one based on LinkedList due to the basic stack operations (push, >> pop and top) being able to rely more on primitives. This assumes that you >> know roughly how a big a stack you need; if you don't, reallocating the >> array and copying its contents over and over again will cost you, but this >> is an exceptional case;-- most stacks are small and when they aren't, the >> programmer usually has enough information to select a reasonable stack size. >> > > *No*. Stack and OrderedCollection differ *usefully*. Adding an item to a > Stack is always O(1). Adding an item to an OrderedCollection is O(N) > because when the array overflows a new one must be allocated and the old > objects copied to the new. Why not apply your speedups to > OrderedCollection, or is that not possible? If not possible, then come up > with a new name and add that. Please /don't/ change Stack. I've never seen any code using Stack. People are more familiar with OrderedCollection. The O(1) worst case time for push is true in theory, but if we take into account GCs and cache locality, then things are a lot worse. GC pauses caused by the allocation of link objects are longer and happen more often than the pause caused by array growing (though it may also cause GC pauses). An array based implementation has much better cache locality: related object pointers (push/pop) are next to each other and 4x more pointers fit in same amount of cache. There are no speedups that could be applied to OrderedCollection in the code. The code implements a stack which is like an OrderedColelction with a few extra constraints: - firstIndex is always 1 - you can only add to the end - you can only remove from the end The implementation relies on these constraints. That's what makes it faster than an OrderedCollection. Levente > > >> >> Enclosed is a fileout of an Array-based Stack implementation. It trounces >> the LinkedList-based implementation easily, but more interestingly, it >> performs better than an OrderedCollection when used like a stack: >> >> Pushing is roughly ~30% faster: >> r1 :=[100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]]] timeToRun. >> r2 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]]] timeToRun. >> 100 - ((r1 / r2) asFloat * 100). >> >> as is pushing + popping: >> r3 := [100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]. >> 10 timesRepeat: [s pop]]] timeToRun. >> r4 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]. >> 10 timesRepeat: [oc removeLast]]] timeToRun. >> 100 - ((r3 / r4) asFloat * 100). >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by jaayer

---- On Fri, 15 Oct 2010 07:41:24 -0700 Guillermo Polito wrote ---- >BTW, why Stack inherits from LinkedList instead of just using it?Â Should an Stack have the entire Collection protocol? I don't think so... That was the subject of the earlier discussion, and yes, I think it should implement all appropriate messages in Collection, including #add: (as #push:), #size and #do:. The Array-based Stack I wrote does not implement #remove:ifAbsent: and only supports removal at the top of the Stack through #pop.

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by jaayer

On closer inspection, it appears the main reason why Stack is faster than OrderedCollection is that OrderedCollection will reallocate its Array even when #new: is supplied with what should be the correct size. To prevent reallocation, one must actually give it 1.5 times the size needed. This is because OrderedCollection keeps the first one-third of its Array empty so that #addFirst: operations will not require O(n) copying. This means that creating an OrderedCollection with new: 10 will require reallocation when the eighth element is added. If you create an OrderedCollection 50% bigger than what you expect to need, the performance gap closes to about ~7%, which isn't very significant: Smalltalk garbageCollect. r1 :=[100000 timesRepeat: [ s := Stack new: 100. 100 timesRepeat: [s push: #foo]]] timeToRun. Smalltalk garbageCollect. r2 := [100000 timesRepeat: [ oc := OrderedCollection new: 150. 100 timesRepeat: [oc addLast: #foo]]] timeToRun.

Oct. 15, 2010

Re: [Pharo-project] FileChooser (Squeak) = ........ (Pharo)

by Hannes Hirzel

Yes, good idea. Something like this which is in Squeak and Pharo. The snippet as such however does not work... It chooses directories and does not give the full path. --Hannes On 10/15/10, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 15, 2010, at 3:29 01PM, Hannes Hirzel wrote: > >> It seems to be >> FileDialogWindow >> >> So the question is how is the following snippet translated. The >> examples I found in the image did not work for some reason. >> >> "Squeak" >> fc := FileChooser new. >> fc initializeAsDialogBox. >> fc open. >> fc fullName >> >> On 10/15/10, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> Hello >>> >>> I am porting an application from Squeak to Pharo (actually the >>> moose-seaside-glamour image) and I wonder what the equivalent class of >>> FileChooser is? >>> >>> There are five 'Chooser' classes in Pharo 1.1 but no FileChooser. >>> >>> Thank you for the answer in advance >>> >>> Hannes > > > UIManager default chooseFileMatching: '*' ? > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 15, 2010

[Pharo-project] Call for contribution to http://pharo-project.org/about/research

by Alexandre Bergel

Hi! I set up http://pharo-project.org/about/research Now, it needs content. I need bibitem. Please, send me only the item that you think are relevant to the page. It makes no sense to have hundreds of item directly listed here. Feel free to comment on it. I am open to suggestion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2010

[Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

They've changed a lot from 1.0. For example, self, super, etc, are not in "orange" or that color of 1.0. Instances variables, are blue (instead of black), the same as parameters,etc... is there a way to recover the original colors? do we wanted this change or it is accidental ? cheers mariano

Oct. 15, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Guillermo Polito

BTW, why Stack inherits from LinkedList instead of just using it? Should an Stack have the entire Collection protocol? I don't think so... On Thu, Oct 14, 2010 at 5:31 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr > wrote: > Thanks!!! > > Stef > > On Oct 14, 2010, at 8:32 PM, jaayer wrote: > > > The original contains an error; it send min: where it should max:. This > one contains the > correction.<Stack.st>_______________________________________________ > > 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 >

Oct. 15, 2010

Re: [Pharo-project] FileChooser (Squeak) = ........ (Pharo)

by Henrik Johansen

On Oct 15, 2010, at 3:29 01PM, Hannes Hirzel wrote: > It seems to be > FileDialogWindow > > So the question is how is the following snippet translated. The > examples I found in the image did not work for some reason. > > "Squeak" > fc := FileChooser new. > fc initializeAsDialogBox. > fc open. > fc fullName > > On 10/15/10, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Hello >> >> I am porting an application from Squeak to Pharo (actually the >> moose-seaside-glamour image) and I wonder what the equivalent class of >> FileChooser is? >> >> There are five 'Chooser' classes in Pharo 1.1 but no FileChooser. >> >> Thank you for the answer in advance >> >> Hannes UIManager default chooseFileMatching: '*' ? Cheers, Henry

Oct. 15, 2010

Re: [Pharo-project] FileChooser (Squeak) = ........ (Pharo)

by Hannes Hirzel

It seems to be FileDialogWindow So the question is how is the following snippet translated. The examples I found in the image did not work for some reason. "Squeak" fc := FileChooser new. fc initializeAsDialogBox. fc open. fc fullName On 10/15/10, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello > > I am porting an application from Squeak to Pharo (actually the > moose-seaside-glamour image) and I wonder what the equivalent class of > FileChooser is? > > There are five 'Chooser' classes in Pharo 1.1 but no FileChooser. > > Thank you for the answer in advance > > Hannes >

Oct. 15, 2010

[Pharo-project] FileChooser (Squeak) = ........ (Pharo)

by Hannes Hirzel

Hello I am porting an application from Squeak to Pharo (actually the moose-seaside-glamour image) and I wonder what the equivalent class of FileChooser is? There are five 'Chooser' classes in Pharo 1.1 but no FileChooser. Thank you for the answer in advance Hannes

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Henrik Johansen

On Oct 15, 2010, at 1:41 06PM, Henrik Johansen wrote: > > On Oct 15, 2010, at 1:01 31PM, StÃ©phane Ducasse wrote: > >> >> On Oct 15, 2010, at 8:42 AM, Geert Claes wrote: >> >>> >>> Maybe a silly question, but it is the "code" of the book "Object Oriented >>> Implementation of Numerical Methods", so the book itself won't be available >>> for free? >>> >> > http://books.google.no/books?id=kKfY0SB0O-cC&printsec=frontcover&dq=Object+… > > Second hit on google of the title... > > Cheers, > Henry Weird, I could swear I had a tab open where all pages were viewable, but in the currently open one, the preview is limited. Sorry for the noise. Cheers, Henry

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Henrik Johansen

On Oct 15, 2010, at 1:01 31PM, StÃ©phane Ducasse wrote: > > On Oct 15, 2010, at 8:42 AM, Geert Claes wrote: > >> >> Maybe a silly question, but it is the "code" of the book "Object Oriented >> Implementation of Numerical Methods", so the book itself won't be available >> for free? >> > http://books.google.no/books?id=kKfY0SB0O-cC&printsec=frontcover&dq=Object+… Second hit on google of the title... Cheers, Henry

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by StÃ©phane Ducasse

On Oct 15, 2010, at 8:42 AM, Geert Claes wrote: > > Maybe a silly question, but it is the "code" of the book "Object Oriented > Implementation of Numerical Methods", so the book itself won't be available > for free? > I do not think so but if we can get the pdf it would be really good for my free Smalltalk books collection :) Stef > > StÃ©phane Ducasse wrote: >> >> I want to thanks didier for releasing the code of his book under MIT. >> Thanks! >> >> >> Didier Besset wrote: >>> >>> Begin forwarded message: >>>> From: Didier Besset <didier(a)ieee.org> >>>> Date: October 14, 2010 8:06:52 PM GMT+02:00 >>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Subject: Disclaimer >>>> >>>> I hereby release the code of my book "Object Oriented Implementation of >>>> Numerical Methods" under the > > MIT license. >>>> >>>> Didier Besset >>> >> > -- > View this message in context: http://forum.world.st/Object-Oriented-Implementation-of-Numerical-Methods-u… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

I've tested this strategy, and it works well: - use accessors self input/self output instead of inst. var. - lazily initialize the input for Collection and File In collection tests, I have used ^input ifNil:[input := outer terminal reading] where: outer := output := collection writing. This is because some Block transforms can't access the terminal collection... I have a bug with File though - it looks like double closing. The symptoms are that no file can't be further opened untill we quit the image... Nicolas 2010/10/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Or maybe I have something simple enough : > > 1) let setUp initialize the output but not the input > 2) access input via a message send and lazy initialization > For example, in collection tests, this would be > input > Â Â ^input ifNil:[input := output conclusion reading] > in file tests: > Â Â ^input ifNil:[input := file reading] > > What do you think ? > > Nicolas > > 2010/10/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/10/13 Â <mkobetic(a)gmail.com>: >>> Michael and I talked about this today a bit and here's what we're thinking about doing. >>> We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. >>> >>> At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. >>> >>> To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: >>> >>> testBlah >>> >>> Â Â Â Â self write: [ :output | .... ] >>> Â Â Â Â Â Â Â Â read: [ :input | ... ] >>> >>> Good enough ? >>> >> >> Seems fair to me. >> >> Nicolas >> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >

Oct. 15, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

Or maybe I have something simple enough : 1) let setUp initialize the output but not the input 2) access input via a message send and lazy initialization For example, in collection tests, this would be input ^input ifNil:[input := output conclusion reading] in file tests: ^input ifNil:[input := file reading] What do you think ? Nicolas 2010/10/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/10/13 Â <mkobetic(a)gmail.com>: >> Michael and I talked about this today a bit and here's what we're thinking about doing. >> We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. >> >> At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. >> >> To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: >> >> testBlah >> >> Â Â Â Â self write: [ :output | .... ] >> Â Â Â Â Â Â Â Â read: [ :input | ... ] >> >> Good enough ? >> > > Seems fair to me. > > Nicolas > >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 15, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Geert Claes

Maybe a silly question, but it is the "code" of the book "Object Oriented Implementation of Numerical Methods", so the book itself won't be available for free? StÃ©phane Ducasse wrote: > > I want to thanks didier for releasing the code of his book under MIT. > Thanks! > > > Didier Besset wrote: >> >> Begin forwarded message: >>> From: Didier Besset <didier(a)ieee.org> >>> Date: October 14, 2010 8:06:52 PM GMT+02:00 >>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Subject: Disclaimer >>> >>> I hereby release the code of my book "Object Oriented Implementation of >>> Numerical Methods" under the > > MIT license. >>> >>> Didier Besset >> > -- View this message in context: http://forum.world.st/Object-Oriented-Implementation-of-Numerical-Methods-u… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 15, 2010

Re: [Pharo-project] Problem installing Magritte2

by Lukas Renggli

> Indeed, the server is down currently. Sorry about that, it should work again. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 15, 2010

Re: [Pharo-project] OOP best practices

by laurent laffont

> > PerformedExperiment class >> > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > | instance | > instance := self new. > instance > initializeFor: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > ^ instance > I don't really like this way of formatting the message with line breaks. I agree on Inline Message Pattern in Kent Beck's Smalltalk Best Practice Patterns. There's the draft here http://stephane.ducasse.free.fr/FreeBooks/BestSmalltalkPractices/Draft-Smal… Look at p.127 / 128 Cheers, Laurent

Oct. 15, 2010

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Sheridan Mahoney

Hi all, The method that generated the error in issue 3090 is below: MethodContext(ContextPart)>>storeDataOn: aDataStream Â Â Â "Contexts are not allowed go to out in DataStreams.Â They must be included inside an ImageSegment." Â Â Â aDataStream insideASegment ifTrue: [^ super storeDataOn: aDataStream]. Â Â Â self error: 'This Context was not included in the ImageSegment'. Â Â Â Â Â Â "or perhaps ImageSegments were not used at all" Â Â Â ^ nil I've been trying to make sense of the stack, and it appears that writing a morph to a file is hooking an object which cannot be written to a DataStream. Does anyone know whether the proper behavior is to: - have the MethodContext go out without being inside an ImageSegment, or - fix the morph-writing so that it uses ImageSegments??? Mariano would love this, right? :) Or perhaps there's a better way to understand the stack. Many thanks, and Cheers, Sheri/dan *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-* Listening's Auspicious Fortune is a heart Rejuvenated with Profound Instructions. Reflection's Auspicious Fortune is the collapse Of delusion's false cavern. Kabje Kalu Rinpoche "With a pure motivation that does not wane and with great courage that does not despair, may each of us endeavour to make our lives meaningful " H.H. the 17th Karmapa Orgyen Trinley Dorje On Oct 11, 2010, at 7:16 AM, Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > Virtual machine used: 4.0.3.2202 Unix VM > OS: Ubuntu Lucid Lynx 10.04 > Class browser used if applicable: SystemBrowser default > > Steps to reproduce: > 1. start pharo > 2. open a Shout workspace > 3. select the just-opened workspace > 4. Ctrl-right button to get the meta-click window > 5. select 'save morph in file' > 6. hit 'ok' to proffered name for file > 7. a message box comes up that reads 'please wait while objects are > counted'. > 8. shortly after that an error is generated: > 'Error: this context was not included in the ImageSegment' > > > I'm planning on doing more research, but wanted to get the issue reported. > > Cheers, > Sheridan > > PS - so far I really like 1.1.1 !!! Good work, gang! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2010

Re: [Pharo-project] [Esug-list] Object Oriented Implementation of Numerical Methods" under the MIT license

by Paolo Bonzini

On 10/14/2010 10:02 PM, StÃ©phane Ducasse wrote: > I want to thanks didier for releasing the code of his book under MIT. That's great, thanks! Paolo

Oct. 14, 2010

Re: [Pharo-project] Problem installing Magritte2

by Miguel CobÃ¡

El jue, 14-10-2010 a las 19:14 -0300, Casimiro de Almeida Barreto escribiÃ³: > The following: > > (Installer squeaksource > project: 'MetacelloRepository'; > packagesMatching: 'ConfigurationOfMagritte2-*') first install. Why this way to install the configuration? Installer squeaksource project: 'MetacelloRepository'; package: 'ConfigurationOfMaggrite'; install. Is enough. Even better, if you're using Pharo, the Gofer is the official fetcher: Gofer it squeaksource: 'MetacelloRepository' package: 'ConfigurationOfMagritte' load > > ConfigurationOfMagritte2 project latestVersion load. > > Results in: Error: could not resolv Magritte-Model > [Magritte-Model-lr.397] > > Then, the site: source.lukas-renggli.ch returns: > > > Service Temporarily Unavailable > The server is temporarily unable to service your request due to > maintenance downtime or capacity problems. Please try again later. > > > ______________________________________________________________________ > Apache/2.2.14 (Ubuntu) Server at source.lukas-renggli.ch Port 80 Indeed, the server is down currently. This is one of the goals of the changes that the new Metacello repositories will bring, to not rely on a single server to get the packages that compose a given configuration. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 14, 2010

[Pharo-project] Problem installing Magritte2

by Casimiro de Almeida Barreto

The following: (Installer squeaksource project: 'MetacelloRepository'; packagesMatching: 'ConfigurationOfMagritte2-*') first install. ConfigurationOfMagritte2 project latestVersion load. Results in: Error: could not resolv Magritte-Model [Magritte-Model-lr.397] Then, the site: source.lukas-renggli.ch returns: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. ------------------------------------------------------------------------ Apache/2.2.14 (Ubuntu) Server at source.lukas-renggli.ch Port 80

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

Almost... :-) it would be: performedExperiment := PerformedExperiment for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" with: aCollectionOfTasks. DNU => HIT CREATE BUTTON => Automatically create the following methods 1) PerformedExperiment class >> for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. | instance | instance := self new. instance initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. ^ instance Save - Proceed - DNU -> Create Button -> 2) PerformedExperiment>> initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. self shouldBeImplemented. " Suggested code - Uncomment it if you like it :-) experiment := anExperiment. startTime := aStartTime. stopTime := aStopTime. participant := aParticipant. taks := aCollectionOfTasks. " The template can be created that way because it knows it is an initialize message, so it takes the parameter names to suggest the inst var names and assign to them the right parameters. Having these kind of "idioms" can really help when creating code automatically in such a context like the debugger 2010/10/14 Fernando olivero <fernando.olivero(a)usi.ch> > So a "smart template" created by the debugger would just do the following, > when defining the following Class method: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is > not a good name" > with: aCollectionOfTasks. > > DNU => HIT CREATE BUTTON => Automatically create the following methods > > 1) > PerformedExperiment class >> > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > | instance | > instance := self new. > instance > initializeFor: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > ^ instance > > 2) > PerformedExperiment>> initializeFor: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant > with: aCollectionOfTasks. > self shouldBeImplemented > > > > > > On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > > Hi Fernando, > I think that you are saying that having too many parameter could be a > problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, > and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have > an instance creation message that creates a "complete" object, then you > would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would > use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone > (in the former you can forget to send a message, ie. stop: and nobody will > complain immediately, but in the last one you wont make that mistake, or if > you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it > could bother a little the reading, but when there are so many parameters I > format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the > inst. creation message. This helps when analyzing code automatically (ie. > initialize messages should only be sent from the class side) or generating > code automatically on the debugger with the create button (as the > enhancement 3099 that I sent the other day, the debugger could be smart > enough to realize it is an initialization message so it could provide a > better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using > as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is > not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like > "experimient: anExperiment", "start: anStartTime", etc., with the last one > you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch > > wrote: > >> Hi Hernan, just wanted to get your opinion on the following method, that >> attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). >> >> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks >> | experiment | >> experiment := self new. >> experiment experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks. >> ^ experiment >> >> >> In your experience, how does the pattern cope with large keyword >> selectors. >> >> Maybe this case is not that evident, although we should try to avoid >> having more than 4 instance variables anyway, i would like to get your >> opinion on this problem (?). >> >> Thanks, >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > <ATT00001..txt> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

cool! remember also the other tip, that the object should be valid from scratch... so, for this example I would do something like this: PerformedExperiment class>>for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks PatAssertionsRunner valueWith: (self assertionForPerformedExperimentStartedAt: aStartTime before: aStopTime). ^self new initializeExperimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks That way if the stoptime is before starttime (wich I beleive is an error in this case) the object is not created and you wont have an invalid performed experiment. You will see that asserting that something starts before the "stop" is very common, so I suggest to use an interval to represent that but not the smalltalk Interval that does not verify that condition but the Aconcagua Interval that verifies that intervals are valid. So you could change the message to something like this: PerformedExperiment class>>for: anExperiment during: aTimePeriod madeBy: aParticipant with: aCollectionOfTasks ^self new initializeExperimient: anExperiment during: aTimePeriod participant: aParticipant tasks: aCollectionOfTasks Doing so you get less parameters and only valid "time periods" (intervals) that leads to valid performed experiments. Another assertion that you may have is if aCollectionOfTasks can be empty... anyway, thinking about this constrains helps you to create a better model and understand the business rules. I hope it helps! Hernan. 2010/10/14 Fernando olivero <fernando.olivero(a)usi.ch> > THANKS Hernan! > > With the example i've got to understand the correct usage of the pattern > now. Which of course i will follow from now on, given the benefits from > having complete objects! ( no messy ifNil checks for starters!, etc...) > > > > > On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > > Hi Fernando, > I think that you are saying that having too many parameter could be a > problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, > and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have > an instance creation message that creates a "complete" object, then you > would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would > use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone > (in the former you can forget to send a message, ie. stop: and nobody will > complain immediately, but in the last one you wont make that mistake, or if > you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it > could bother a little the reading, but when there are so many parameters I > format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the > inst. creation message. This helps when analyzing code automatically (ie. > initialize messages should only be sent from the class side) or generating > code automatically on the debugger with the create button (as the > enhancement 3099 that I sent the other day, the debugger could be smart > enough to realize it is an initialization message so it could provide a > better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using > as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is > not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like > "experimient: anExperiment", "start: anStartTime", etc., with the last one > you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch > > wrote: > >> Hi Hernan, just wanted to get your opinion on the following method, that >> attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). >> >> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks >> | experiment | >> experiment := self new. >> experiment experiment: anExperiment start: aTime stop: aStopTime >> participant: aParticipant tasks: aCollectionOfTasks. >> ^ experiment >> >> >> In your experience, how does the pattern cope with large keyword >> selectors. >> >> Maybe this case is not that evident, although we should try to avoid >> having more than 4 instance variables anyway, i would like to get your >> opinion on this problem (?). >> >> Thanks, >> Fernando >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > <ATT00001..txt> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 14, 2010