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

Re: [Pharo-users] SqueakCompatibility

by Mariano Martinez Peck

On Sat, Aug 14, 2010 at 3:13 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > What is SqueakCompatibility? It's listed as a non-core package on > http://book.pharo-project.org/book/table-of-contents/PharoTools, and the > only reference I found in the mailing lists was a slice for Menu > Registries. > Is this one the same? The name sounds like it may be intended as a more > general compatibility layer. > > I asked the same. I remember someone (maybe Stef) told me "Mariano, could you please add the package SqueakCompatibility?". But I have no idea what it is. Cheers Mariano > Thanks. > Sean > -- > View this message in context: > http://forum.world.st/SqueakCompatibility-tp2325190p2325190.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Aug. 14, 2010

Re: [Pharo-users] RecentMessageList

by Benjamin Van Ryseghem

> at some place you use Smalltalk globals to access the class. > > Now it would be better to have an environment instance variable that is > initialized by default to point to Smalltalk globals. > Like that I can use your code if I want to store a list of message with > another environment that Smalltalk globals > I can pass another instance of systemDictionary with what I want inside > > Stef > Ok, i've added a environment variable in MessageList which is initialized trought the environment method ;) > > good! > For the record > these are not annoucement but events. Announcement pass objects as send: > parameters. > > Stef > Ok, i'll resume trying to understand how Announcement works ... > have a look at the code, the point is that as a class you do not want to > let the user decide how to interpret you. > You can say there are three ways to change me > 1, 2, 3 > but not how you decided internally to represent them. > I just made asDictionaryByDateAscendingSelector = a choice like 1 > the client does not have to know that this is #asDictionaryByDateAscending. > It could be anything else. > > Setf > Ok, now i see :) Thank you again Ben

Aug. 14, 2010

SqueakCompatibility

by Sean P. DeNigris

What is SqueakCompatibility? It's listed as a non-core package on http://book.pharo-project.org/book/table-of-contents/PharoTools, and the only reference I found in the mailing lists was a slice for Menu Registries. Is this one the same? The name sounds like it may be intended as a more general compatibility layer. Thanks. Sean -- View this message in context: http://forum.world.st/SqueakCompatibility-tp2325190p2325190.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 14, 2010

Re: [Pharo-users] RecentMessageList

by StÃ©phane Ducasse

have a look at the code, the point is that as a class you do not want to let the user decide how to interpret you. You can say there are three ways to change me 1, 2, 3 but not how you decided internally to represent them. I just made asDictionaryByDateAscendingSelector = a choice like 1 the client does not have to know that this is #asDictionaryByDateAscending. It could be anything else. Setf On Aug 13, 2010, at 8:44 PM, Benjamin Van Ryseghem wrote: > > MessageListBrowser >>byDateAscendingOn: aMessageList > > ^self > on: aMessageList > withADictionarySelector: aMessageList asDictionaryByDateAscendingSelector > > and > > MessageList>> asDictionaryByDateAscendingSelector > ^ #asDictionaryByDateAscending > > => encapsulate information from model to UI. > => I did it > > I do not understand :s

Aug. 13, 2010

Re: [Pharo-users] RecentMessageList

by StÃ©phane Ducasse

good! For the record these are not annoucement but events. Announcement pass objects as send: parameters. Stef On Aug 13, 2010, at 8:44 PM, Benjamin Van Ryseghem wrote: > I've fixed that using Announcement > > > MessageList >> updateView > self triggerEvent: #changed > > MessageListBrowser >> messageList: anObject > messageList := anObject. > messageList > when: #changed > send: #updateView > to: self. > messageList > when: #reset > send: #delete > to: self.

Aug. 13, 2010

Re: [Pharo-users] RecentMessageList

by StÃ©phane Ducasse

at some place you use Smalltalk globals to access the class. Now it would be better to have an environment instance variable that is initialized by default to point to Smalltalk globals. Like that I can use your code if I want to store a list of message with another environment that Smalltalk globals I can pass another instance of systemDictionary with what I want inside On Aug 13, 2010, at 8:44 PM, Benjamin Van Ryseghem wrote: > > 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. > > I do not understand ...

Aug. 13, 2010

Re: [Pharo-users] [SPAM] Re: WebClient

by StÃ©phane Ducasse

