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

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