April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2176 in pharo: Integrated DirectoryEntry>>attributes

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #4 on issue 2176 by marcus.d...(a)gmail.com: Integrated DirectoryEntry>>attributes http://code.google.com/p/pharo/issues/detail?id=2176 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 1907 in pharo: Set with nil

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #23 on issue 1907 by marcus.d...(a)gmail.com: Set with nil http://code.google.com/p/pharo/issues/detail?id=1907 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Metacello chapter

by Serge Stinckwich

Yes this is usual way to propose changes with github. On Thu, Apr 7, 2011 at 7:59 PM, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > I don't know how other authors work. > Not having write access to the repo, I have to fork, make my changes and then ask the admin of the repo (you + who else) to pull (=> merge) changes I made. > > Noury > On 7 avr. 2011, at 09:18, StÃ©phane Ducasse wrote: > >> and so what? I still do not understand it. >> may be noury should be added to the project. >> >> >> On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote: >> >>> https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3 >>> >>> On Thu, Apr 7, 2011 at 3:10 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>>> Cool. BTW, I have a pending pull request on the Socket chapter. >>>> >>>> what is it? >>>> what do you mean? >>>> what do you need? >>>> >>>> Stef >>>> >>>> >>> >>> >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> Every DSL ends up being Smalltalk >>> http://doesnotunderstand.org/ >> >> > > Noury Bouraqadi > http://car.mines-douai.fr/noury > -- > -6th National Conference on > âControl Architecture of Robotsâ > 24-25 may 2011, Grenoble area, France > http://car2011.inrialpes.fr/ > > -19th ESUG International Smalltalk Conference > 22-26 August 2011, Edinburgh, UK > http://www.esug.org/Conferences/2011 > > -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) > http://www.univ-valenciennes.fr/congres/jfsma2011/ > 17-19 Octobre 2011, Valenciennes, France > > > > > > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 7, 2011

Re: [Pharo-project] Decode url form with Zinc-HTTP

by HernÃ¡n Morales Durand

One more thing, I've tried to install in the new released Pharo with CogVM: Gofer new squeaksource: 'ZincHTTPComponents'; package: 'ConfigurationOfZincHTTPComponents'; load. (Smalltalk at: #ConfigurationOfZincHTTPComponents) perform: #load and loading manually the latest Zinc-HTTP from the Monticello Browser. either way I get errors (attached debugger output from the ConfigurationOf script). What is the proper way to install or update to the latest version, Cheers, 2011/4/7 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Cool. Thanks Sven! > > 2011/4/7 Sven Van Caekenberghe <sven(a)beta9.be>: >> HernÃ¡n, >> >> From the class comment of ZnUrl: >> >> [...] >> >> Â Â Â Â The methods in accessing protocols do not do any encoding, those in printing do. >> >> [...] >> >> Taking your example: >> >> Â (ZnUrl fromString: >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') pathSegments >> >> Â Â Â Â an OrderedCollection('entrez' 'eutils' 'esearch.fcgi?db=nuccore&term=science[journal]+AND+breast+cancer+AND+2009[pdat]') >> >> (ZnUrl fromString: >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') path >> >> Â Â Â Â 'entrez/eutils/esearch.fcgi?db=nuccore&term=science[journal]+AND+breast+cancer+AND+2009[pdat]' >> >> (ZnUrl fromString: >> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') printString >> >> Â Â Â Â 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >> >> If you inspect a ZnUrl instance you will notice that the internal Smalltalk representation is unencoded. But its #printString and the argument to #fromString: are. You could programmatically build up a ZnUrl using accessors and supplying unencoded (path) elements. >> >> HTH, >> >> Sven >> >> On 06 Apr 2011, at 22:38, HernÃ¡n Morales Durand wrote: >> >>> Hi Sven, >>> >>> In WebUtils one can decode an URL this way >>> >>> ( WebUtils decodeUrlEncodedForm: >>> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >>> ) keys anyOne >>> >>> resulting in >>> >>> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=nuccore&term=s…' >>> >>> In Zinc-HTTP I didn't find a method for decoding an encoded HTTP address: >>> >>> ( ZnUrl fromString: >>> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >>> ) .... ? >>> >>> but there is #unescapePercents in Network package (by the way if it's >>> the opposite of #encodeForHTTP shouldn't be #decodeFromHTTP ?) >>> >>> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' >>> unescapePercents >>> >>> 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=nuccore&term=s…' >>> >>> but I want to maximize package dependency and not system dependency. >>> Is there a way to decode url's in Zinc-HTTP without use >>> #unescapePercents ? >>> >>> Cheers, >>> >>> -- >>> HernÃ¡n Morales >>> Information Technology Manager, >>> Institute of Veterinary Genetics. >>> National Scientific and Technical Research Council (CONICET). >>> La Plata (1900), Buenos Aires, Argentina. >>> Telephone: +54 (0221) 421-1799. >>> Internal: 422 >>> Fax: 425-7980 or 421-1799. >>

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by Miguel CobÃ¡

