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

[Pharo-project] Fame vs Magritte

by FranÃ§ois Tanguy

Hi, being a end user, I am bit confused with these 2 frameworks: Fame and Magritte. There are both meta-meta-models. So what make them different from a conceptual point of view ? For my models, I would like to have the persistency for free (from Fame) and the UI edition and model validation for free (from Magritte). Today I must write two times the description of my language (one in Fame and one in Magritte), and it feels like I would need only one description. Any info on this would be appreciated. Thanks. Francois

Sept. 25, 2010

[Pharo-project] FluidDB API for Pharo

by Sven Van Caekenberghe

On 25 Sep 2010, at 10:22, Jordi Delgado wrote: > Hi > > I write just to let you know that we (the smalltalk.cat group) did an > API to interact with a nice no-SQL database called FluidDB. It has been > mainly the work of Sergio Garcia, but there is a little of some of us in the > tests and the code: > http://www.squeaksource.com/FluidDB.html > To see what this FluidDB is: > http://fluidinfo.com/ > > Bests, > > Jordi Sounds interesting, however the SqueakSource project has a 'Global: no access', so we can't see anything. Sven

Sept. 25, 2010

[Pharo-project] FluidDB API for Pharo

by Jordi Delgado

Hi I write just to let you know that we (the smalltalk.cat group) did an API to interact with a nice no-SQL database called FluidDB. It has been mainly the work of Sergio Garcia, but there is a little of some of us in the tests and the code: http://www.squeaksource.com/FluidDB.html To see what this FluidDB is: http://fluidinfo.com/ Bests, Jordi

Sept. 25, 2010

Re: [Pharo-project] Zinc HTTP Components

by Sven Van Caekenberghe

Matt, On 24 Sep 2010, at 21:02, Matt Kennedy wrote: > Hi Sven, > > I am interested mostly in the client side right now and will take up your suggestion of implementing a new client within the Zn components. The client I started a couple days ago subclassed ProtocolClient and I can lift stuff I did from that client for a new Zn client. My current client had cookie handling, chunked encoding, and configurable automatic redirect handling. I myself am not so much interested in keep alive connection reuse, though it'd certainly have some use. My main goals for a client library are to support persistent client sessions, pluggable authentication, and easy header control, which are things I've found lacking when trying to implement some web APIs using HTTPSocket. Sounds really interesting, I am looking forward at seeing your code! Sven > I am on the Pharo-project list and squeak-dev currently. I'll make sure I'm on all the pharo lists so future discussions can happen openly there. > > Matt > > On Sep 24, 2010, at 1:47 PM, Sven Van Caekenberghe wrote: > >> Hi Matt, >> >> On 24 Sep 2010, at 18:01, Matt Kennedy wrote: >> >>> Hi, >>> >>> I wanted to write and thank you for the work you've done here with your library. I just recently started this week on working on a replacement for HTTPSocket because I wanted to implement OAuth for Pharo and HTTPSocket just doesn't cut it. You've got a nice bundle packaged up and are a lot farther along, so I'd much rather support your work. >>> >>> My question for you is how much of the client code from the Old collection of packages are you planning on refactoring into the New packages? I'd like to work on bringing over the session and cookie code and instance side methods of ZnHTTPClient over in order to support making multiple requests from a single client instance and work on an OAuth authenticator, which is what got me started on this road to begin with. >>> >>> Regards, >>> Matt Kennedy >> >> Thanks for your interest. I presume you have read the project's main page and getting started guide, especially the Status, Todo & Future sections. Those should answer most of your questions. >> >> Now, basic Cookie support should be a standalone class or two (ZnCookie, ZnCookieJar). The exesting ones are not that clean, if you know the subject, you could do that from scratch. This is not something that I would do first. >> >> Although the current (server side) authenticator is pluggable, it is hardwired for basic authentication. Obviously there are other authentication schemes. So authenticator should become a more intelligent object that does what ZnServer>>#authenticateRequest:do: now does. I could do the refactoring (server side) with an abstract superclass and basic authentication as concrete subclass. I don't know if server and client side are unifyable. >> >> If you are mostly interested in the client side, I would suggest that you try to write your own client, separate from the current one (ZnClient is only a very simple class side collection of utilities). One of the first things I wanted to do next was a client that reuses connections (as well as chunked and gzip encoded transfers). Reusing connections is actually a pretty special case when you keep on hitting one server very frequently, otherwise the reuse effort is not worth the trouble (re-establising connections) - that is what I found in other HTTP clients that I wrote. What do you think ? >> >> I am not familiar with OAuth, I just heard about it, something like that would be most interesting. But maybe this could be an add-on package, I don't known how elaborate it is ? >> >> BTW, are you on Pharo ? I would like to have discussions like this openly on the pharo dev list. >> >> Sven >

