August 2010 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Moose-dev] Re: [Survey] Assess the cycles in your software

by Tudor Girba

I apologize for not doing it earlier. I will do it until Tuesday. Cheers, Doru On 13 Aug 2010, at 16:33, Laval Jannik wrote: > Hi all, > > A (second) reminder for people who wants to participate. > We need help from the community. > > Cheers, > Jannik > > On Jul 19, 2010, at 08:36 , Laval Jannik wrote: > >> Hi Pharoers, and Smalltalkers in general, >> >> Have you seen waited to assess the cycles in your software? Now you >> can :) >> >> We request some of you to perform an experiment using DSM to see >> your software package structure and to fix cycles between packages. >> Our tool shows dependencies between packages and highlight some bad >> dependencies generating structure cycles. It also helps to >> understand dependencies. >> >> Your goal is to fill a survey using our tool. >> I prepared a mini-tutorial about DSM and eDSM. It can help you to >> understand the visualization tool. >> >> To ease the use of our tool, I loaded it in a PharoCore1.2. And >> there are two archives available: >> - the first contains an image with our tool with a model of Pharo >> loaded in it, so you can play with our tool on pharo itself. It can >> be downloaded here: http://dl.dropbox.com/u/7739334/ >> dsmWithPharo.zip. Pay attention, the image is slow. >> - the second contains the same thing without the model of Pharo. >> Here, you have to load your code, then populate a moose model and >> use the tool. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithoutPharo.zip >> The two archives contain the tutorial and the survey. If you are a >> pharo integrator, we suggest you to take the one with Pharo model >> loaded, else the other. >> >> To use our tool, load your tool in Pharo. Then do "MoosePanel >> open", and import your software in Moose by "import from Smalltalk >> image". When it is imported, select your project in the list on the >> left of MoosePanel, and select "all model packages" on the list on >> center. >> >> Then, you have two choices: >> - you can scan all your project: right click on "all model >> packages" and do DSM. >> - or select "all model packages" then select some packages in the >> next list and right click, do DSM. >> >> After that, you can perform the survey (with reading of the >> tutorial). We need your answers for the end of August. So, you have >> two months to do it. >> >> If you have any question, just let me know. >> >> Best regards, >> Jannik. >> >> --- >> Jannik Laval >> PhD Student - Rmod Team - INRIA >> Certified Project Management Associate (IPMA) >> http://www.jannik-laval.eu >> http://rmod.lille.inria.fr >> --- >> > > --- > Jannik Laval > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Aug. 13, 2010

Re: [Pharo-users] WebClient

by Miguel Enrique CobÃ¡ MartÃnez