El miÃ©, 06-04-2011 a las 19:48 -0700, Randal L. Schwartz escribiÃ³: > >>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > > Serge> On Thu, Apr 7, 2011 at 9:38 AM, Randal L. Schwartz > Serge> <merlyn(a)stonehenge.com> wrote: > >>>>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > >> > Serge> Yes, but this SmalltalkHub not PharoHub ;-) > >> > >> Oh, did I miss the parallel announcement on squeak-dev? Sorry. > > Serge> There was no announcement on squeak-dev. > Serge> Nicolas forget about that i guess. > > OK, so if this is a general replacement for Squeaksource, the "tagging" > issue comes up again. How do we identify which branch of Squeak a > package might be for? And can we maintain forks for those things that > require it? Isn't the responsibility of the repository. The repository only stores code. Just like svn or github. You can use other features to "emulate" and adapt it to your needs (like the tags) but that isn't a feature of the repo. Indeed is the task of the maintainer of the code to mark some versions as tested and ok on some versions of Squeak or Pharo. Currently, in Pharo, that job is done in Metacello configurations. Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by Miguel CobÃ¡

El miÃ©, 06-04-2011 a las 19:38 -0700, Randal L. Schwartz escribiÃ³: > >>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > > Serge> Yes, but this SmalltalkHub not PharoHub ;-) > > Oh, did I miss the parallel announcement on squeak-dev? Sorry. That is because there isn't an announcement yet. It only mentioned that a beta could be made available next week. I suppose that then an announcement will be made. -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 7, 2011

Re: [Pharo-project] Metacello chapter

by Miguel CobÃ¡

El jue, 07-04-2011 a las 14:59 +0200, Noury Bouraqadi escribiÃ³: > I don't know how other authors work. > Not having write access to the repo, I have to fork, make my changes and then ask the admin of the repo (you + who else) to pull (=> merge) changes I made. Indeed, that is the recommended way to work in open source projects on GitHub. Cheers > > Noury > On 7 avr. 2011, at 09:18, StÃ©phane Ducasse wrote: > > > and so what? I still do not understand it. > > may be noury should be added to the project. > > > > > > On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote: > > > >> https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3 > >> > >> On Thu, Apr 7, 2011 at 3:10 AM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>>> Cool. BTW, I have a pending pull request on the Socket chapter. > >>> > >>> what is it? > >>> what do you mean? > >>> what do you need? > >>> > >>> Stef > >>> > >>> > >> > >> > >> > >> -- > >> Serge Stinckwich > >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > >> Every DSL ends up being Smalltalk > >> http://doesnotunderstand.org/ > > > > > > Noury Bouraqadi > http://car.mines-douai.fr/noury > -- > -6th National Conference on > âControl Architecture of Robotsâ > 24-25 may 2011, Grenoble area, France > http://car2011.inrialpes.fr/ > > -19th ESUG International Smalltalk Conference > 22-26 August 2011, Edinburgh, UK > http://www.esug.org/Conferences/2011 > > -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) > http://www.univ-valenciennes.fr/congres/jfsma2011/ > 17-19 Octobre 2011, Valenciennes, France > > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 7, 2011

Re: [Pharo-project] Metacello chapter

by Miguel CobÃ¡

El jue, 07-04-2011 a las 09:18 +0200, StÃ©phane Ducasse escribiÃ³: > and so what? I still do not understand it. > may be noury should be added to the project. A pull is a notice to the original author (whose code the contributor is forking and modifying) to indicate that some changes are made parting from some point in time (the time of forking). Github permits the original author to review the changes and apply them to its own "official" codebase, therefore integrating contributions from others. The nice thing is that everyone can modify what he wants but the original author is the one that takes what it appears good to him for integrating in the official codebase. There is no need to add more people to a "project" because everyone can have its own copy of the project and only share the changes as needed. Cheers > > > On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote: > > > https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3 > > > > On Thu, Apr 7, 2011 at 3:10 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >>> Cool. BTW, I have a pending pull request on the Socket chapter. > >> > >> what is it? > >> what do you mean? > >> what do you need? > >> > >> Stef > >> > >> > > > > > > > > -- > > Serge Stinckwich > > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > > Every DSL ends up being Smalltalk > > http://doesnotunderstand.org/ > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 7, 2011

Re: [Pharo-project] An idea about Pluggable widgets

by Igor Stasenko

On 7 April 2011 16:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I'm using a similar approach for Mars. > Views in Mars always consume from a similar structure and we have the concept of "model adaptor" when you need to adapt from your model to the views. We also have a couple of generic adaptors who adapts nicely to your model. > Let's say we need to place a string into a MRLabel, and model for label is prepared to understand #content message. > so you say something like this: > > Â Â Â Â MRLabel new > Â Â Â Â Â Â Â Â model: ('My label' adaptAccessor: #yourself); > Â Â Â Â Â Â Â Â ...etc... > > and that way you have "cleanness" in both sides :) > > other problems is when widgets triggers events (like your example, a button click, named performAction). > I think here you should not trigger anything but an announcement. > Your performAction should look more like: > > performAction > Â Â Â Â self announce: ButtonPressed > > and your "client code" should look: > > MRButton new > Â Â Â Â on: ButtonPressed do: [ ... whatever... ] > > > So, summarizing.... I "more or less" agree with your approach. Or better I mean: I agree in the "accessing" part, but I would like using announcements to trigger events. Yes, but that is another step , another milestone. If you do it gradually, first you clean the mess out, and then introduce announcements, otherwise you have good chances to not deliver, because for announcements you need to use different api and rewrite things everywhere. While model adaptors (i like the naming btw) could be introduced seamlessly without breaking existing code that much. -- Best regards, Igor Stasenko AKA sig.

