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

Re: [Pharo-project] Pharo XMLRPC Project

by Levente Uzonyi

On Sun, 19 Sep 2010, Guillermo Polito wrote: > :D Yay!! Where can I get a better explanation of the project? > > It will be nice to have a SOAP support in pharo (which doesn't exists I > think), and it should be veeeery useful! XML-RPC is not SOAP. Here is a SOAP client/server (IIRC Gjallar uses this): http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html Levente > > On Sun, Sep 19, 2010 at 6:09 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> wrote: > >> Good! >> The ESUG board decided to support german as originally mentioned >> so he should probably join your effort. >> >> >> Stef >> >>> Is there anything that is complete with respect to the XMLRPC Project..? >>> >>> Our notes: vibhu and I have put through the package ported from the >> available squeak work: >>> >>> http://skrishnamachari.wordpress.com/2010/09/19/pharo-xmlrpc-kick-start/ >>> >>> This is just the first shot at it.. >>> >>> Will come up with the ConfigurationOfXMLRPC shortly to bind the >> dependencies properly and fix anything that may required to take care of it >> as possible. >>> >>> -skrish >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Sept. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Guillermo Polito

+1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. Guille On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > wrote: > > Slow access can be a big problem. Any such change should be made based > on measurements so we know what benefit we get at what cost. > > > Yeah, it would be much easier to deal that line in Self or JavaScript, > where you can add any properties to object > on the fly, without need of adding a methods or declaring additional > instance variable in class... > > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [ > siguctua(a)gmail.com] > > Sent: Sunday, September 19, 2010 7:56 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] we need to find a way to declare that an > action is UIless > > > > On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> hi guys > >> > >> I tried to add borderStyle to BorderedMorph and the progressbar showing > the progress blow up. > >> So we should really have a way to specify silent ui action. > >> Does anybody have an idea how I could do that? > >> > >> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be > cool. > >> > > > > use morph propertyAt: #borderStyle > > so you don't have to break your head with it :) > > > > BorderedMorph having an enormous number of subclasses, while some of > > them even don't using any > > kind of borders. That's makes me wonder if anything like color, border > > style etc should belong to root classes > > in hierarchy, like Morph or BorderedMorph. I think that dynamic set of > > properties (which is currently sits in morphic > > extensions are more appropriate storage for them). The only problem is > > that accessing them is much slower than ivars. > > > >> Stef > >> _______________________________________________ > >> 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. > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] Pharo XMLRPC Project

by Guillermo Polito

:D Yay!! Where can I get a better explanation of the project? It will be nice to have a SOAP support in pharo (which doesn't exists I think), and it should be veeeery useful! On Sun, Sep 19, 2010 at 6:09 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Good! > The ESUG board decided to support german as originally mentioned > so he should probably join your effort. > > > Stef > > > Is there anything that is complete with respect to the XMLRPC Project..? > > > > Our notes: vibhu and I have put through the package ported from the > available squeak work: > > > > http://skrishnamachari.wordpress.com/2010/09/19/pharo-xmlrpc-kick-start/ > > > > This is just the first shot at it.. > > > > Will come up with the ConfigurationOfXMLRPC shortly to bind the > dependencies properly and fix anything that may required to take care of it > as possible. > > > > -skrish > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Igor Stasenko

On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Slow access can be a big problem. Â Any such change should be made based on measurements so we know what benefit we get at what cost. > Yeah, it would be much easier to deal that line in Self or JavaScript, where you can add any properties to object on the fly, without need of adding a methods or declaring additional instance variable in class... > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Sunday, September 19, 2010 7:56 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> hi guys >> >> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >> So we should really have a way to specify silent ui action. >> Does anybody have an idea how I could do that? >> >> Â Â Â Â [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >> > > use morph propertyAt: #borderStyle > so you don't have to break your head with it :) > > BorderedMorph having an enormous number of subclasses, while some of > them even don't using any > kind of borders. That's makes me wonder if anything like color, border > style etc should belong to root classes > in hierarchy, like Morph or BorderedMorph. I think that dynamic set of > properties (which is currently sits in morphic > extensions are more appropriate storage for them). The only problem is > that accessing them is much slower than ivars. > >> Stef >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > 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. 20, 2010

Re: [Pharo-project] about events :)

by Schwab,Wilhelm K

+10 - Weak subscriptions are a must. Absent that, we'll end up with bloated images and lots of unhappy users. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Sunday, September 19, 2010 8:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about events :) On 19 September 2010 16:42, Juan Vuletich <juan(a)jvuletich.org> wrote: > StÃ©phane Ducasse wrote: >> >> hi >> may be I'm wrong but I have the impression that we have around three >> different kinds of event system in the system >> >> - actionMap >> - announcement >> - changed: >> Could we simplify that? >> Stef >> > > Yes! Kill #changed: And if you adopt announcements, kill actionMap too! > amen. But we have to add weak subscriptions to announcements first, otherwise you won't be able to properly reimplement actionMap/changed: without that. I provided some code for that, but i'm not sure if it integrated into pharo yet. > Cheers, > Juan Vuletich > > _______________________________________________ > 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Sunday, September 19, 2010 7:56 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. > So we should really have a way to specify silent ui action. > Does anybody have an idea how I could do that? > > [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. > use morph propertyAt: #borderStyle so you don't have to break your head with it :) BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars. > Stef > _______________________________________________ > 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

Re: [Pharo-project] about events :)