El vie, 13-08-2010 a las 12:11 +0200, StÃ©phane Ducasse escribiÃ³: > Since we agree that we want to use WebClient in pharo by default, it would be nice to start > pushing it into 1.2. I was waiting a bit to get some more feedback. What we could do > is > - load it in 1.2 > - update it when andreas publish new versions > - start forwarding to webClient > - remove the other code slowly > > What do you think? > Stef +1, I think GermÃ¡n Arduino began the work to include WebClient in Pharo. He could give an update. Also, now that WebClient includes OAuth support Seaside apps and Pharo in general could benefit by allowing connecting to Twitter and Facebook sites. Cheers > > On Jun 10, 2010, at 4:09 PM, Sven Van Caekenberghe wrote: > > > Hi, > > > > Andreas Raab's 'new' WebClient/WebServer seems quite nice, as he says himself: > > > > As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in every respect. > > > > Is this something that will / should fit seamlessly into Pharo ? Or even become preinstalled ? > > > > I didn't try his ConfigurationOfWebClient since the last version was unreadable and it seemed like an experiment, while his textual explanation was easy to follow. > > > > To load it into and to make the unit tests run in Pharo 1.0 I had to make a couple of fixes (to WebCookie#printOn: and WebServer class#serverString). Who should I sent these changes to ? > > > > But even then 1 unit test failed (#testServerDestroy). > > > > Furthermore, some the changes in his package WebClient-Pharo seem a bit dangerous, especially a modification to SocketStream#peek (and the failed test was doing a peek) and an override of String#, some others are unneccessary as far as I can see. > > > > Sven > > > > -- > > Sven Van Caekenberghe - mailto:sven@beta9.be > > Beta Nine - software engineering - http://www.beta9.be > > .Mac - svc(a)mac.com - http://homepage.mac.com/svc > > > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 13, 2010

Re: [Pharo-users] [Survey] Assess the cycles in your software

by Laval Jannik

Hi all, A (second) reminder for people who wants to participate. We need help from the community. Cheers, Jannik On Jul 19, 2010, at 08:36 , Laval Jannik wrote: > Hi Pharoers, and Smalltalkers in general, > > Have you seen waited to assess the cycles in your software? Now you can :) > > We request some of you to perform an experiment using DSM to see your software package structure and to fix cycles between packages. Our tool shows dependencies between packages and highlight some bad dependencies generating structure cycles. It also helps to understand dependencies. > > Your goal is to fill a survey using our tool. > I prepared a mini-tutorial about DSM and eDSM. It can help you to understand the visualization tool. > > To ease the use of our tool, I loaded it in a PharoCore1.2. And there are two archives available: > - the first contains an image with our tool with a model of Pharo loaded in it, so you can play with our tool on pharo itself. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithPharo.zip. Pay attention, the image is slow. > - the second contains the same thing without the model of Pharo. Here, you have to load your code, then populate a moose model and use the tool. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithoutPharo.zip > The two archives contain the tutorial and the survey. If you are a pharo integrator, we suggest you to take the one with Pharo model loaded, else the other. > > To use our tool, load your tool in Pharo. Then do "MoosePanel open", and import your software in Moose by "import from Smalltalk image". When it is imported, select your project in the list on the left of MoosePanel, and select "all model packages" on the list on center. > > Then, you have two choices: > - you can scan all your project: right click on "all model packages" and do DSM. > - or select "all model packages" then select some packages in the next list and right click, do DSM. > > After that, you can perform the survey (with reading of the tutorial). We need your answers for the end of August. So, you have two months to do it. > > If you have any question, just let me know. > > Best regards, > Jannik. > > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > --- Jannik Laval

Aug. 13, 2010

Re: [Pharo-users] RecentMessageList

by Guillermo Polito