Sept. 25, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Hannes Hirzel

Thanks, Igor Two questions. 1) I have not been following closely the Pharo development. Does Pharo rely mainly on Announcements (Event objects) for Morphic GUI code these days? MCHttpRepository location: 'http://source.lukas-renggli.ch/announcements' user: '' password: '' 2) I found How Morphic processes events http://wiki.squeak.org/squeak/118 written by Andreas Raab in 2003 Could somebody have a quick look at it and tell me if this still more or less applies to the current Squeak and Pharo implementations? Where do I find a description how Pharo handles Morphic events these days? --Hannes On 9/25/10, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: >> On 9/24/10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> >>> Hannes Hirzel-2 wrote: >>>> >>>>> I tried (one of these felt very satisfying): >>>>> * Morph>>on:send:to:, which sounded good, but never got called >>>>> * intercepting Morph>>processEvent:using: (which I was told was not a >>>>> good >>>>> idea) >>>>> * (after seeking help), locking the submorphs and overriding the dozen >>>>> or >>>>> so >>>>> event-related methods in the chain from my morph to TextMorphForShout >>>>> (the >>>>> Morph that actually handles the text and input). >>>>> * subclassing TextMorphForShout and then subclassing >>>>> PluggableShoutMorph >>>>> to >>>>> use that subclass. >>>> >>>> Which method did you like best? >>>> >>> >>> Ha ha, should have been *none of these felt...*, but: >> >>> 1. The on:send:to: was what I /wanted/ to do, with the downside being >>> that >>> it did nothing, lol. >> >>> 2. The intercept of Morph>>processEvent:using: was okay, but dangerous >>> because it's easy to lock the image when messing with this. >> >>> 3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very >>> heavy >>> weight for listening in on one event. Â IOW I may have gone that route >>> eventually if the behavior got complex, but didn't like being chained to >>> it >>> for my simple case. >>> >>> >>> Hannes Hirzel-2 wrote: >>>> >>>> There are some notes on this issue at >>>> http://wiki.squeak.org/squeak/2477 >>>> ( Eddie Cottongim writes: I know of three main ways to handle events >>>> in Morphic.......) >>>> >>> Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler >>> >>> >>> Hannes Hirzel-2 wrote: >>>> >>>> Conclusion: It might be worthwile to find out more how Juan has pruned >>>> Morphic in Cuis and if it is still valuable for use, document that and >>>> put it to use in Squeak and Pharo. >>>> >>> Cool, I've started this as well. Â Let's keep the list posted if we come >>> up >>> with anything. >>> >>> Sean >> >> >> >> >>> p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start >>> another >>> thread. >> >> Juan has in Cuis 2.6 >> >> Morph >> >> on: eventName send: selector to: recipient >> > i saw such message pattern. Guess where? > Announcements! :) > > announcer on: MyAnnouncement send: #foo to: bar > >> Â Â Â Â self flag: #jmv. >> Â Â Â Â "Do NOT implement EventHandler in Morphic 3 or LightWidgets. >> Â Â Â Â Even more. Try to avoid all the stuff in Morphic-OldEvents" >> >> Â Â Â Â self eventHandler ifNil: [self eventHandler: EventHandler new]. >> Â Â Â Â self eventHandler on: eventName send: selector to: recipient >> >> >> So the best thing as of now would be to remove this in Squeak and >> Pharo so that the next people who analyze this do not loose time with >> it and can advance more with the things which work..... >> > > The dichotomy here is , that Morph from one side acts as an event recipient, > but from another side, it acts as an events source for eventHandler. > (as far as i can tell, this is an intent of introducing EventHandler). > > This could be managed in more gracious manner, by having a single > entry point for all events, > which coming to morph. Then you can write: > > singleEntryPointForAllEvents: anEvent > self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent > fromMorph: self ]. > self handleEvent: anEvent > > and get rid of repetituous code from all places, like: > > keyStroke: anEvent > "Handle a keystroke event. The default response is to let my > eventHandler, if any, handle it." > > self eventHandler ifNotNil: > [self eventHandler keyStroke: anEvent fromMorph: self]. > > >> HJH >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Sept. 25, 2010