by Igor Stasenko

On 19 September 2010 16:42, Juan Vuletich <juan(a)jvuletich.org> wrote: > StÃ©phane Ducasse wrote: >> >> hi >> may be I'm wrong but I have the impression that we have around three >> different kinds of event system in the system >> >> Â Â Â Â - actionMap >> Â Â Â Â - announcement >> Â Â Â Â - changed: >> Could we simplify that? >> Stef >> > > Yes! Kill #changed: And if you adopt announcements, kill actionMap too! > amen. But we have to add weak subscriptions to announcements first, otherwise you won't be able to properly reimplement actionMap/changed: without that. I provided some code for that, but i'm not sure if it integrated into pharo yet. > Cheers, > Juan Vuletich > > _______________________________________________ > 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. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Igor Stasenko

On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. > So we should really have a way to specify silent ui action. > Does anybody have an idea how I could do that? > > Â Â Â Â [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. > use morph propertyAt: #borderStyle so you don't have to break your head with it :) BorderedMorph having an enormous number of subclasses, while some of them even don't using any kind of borders. That's makes me wonder if anything like color, border style etc should belong to root classes in hierarchy, like Morph or BorderedMorph. I think that dynamic set of properties (which is currently sits in morphic extensions are more appropriate storage for them). The only problem is that accessing them is much slower than ivars. > Stef > _______________________________________________ > 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. 19, 2010

[Pharo-project] Pharocasts: Document with HelpSystem

by laurent laffont

You will learn how to: - write an HelpSystem book - use PackageAPIHelpBuilder to generate the API documentation of a package - create your own builder to dynamically create a documentation from the system Starting from now, no excuses to not write documentation ;) http://pharocasts.blogspot.com/2010/09/document-with-helpsystem.html Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

Sept. 19, 2010

Re: [Pharo-project] Morph selectors size - CUISMorph selectors size = 358

by StÃ©phane Ducasse

I thought so as well as eliot. Of course we will never blindly remove methods just because they are not invoked in the core image. Usually we analyze deeply what we remove - this is even one of our problem I would say :) > Stef, > > Ok. I'm in. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Sunday, September 19, 2010 2:31 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Morph selectors size - CUISMorph selectors size = 358 > > Another point I'm sorry but leaving in a unclean place is not my goal in life. We should integrate in our mind that until pharo is not clean, it will change at a rapid pace. I do not have 10 years for that - my life is too short. This is why we will get a new compiler with a new api and a lot of new things. > I imagine that in 2-3 years the situation will be different. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 19, 2010