April 7, 2011

Re: [Pharo-project] An idea about Pluggable widgets

by Esteban Lorenzano

I'm using a similar approach for Mars. Views in Mars always consume from a similar structure and we have the concept of "model adaptor" when you need to adapt from your model to the views. We also have a couple of generic adaptors who adapts nicely to your model. Let's say we need to place a string into a MRLabel, and model for label is prepared to understand #content message. so you say something like this: MRLabel new model: ('My label' adaptAccessor: #yourself); ...etc... and that way you have "cleanness" in both sides :) other problems is when widgets triggers events (like your example, a button click, named performAction). I think here you should not trigger anything but an announcement. Your performAction should look more like: performAction self announce: ButtonPressed and your "client code" should look: MRButton new on: ButtonPressed do: [ ... whatever... ] So, summarizing.... I "more or less" agree with your approach. Or better I mean: I agree in the "accessing" part, but I would like using announcements to trigger events. cheers, Esteban El 07/04/2011, a las 10:26a.m., Igor Stasenko escribiÃ³: > I have an idea how to refactor the pluggable morphs mess. > > The main principle behind all pluggables, that you have a model (which > is held in instance variable), > and then morph having additional ivars to speak with this model, which > the selector names you should use > to access certain state from model. > > For example: > > AlignmentMorph subclass: #PluggableButtonMorph > instanceVariableNames: 'model label getStateSelector actionSelector > getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging > triggerOnMouseDown offColor onColor feedbackColor > showSelectionFeedback allButtons arguments argumentsProvider > argumentsSelector gradientLook enabled actionBlock getColorSelector > getEnabledSelector' > classVariableNames: 'UseGradientLook' > poolDictionaries: '' > category: 'Morphic-Pluggable Widgets' > > > as you can see it is crowded with all those ivars, where part of them > used to speak with model, > and part of them used for keeping flags and additional parameters > which you can customize when creating a button. > getStateSelector actionSelector getLabelSelector getMenuSelector > arguments argumentsProvider argumentsSelector gradientLook > actionBlock getColorSelector getEnabledSelector > > and this is really messy.. > Take a look at code: > > performAction > "Inform the model that this button has been pressed. Sent by the > controller when this button is pressed. If the button's actionSelector > takes any arguments, they are obtained dynamically by sending the > argumentSelector to the argumentsProvider" > > enabled ifFalse: [^self]. > askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]]. > self actionBlock ifNotNil: [ ^ self actionBlock value]. > actionSelector ifNotNil: > [actionSelector numArgs == 0 > ifTrue: [model perform: actionSelector] > ifFalse: > [argumentsProvider ifNotNil: > [arguments := argumentsProvider perform: argumentsSelector]. > model perform: actionSelector withArguments: arguments]] > > > Now think if we could replace this with simple: > > > performAction > "Inform the model that this button has been pressed. Sent by the > controller when this button is pressed. If the button's actionSelector > takes any arguments, they are obtained dynamically by sending the > argumentSelector to the argumentsProvider" > > enabled ifFalse: [^self]. > model performAction. > > > so, in this case, we just put an obligation onto model to perform any > action in response to button clicked, > and button no longer cares about crappy logic how it should send a > message to model > (via action block, via actionSelector ... and whether it should pass > any additional arguments or not..) > > So, in all places which using things in a way like: > > getListItems > ^ model perform: getListItemsSelector > > now will be replaced with clean: > > getListItems > ^ model getListItems > > So, a pluggable morph no longer cares about keeping all those > selectors and maintain an obscure logic whether selector is nil or not > nil etc etc.. > Let model handle it! > > Then you may ask, what if i have a model, which doesn't implements > such protocol (required for specific pluggable widget). > The answer is simple: > - create a pluggable model class for given widget, which wraps around > your object and can keeps all those messy 'getLabelSelector' > 'getMenuSelector' , > inside and mediates between your model and widget. > > The benefit of it that widgets code will be much more cleaner. > And another benefit is that you know what exact protocol is needed if > you want to use your object as a model to given widget (list, button > etc). > And in most of the cases, you don't need to use this messy > 'getXYZSelector', because you can simply answer to messages sent by > widget and provide > necessary data. > But if you wanna go messy, you just use wrapper model, which contains > all those 'getXYZSelectors' which you can set to whatever you like. > > -- > Best regards, > Igor Stasenko AKA sig. >

April 7, 2011