Re: [Pharo-project] Webpage for research paper about Pharo?

by StÃ©phane Ducasse

guys all my papers are using Smalltalk (visualworks, squeak mainly so far) as a research vehicule. You can use them to do marketing around smalltalk because there are good papers in prestigious venues. Please do not have the time. Now pharo has the right to mention the papers using pharo on the pharo web site. Stef On Sep 25, 2010, at 12:20 AM, Sean P. DeNigris wrote: > > How about putting the papers on both sites ;-) > > Sean > -- > View this message in context: http://forum.world.st/Webpage-for-research-paper-about-Pharo-tp2549096p2606… > 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

Sept. 25, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Igor Stasenko

On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 9/24/10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> >> Hannes Hirzel-2 wrote: >>> >>>> I tried (one of these felt very satisfying): >>>> * Morph>>on:send:to:, which sounded good, but never got called >>>> * intercepting Morph>>processEvent:using: (which I was told was not a >>>> good >>>> idea) >>>> * (after seeking help), locking the submorphs and overriding the dozen or >>>> so >>>> event-related methods in the chain from my morph to TextMorphForShout >>>> (the >>>> Morph that actually handles the text and input). >>>> * subclassing TextMorphForShout and then subclassing PluggableShoutMorph >>>> to >>>> use that subclass. >>> >>> Which method did you like best? >>> >> >> Ha ha, should have been *none of these felt...*, but: > >> 1. The on:send:to: was what I /wanted/ to do, with the downside being that >> it did nothing, lol. > >> 2. The intercept of Morph>>processEvent:using: was okay, but dangerous >> because it's easy to lock the image when messing with this. > >> 3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy >> weight for listening in on one event. Â IOW I may have gone that route >> eventually if the behavior got complex, but didn't like being chained to it >> for my simple case. >> >> >> Hannes Hirzel-2 wrote: >>> >>> There are some notes on this issue at >>> http://wiki.squeak.org/squeak/2477 >>> ( Eddie Cottongim writes: I know of three main ways to handle events >>> in Morphic.......) >>> >> Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler >> >> >> Hannes Hirzel-2 wrote: >>> >>> Conclusion: It might be worthwile to find out more how Juan has pruned >>> Morphic in Cuis and if it is still valuable for use, document that and >>> put it to use in Squeak and Pharo. >>> >> Cool, I've started this as well. Â Let's keep the list posted if we come up >> with anything. >> >> Sean > > > > >> p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start another >> thread. > > Juan has in Cuis 2.6 > > Morph > > on: eventName send: selector to: recipient > i saw such message pattern. Guess where? Announcements! :) announcer on: MyAnnouncement send: #foo to: bar > Â Â Â Â self flag: #jmv. > Â Â Â Â "Do NOT implement EventHandler in Morphic 3 or LightWidgets. > Â Â Â Â Even more. Try to avoid all the stuff in Morphic-OldEvents" > > Â Â Â Â self eventHandler ifNil: [self eventHandler: EventHandler new]. > Â Â Â Â self eventHandler on: eventName send: selector to: recipient > > > So the best thing as of now would be to remove this in Squeak and > Pharo so that the next people who analyze this do not loose time with > it and can advance more with the things which work..... > The dichotomy here is , that Morph from one side acts as an event recipient, but from another side, it acts as an events source for eventHandler. (as far as i can tell, this is an intent of introducing EventHandler). This could be managed in more gracious manner, by having a single entry point for all events, which coming to morph. Then you can write: singleEntryPointForAllEvents: anEvent self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent fromMorph: self ]. self handleEvent: anEvent and get rid of repetituous code from all places, like: keyStroke: anEvent "Handle a keystroke event. The default response is to let my eventHandler, if any, handle it." self eventHandler ifNotNil: [self eventHandler keyStroke: anEvent fromMorph: self]. > HJH > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 25, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Hannes Hirzel