On Fri, Aug 13, 2010 at 7:06 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Aug 11, 2010, at 11:05 PM, Guillermo Polito wrote: > > > Hi! > > > > I submitted a little fix where the UI is updated and the example is > working. > > How? > Because the model should not rely on the UI as it was before > Well, I add a "self changed" in the #updateView method of the model, and made the view update in the #update:. Maybe this can be cleaner using the bindings.. > > I expect you don't get upset for touching it. > > > > By the way, I have some extra comments: > > > > -Why there are MessageList and RecentMessageList? Why not only one of > them? > > Because you can reuse MessageList in other circumstances > Yeah, but it seemed a little of overdesing to me :$. This was not necessary now, that's all. > > > > -Why MethodReferenceWithSource is called like that? It can contain also > Class references... Otherwise, maybe there is a better name for that class. > Maybe something like RecentChangeNotification or something like that... > > This has nothing to do with notification. This is just an extension of > MethodReference > > Looking the code I thought this RecentMessageList stored and showed the last methods and classes changed. I don't know if XXNotification is the best name. > > > -There is no RecentMessageList example or similar!!!! I had to browse > the code and guess that "RecentMessageList new openInWorld" should open it > :). > > > > - All the asDictionaryByXXX are very similar... Maybe you can build a > asDictionaryBy (or groupedBy: as Stephane said) parametrized like: > > > > groupBy: groupBlock valueBy: valueBlock > > | result tempList | > > result := Dictionary new. > > tempList := self methodReferenceList copy sort: [:m1 :m2 | m2 > timeStamp <= m1 timeStamp]. > > tempList do: [:each | > > | key value | > > key := groupBlock value each. > > value := valueBlock value: each. > > (result includesKey: key) > > ifFalse: [result at: key put: OrderedCollection new]. > > (result at: key) add: value]. > > ^(Association key: result value: tempList) > > probably > > > - And that reminds me: Why does that method return an association? So > you can return multiple values? :( Thats not nice.. Maybe you can make the > RecentMessageList stateful and let it have a sorted collection with the > sorted elements. Maybe playing with that let you manage the speed problems. > > > > - And maybe you should look at SettingBrowser>>treeMorphIn:. There's the > way to build a MorphTreeMorph binded to a list, so you can update the view > sending the message #changed to the model. > > Yes that part I do not know > > > > > Cheers, > > Guille > > > > On Tue, Aug 10, 2010 at 8:11 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Hi benjamin > > > > Thanks for your code!!!! > > > > I did a review of your latest code: Here are some points that it would be > nice to address > > I fixed what I saw and republished > > > > > > 0 - all the classes should have comments > > > > MessageList > > ---------- > > 1- MessageList example does not work > > Can you create some Unit tests to cover the expected behavior of > the MessageList > > > > 2- MessageList>>browsers > > I removed it > > > > 3- recategorized the methods > > > > 4- I removed all the "comment10" > > > > 5- what I level > > Can you comment it? > > > > 6- for asDictionaryByClass > > why don't you use groupedBy: or similar methods? > > I'm not sure that I would call them asDictionaryBy.... since you > return an association? > > > > > > Why don't you call them groupedBySelectors, groupedByClasses, > groupedByPackages > > then why do you return an Association and not a dictionary. > > > > 7- Can you add oneline method comments to method? > > > > > > 8- Could you introduce an explicit instance variable representing the > environment in use and initialize > > it with Smalltalk globals because like that we can specify in > which environment the set is working. > > > > 9- openInWorldWithADictionarySelector: sucks :) > > the name is not really cool > > then you bind the core with the UI > > so you should define this method as an extension of > RecentSubmission-UI and may be > > > > 10- You update all the browsers open but this should not be your role. > > As a core domain object you should not do this kind of behavior. The UI > widget should register to event > > or notification and update themselves when you change. > > > > updateView > > browsers ifNotNilDo: [:collection | collection do: [:each > | each updateView]] > > > > > > MessageListAssociation > > -------------------- > > why do you need this guy? > > Just to print the elements? > > This is a UI concerns. The UI should wrap the model and provide a > specific printed version > > or the MessageListAssociation should be explained in the class > comment > > > > > > MethodReferenceWithSource > > ------------------------ > > We should probably move some behavior to MethodReference > > > > > > NullTextStyler > > ------------ > > I categorized all the methods following SHStyler categories > > > > RecentMessageList > > ---------------- > > I cleaned the singleton part. > > You do not need > > UniqueInstance ifNotNil: [:u | UniqueInstance releaseAll]. > > > > Again the model should not be referencing the ui > > releaseAll > > super initialize. > > MessageListBrowser allInstancesDo: [:each | each > messageList = self ifTrue:[each delete]]. > > browser:= nil. > > self methodReferenceList: OrderedCollection new. > > > > > > Why the setting is registration is done in the core and not at the > level of the widget? > > > > > > - at startUp: you should not create the instance since > uniqueInstance is lazzily accessed. > > However you should register to the SystemChangeNotifier to get the > notification. > > > > > > > > > > MessageListBrowser > > ----------------- > > Instead of having > > > > MessageListBrowser >>byDateAscendingOn: aMessageList > > > > ^self > > on: aMessageList > > withADictionarySelector: #asDictionaryByDateAscending. > > > > > > MessageListBrowser >>byDateAscendingOn: aMessageList > > > > ^self > > on: aMessageList > > withADictionarySelector: aMessageList > asDictionaryByDateAscendingSelector > > > > and > > > > MessageList>> asDictionaryByDateAscendingSelector > > ^ #asDictionaryByDateAscending > > > > => encapsulate information from model to UI. > > => I did it > > > > > > > > So for now this is enough :) > > > > > > Stef > > > > On Aug 1, 2010, at 3:00 AM, Benjamin Van Ryseghem wrote: > > > > > Gofer new > > > squeaksource: 'PharoTaskForces'; > > > package: 'RecentSubmissions'; > > > load. > > > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Aug. 13, 2010