> Well, I did some effort before and got Andreas to include a number of patches so that his WebClient-Core loaded into Pharo without a need for a compatibility layer. The lastest version does no longer have this property ;-) > > I again submitted some patches to Andreas ( http://forum.world.st/WebClient-Core-port-to-Pharo-1-1-final-td2322411.html… ) but he hasn't responded yet. Futhermore, I did not yet fix everything, but the code works for my purposes. > > As I discussed with StÃ©phane, it is not clear for me how this must go further, since we keep on running 'behind'. So it is good to discuss this here. like that :) >>> - load it in 1.2 >>> - update it when andreas publish new versions >>> - start forwarding to webClient >>> - remove the other code slowly I do not feel as running behind. Just been pragmatic. The rewrite of network was a task on the proposal we wrote for inria the engineer will just help/do something else and we use webclient and on a regular basis merge from the project of andreas we did that for polymorph continuously in pharo 1.0. stef

Aug. 13, 2010

Re: [Pharo-users] RecentMessageList

by Benjamin Van Ryseghem

> 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 > I'm on it, but it's a bit long > > MessageList > ---------- > 1- MessageList example does not work > Can you create some Unit tests to cover the expected behavior of the > MessageList > I've fixed it thanks to Guillermo Polito :) > > 2- MessageList>>browsers > I removed it > Thank you > > 3- recategorized the methods > > > 4- I removed all the "comment10" > Thanks again > > 5- what I level > Can you comment it? > It's commented now. Level represents the number of levels used to shows the list > > 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. > > I've changed the names. They return an association because they return the dictionary and the list sorted. I've choose this way because when i add referecens in the dictionary, the references are sorted alphabetically and so I lost the order :s > 7- Can you add oneline method comments to method? > I'm on o too > > > 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. > I do not understand ... > > 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 > I've removed this method > > 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]] > I've fixed that using Announcement MessageList >> updateView self triggerEvent: #changed MessageListBrowser >> messageList: anObject messageList := anObject. messageList when: #changed send: #updateView to: self. messageList when: #reset send: #delete to: self. > 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 > I used them to quickly have the MethodReference corresponding to a node. > > MethodReferenceWithSource > ------------------------ > We should probably move some behavior to MethodReference > I do not dare to change Pharo core alone ^^ > > NullTextStyler > ------------ > I categorized all the methods following SHStyler categories > Thank you :) > > 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. > Ok, now i used event too :) > > > Why the setting is registration is done in the core and not at the > level of the widget? > It's just easier to write in RecentMessageList self openInWorld than to write in MessageListBrowser on: RecentMesageList uniquInstance withADictionarySelector: RecentMessageList uniqueInstance sortingSelector > - at startUp: you should not create the instance since > uniqueInstance is lazzily accessed. > However you should register to the SystemChangeNotifier to get the > notification. > It's done, i've implemented the RecentMessageList class >> event: method. > 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 > I do not understand :s > > > So for now this is enough :) > Cool :) Thank you and Guillermo Polito Ben Gofer new squeaksource: 'PharoTaskForces'; package: 'RecentSubmissions'; load.

Aug. 13, 2010

Re: [Pharo-users] RecentMessageList

by Benjamin Van Ryseghem

>From: Guillermo Polito <guillermopolito(a)gmail.com> > >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.. It does'nt seem to work on Pharo 1.2 but i fixed it with Announcement ^^ I've also improved the example. I'm still working on the code, I'll push a version this evening I think Ben

Aug. 13, 2010

Re: [Pharo-users] [SPAM] Re: WebClient

by Sven Van Caekenberghe

Well, I did some effort before and got Andreas to include a number of patches so that his WebClient-Core loaded into Pharo without a need for a compatibility layer. The lastest version does no longer have this property ;-) I again submitted some patches to Andreas ( http://forum.world.st/WebClient-Core-port-to-Pharo-1-1-final-td2322411.html… ) but he hasn't responded yet. Futhermore, I did not yet fix everything, but the code works for my purposes. As I discussed with StÃ©phane, it is not clear for me how this must go further, since we keep on running 'behind'. So it is good to discuss this here. Sven On 13 Aug 2010, at 17:24, Miguel Enrique CobÃ¡ MartÃnez wrote: > 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 > > > _______________________________________________ > 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