On 9/24/10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Hannes Hirzel-2 wrote: >> >>> I tried (one of these felt very satisfying): >>> * Morph>>on:send:to:, which sounded good, but never got called >>> * intercepting Morph>>processEvent:using: (which I was told was not a >>> good >>> idea) >>> * (after seeking help), locking the submorphs and overriding the dozen or >>> so >>> event-related methods in the chain from my morph to TextMorphForShout >>> (the >>> Morph that actually handles the text and input). >>> * subclassing TextMorphForShout and then subclassing PluggableShoutMorph >>> to >>> use that subclass. >> >> Which method did you like best? >> > > Ha ha, should have been *none of these felt...*, but: > 1. The on:send:to: was what I /wanted/ to do, with the downside being that > it did nothing, lol. > 2. The intercept of Morph>>processEvent:using: was okay, but dangerous > because it's easy to lock the image when messing with this. > 3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy > weight for listening in on one event. IOW I may have gone that route > eventually if the behavior got complex, but didn't like being chained to it > for my simple case. > > > Hannes Hirzel-2 wrote: >> >> There are some notes on this issue at >> http://wiki.squeak.org/squeak/2477 >> ( Eddie Cottongim writes: I know of three main ways to handle events >> in Morphic.......) >> > Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler > > > Hannes Hirzel-2 wrote: >> >> Conclusion: It might be worthwile to find out more how Juan has pruned >> Morphic in Cuis and if it is still valuable for use, document that and >> put it to use in Squeak and Pharo. >> > Cool, I've started this as well. Let's keep the list posted if we come up > with anything. > > Sean > p.s. #1 seems to be broken in Squeak and Pharo. I'm going to start another > thread. Juan has in Cuis 2.6 Morph on: eventName send: selector to: recipient self flag: #jmv. "Do NOT implement EventHandler in Morphic 3 or LightWidgets. Even more. Try to avoid all the stuff in Morphic-OldEvents" self eventHandler ifNil: [self eventHandler: EventHandler new]. self eventHandler on: eventName send: selector to: recipient So the best thing as of now would be to remove this in Squeak and Pharo so that the next people who analyze this do not loose time with it and can advance more with the things which work..... HJH

Sept. 25, 2010

[Pharo-project] Smalltalk memoryHogs

by Igor Stasenko

Just some thoughts... Magma registers own entities as a memory hog, using (Smalltalk memoryHogs add: ...) and then if error happens (because i experimenting with it), i have a reference handling, and i need to cast weird incarnations to get rid of it. What i thinking , that memoryHogs should be not just simple OrderedCollection, but WeakArray instead. Then it won't keep hanging references, and don't force to remove them manually. But the problem is, that its implementation: memoryHogs "Answer the list of objects to notify with #freeSomeSpace if memory gets full." ^ MemoryHogs ifNil: [MemoryHogs := OrderedCollection new] means that any user could send #add: or #remove: at any time. So, i can't replace OrderedCollection with just WeakArray, because it will break the users of this message. :( So, i think that memoryHogs should be deprecated and instead, and we should provide #registerMemoryHog: and #unregisterMemoryHog then we are free to use something else than OrderedCollection. -- Best regards, Igor Stasenko AKA sig.

Sept. 25, 2010

Re: [Pharo-project] Morphic

by Sean P. DeNigris

This thread is about Morphic and how we can make it great. Please move any other topics (e.g. Squeak vs. Pharo, and why one would use one or the other) off my thread. Have a nice day :) Thanks. Sean -- View this message in context: http://forum.world.st/Morphic-tp2544184p2609146.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 24, 2010