Re: [Pharo-users] WebClient

by StÃ©phane Ducasse

Since we agree that we want to use WebClient in pharo by default, it would be nice to start pushing it into 1.2. I was waiting a bit to get some more feedback. What we could do is - load it in 1.2 - update it when andreas publish new versions - start forwarding to webClient - remove the other code slowly What do you think? Stef On Jun 10, 2010, at 4:09 PM, Sven Van Caekenberghe wrote: > Hi, > > Andreas Raab's 'new' WebClient/WebServer seems quite nice, as he says himself: > > As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in every respect. > > Is this something that will / should fit seamlessly into Pharo ? Or even become preinstalled ? > > I didn't try his ConfigurationOfWebClient since the last version was unreadable and it seemed like an experiment, while his textual explanation was easy to follow. > > To load it into and to make the unit tests run in Pharo 1.0 I had to make a couple of fixes (to WebCookie#printOn: and WebServer class#serverString). Who should I sent these changes to ? > > But even then 1 unit test failed (#testServerDestroy). > > Furthermore, some the changes in his package WebClient-Pharo seem a bit dangerous, especially a modification to SocketStream#peek (and the failed test was doing a peek) and an override of String#, some others are unneccessary as far as I can see. > > Sven > > -- > Sven Van Caekenberghe - mailto:sven@beta9.be > Beta Nine - software engineering - http://www.beta9.be > .Mac - svc(a)mac.com - http://homepage.mac.com/svc > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 13, 2010

Re: [Pharo-users] RecentMessageList

by StÃ©phane Ducasse

On Aug 11, 2010, at 11:05 PM, Guillermo Polito wrote: > Hi! > > I submitted a little fix where the UI is updated and the example is working. How? Because the model should not rely on the UI as it was before > I expect you don't get upset for touching it. > > By the way, I have some extra comments: > > -Why there are MessageList and RecentMessageList? Why not only one of them? Because you can reuse MessageList in other circumstances > -Why MethodReferenceWithSource is called like that? It can contain also Class references... Otherwise, maybe there is a better name for that class. Maybe something like RecentChangeNotification or something like that... This has nothing to do with notification. This is just an extension of MethodReference > -There is no RecentMessageList example or similar!!!! I had to browse the code and guess that "RecentMessageList new openInWorld" should open it :). > - All the asDictionaryByXXX are very similar... Maybe you can build a asDictionaryBy (or groupedBy: as Stephane said) parametrized like: > > groupBy: groupBlock valueBy: valueBlock > | result tempList | > result := Dictionary new. > tempList := self methodReferenceList copy sort: [:m1 :m2 | m2 timeStamp <= m1 timeStamp]. > tempList do: [:each | > | key value | > key := groupBlock value each. > value := valueBlock value: each. > (result includesKey: key) > ifFalse: [result at: key put: OrderedCollection new]. > (result at: key) add: value]. > ^(Association key: result value: tempList) probably > - And that reminds me: Why does that method return an association? So you can return multiple values? :( Thats not nice.. Maybe you can make the RecentMessageList stateful and let it have a sorted collection with the sorted elements. Maybe playing with that let you manage the speed problems. > > - And maybe you should look at SettingBrowser>>treeMorphIn:. There's the way to build a MorphTreeMorph binded to a list, so you can update the view sending the message #changed to the model. Yes that part I do not know > > Cheers, > Guille > > On Tue, Aug 10, 2010 at 8:11 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi benjamin > > Thanks for your code!!!! > > I did a review of your latest code: Here are some points that it would be nice to address > I fixed what I saw and republished > > > 0 - all the classes should have comments > > MessageList > ---------- > 1- MessageList example does not work > Can you create some Unit tests to cover the expected behavior of the MessageList > > 2- MessageList>>browsers > I removed it > > 3- recategorized the methods > > 4- I removed all the "comment10" > > 5- what I level > Can you comment it? > > 6- for asDictionaryByClass > why don't you use groupedBy: or similar methods? > I'm not sure that I would call them asDictionaryBy.... since you return an association? > > > Why don't you call them groupedBySelectors, groupedByClasses, groupedByPackages > then why do you return an Association and not a dictionary. > > 7- Can you add oneline method comments to method? > > > 8- Could you introduce an explicit instance variable representing the environment in use and initialize > it with Smalltalk globals because like that we can specify in which environment the set is working. > > 9- openInWorldWithADictionarySelector: sucks :) > the name is not really cool > then you bind the core with the UI > so you should define this method as an extension of RecentSubmission-UI and may be > > 10- You update all the browsers open but this should not be your role. > As a core domain object you should not do this kind of behavior. The UI widget should register to event > or notification and update themselves when you change. > > updateView > browsers ifNotNilDo: [:collection | collection do: [:each | each updateView]] > > > MessageListAssociation > -------------------- > why do you need this guy? > Just to print the elements? > This is a UI concerns. The UI should wrap the model and provide a specific printed version > or the MessageListAssociation should be explained in the class comment > > > MethodReferenceWithSource > ------------------------ > We should probably move some behavior to MethodReference > > > NullTextStyler > ------------ > I categorized all the methods following SHStyler categories > > RecentMessageList > ---------------- > I cleaned the singleton part. > You do not need > UniqueInstance ifNotNil: [:u | UniqueInstance releaseAll]. > > Again the model should not be referencing the ui > releaseAll > super initialize. > MessageListBrowser allInstancesDo: [:each | each messageList = self ifTrue:[each delete]]. > browser:= nil. > self methodReferenceList: OrderedCollection new. > > > Why the setting is registration is done in the core and not at the level of the widget? > > > - at startUp: you should not create the instance since uniqueInstance is lazzily accessed. > However you should register to the SystemChangeNotifier to get the notification. > > > > > MessageListBrowser > ----------------- > Instead of having > > MessageListBrowser >>byDateAscendingOn: aMessageList > > ^self > on: aMessageList > withADictionarySelector: #asDictionaryByDateAscending. > > > MessageListBrowser >>byDateAscendingOn: aMessageList > > ^self > on: aMessageList > withADictionarySelector: aMessageList asDictionaryByDateAscendingSelector > > and > > MessageList>> asDictionaryByDateAscendingSelector > ^ #asDictionaryByDateAscending > > => encapsulate information from model to UI. > => I did it > > > > So for now this is enough :) > > > Stef > > On Aug 1, 2010, at 3:00 AM, Benjamin Van Ryseghem wrote: > > > Gofer new > > squeaksource: 'PharoTaskForces'; > > package: 'RecentSubmissions'; > > load. > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 13, 2010

WebClient-Core port to Pharo 1.1 final

by Sven Van Caekenberghe

Hi Andreas, I made some changes to the latest WebClient-Core in order to run it on Pharo 1.1: Sven Van Caekenberghe uploaded a new version of WebClient-Core to project A Day At The Beach: http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… ==================== Summary ==================== Name: WebClient-Core-SvenVanCaekenberghe.63 Author: SvenVanCaekenberghe Time: 12 August 2010, 10:46:11 am UUID: 149d44b2-138b-4d63-a158-f587b2bd391d Ancestors: WebClient-Core-ar.62 added some more #asString's where needed to deal with the different semantics of #, in Squeak vs Pharo; removed usage of #and:and:and:and: with a composition of #and: in WebClient>>connect ================================================ I still have some tests that fail, but I can't find the problem: 39 run, 34 passes, 0 expected failures, 0 failures, 5 errors, 0 unexpected passes Failures: Errors: WebClientServerTest>>#testMultipartFiles WebClientServerTest>>#testMultipartFiles2 WebClientServerTest>>#testServerError WebClientServerTest>>#testWebSockets WebClientServerTest>>#testWebSocketsFraming The #testServerError bothers me most. I am posting this to a Pharo list as well so that maybe others can help. Maybe I'll find the problems myself later on. Sven

Aug. 12, 2010

Re: [Pharo-users] RecentMessageList

by Guillermo Polito

Hi! I submitted a little fix where the UI is updated and the example is working. I expect you don't get upset for touching it. By the way, I have some extra comments: -Why there are MessageList and RecentMessageList? Why not only one of them? -Why MethodReferenceWithSource is called like that? It can contain also Class references... Otherwise, maybe there is a better name for that class. Maybe something like RecentChangeNotification or something like that... -There is no RecentMessageList example or similar!!!! I had to browse the code and guess that "RecentMessageList new openInWorld" should open it :). - All the asDictionaryByXXX are very similar... Maybe you can build a asDictionaryBy (or groupedBy: as Stephane said) parametrized like: groupBy: groupBlock valueBy: valueBlock | result tempList | result := Dictionary new. tempList := self methodReferenceList copy sort: [:m1 :m2 | m2 timeStamp <= m1 timeStamp]. tempList do: [:each | | key value | key := groupBlock value each. value := valueBlock value: each. (result includesKey: key) ifFalse: [result at: key put: OrderedCollection new]. (result at: key) add: value]. ^(Association key: result value: tempList) - And that reminds me: Why does that method return an association? So you can return multiple values? :( Thats not nice.. Maybe you can make the RecentMessageList stateful and let it have a sorted collection with the sorted elements. Maybe playing with that let you manage the speed problems. - And maybe you should look at SettingBrowser>>treeMorphIn:. There's the way to build a MorphTreeMorph binded to a list, so you can update the view sending the message #changed to the model. Cheers, Guille On Tue, Aug 10, 2010 at 8:11 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi benjamin > > Thanks for your code!!!! > > I did a review of your latest code: Here are some points that it would be > nice to address > I fixed what I saw and republished > > > 0 - all the classes should have comments > > MessageList > ---------- > 1- MessageList example does not work > Can you create some Unit tests to cover the expected behavior of the > MessageList > > 2- MessageList>>browsers > I removed it > > 3- recategorized the methods > > 4- I removed all the "comment10" > > 5- what I level > Can you comment it? > > 6- for asDictionaryByClass > why don't you use groupedBy: or similar methods? > I'm not sure that I would call them asDictionaryBy.... since you > return an association? > > > Why don't you call them groupedBySelectors, groupedByClasses, > groupedByPackages > then why do you return an Association and not a dictionary. > > 7- Can you add oneline method comments to method? > > > 8- Could you introduce an explicit instance variable representing the > environment in use and initialize > it with Smalltalk globals because like that we can specify in which > environment the set is working. > > 9- openInWorldWithADictionarySelector: sucks :) > the name is not really cool > then you bind the core with the UI > so you should define this method as an extension of > RecentSubmission-UI and may be > > 10- You update all the browsers open but this should not be your role. > As a core domain object you should not do this kind of behavior. The UI > widget should register to event > or notification and update themselves when you change. > > updateView > browsers ifNotNilDo: [:collection | collection do: [:each | > each updateView]] > > > MessageListAssociation > -------------------- > why do you need this guy? > Just to print the elements? > This is a UI concerns. The UI should wrap the model and provide a > specific printed version > or the MessageListAssociation should be explained in the class > comment > > > MethodReferenceWithSource > ------------------------ > We should probably move some behavior to MethodReference > > > NullTextStyler > ------------ > I categorized all the methods following SHStyler categories > > RecentMessageList > ---------------- > I cleaned the singleton part. > You do not need > UniqueInstance ifNotNil: [:u | UniqueInstance releaseAll]. > > Again the model should not be referencing the ui > releaseAll > super initialize. > MessageListBrowser allInstancesDo: [:each | each > messageList = self ifTrue:[each delete]]. > browser:= nil. > self methodReferenceList: OrderedCollection new. > > > Why the setting is registration is done in the core and not at the > level of the widget? > > > - at startUp: you should not create the instance since > uniqueInstance is lazzily accessed. > However you should register to the SystemChangeNotifier to get the > notification. > > > > > MessageListBrowser > ----------------- > Instead of having > > MessageListBrowser >>byDateAscendingOn: aMessageList > > ^self > on: aMessageList > withADictionarySelector: #asDictionaryByDateAscending. > > > MessageListBrowser >>byDateAscendingOn: aMessageList > > ^self > on: aMessageList > withADictionarySelector: aMessageList > asDictionaryByDateAscendingSelector > > and > > MessageList>> asDictionaryByDateAscendingSelector > ^ #asDictionaryByDateAscending > > => encapsulate information from model to UI. > => I did it > > > > So for now this is enough :) > > > Stef > > On Aug 1, 2010, at 3:00 AM, Benjamin Van Ryseghem wrote: > > > Gofer new > > squeaksource: 'PharoTaskForces'; > > package: 'RecentSubmissions'; > > load. > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Aug. 11, 2010

Re: [Pharo-users] RecentMessageList

by StÃ©phane Ducasse

Hi benjamin Thanks for your code!!!! I did a review of your latest code: Here are some points that it would be nice to address I fixed what I saw and republished 0 - all the classes should have comments MessageList ---------- 1- MessageList example does not work Can you create some Unit tests to cover the expected behavior of the MessageList 2- MessageList>>browsers I removed it 3- recategorized the methods 4- I removed all the "comment10" 5- what I level Can you comment it? 6- for asDictionaryByClass why don't you use groupedBy: or similar methods? I'm not sure that I would call them asDictionaryBy.... since you return an association? Why don't you call them groupedBySelectors, groupedByClasses, groupedByPackages then why do you return an Association and not a dictionary. 7- Can you add oneline method comments to method? 8- Could you introduce an explicit instance variable representing the environment in use and initialize it with Smalltalk globals because like that we can specify in which environment the set is working. 9- openInWorldWithADictionarySelector: sucks :) the name is not really cool then you bind the core with the UI so you should define this method as an extension of RecentSubmission-UI and may be 10- You update all the browsers open but this should not be your role. As a core domain object you should not do this kind of behavior. The UI widget should register to event or notification and update themselves when you change. updateView browsers ifNotNilDo: [:collection | collection do: [:each | each updateView]] MessageListAssociation -------------------- why do you need this guy? Just to print the elements? This is a UI concerns. The UI should wrap the model and provide a specific printed version or the MessageListAssociation should be explained in the class comment MethodReferenceWithSource ------------------------ We should probably move some behavior to MethodReference NullTextStyler ------------ I categorized all the methods following SHStyler categories RecentMessageList ---------------- I cleaned the singleton part. You do not need UniqueInstance ifNotNil: [:u | UniqueInstance releaseAll]. Again the model should not be referencing the ui releaseAll super initialize. MessageListBrowser allInstancesDo: [:each | each messageList = self ifTrue:[each delete]]. browser:= nil. self methodReferenceList: OrderedCollection new. Why the setting is registration is done in the core and not at the level of the widget? - at startUp: you should not create the instance since uniqueInstance is lazzily accessed. However you should register to the SystemChangeNotifier to get the notification. MessageListBrowser ----------------- Instead of having MessageListBrowser >>byDateAscendingOn: aMessageList ^self on: aMessageList withADictionarySelector: #asDictionaryByDateAscending. MessageListBrowser >>byDateAscendingOn: aMessageList ^self on: aMessageList withADictionarySelector: aMessageList asDictionaryByDateAscendingSelector and MessageList>> asDictionaryByDateAscendingSelector ^ #asDictionaryByDateAscending => encapsulate information from model to UI. => I did it So for now this is enough :) Stef On Aug 1, 2010, at 3:00 AM, Benjamin Van Ryseghem wrote: > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'RecentSubmissions'; > load.

Aug. 10, 2010

Re: [Pharo-users] Starting a new ancestry from an MC package

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > normally yes. > Ha, ha. When I wrote that, I thought, "I wonder if someone is going to respond with 'yes|no'." Sean -- View this message in context: http://forum.world.st/Starting-a-new-ancestry-from-an-MC-package-tp2318679p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 9, 2010