- Pharo-dev - lists.pharo.org

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

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

by Schwab,Wilhelm K

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

Sept. 19, 2010

Re: [Pharo-project] RGB (0-255) image format?

by Schwab,Wilhelm K

The library assumes a 24 bit layout; unless I want to edit/recompile it, I have no say in that. The best I have been able to find is to let it do its thing and then expand the result into what Pharo uses for a 32 bit layout; I take that to be adding an alpha bit to each pixel?? ------------------------------------------- Javier DÃaz Reinoso javier_diaz_r at mac.com Sun Sep 19 18:16:23 UTC 2010 You need to browse the Graphics-File category, there you can found how the different formats are read/write from files to memory. A better name for ColorForm should be IndexedColorForm: 8 bit index into a palette of colors, used also for 8 bit gray images. If you have RBG you need to use 32 (or 16) bit Forms. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Sunday, September 19, 2010 1:49 PM To: Pharo-project(a)lists.gforge.inria.fr; squeak-dev(a)lists.squeakfoundation.org Subject: Re: [Pharo-project] RGB (0-255) image format? Some searching did not turn up an answer, but I might be able to let the library "think" in 24 bbp, and then use a C function to expand the result into 32 bbp for Pharo. Would the alpha value be 255?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Sunday, September 19, 2010 10:55 AM To: Pharo-project(a)lists.gforge.inria.fr; squeak-dev(a)lists.squeakfoundation.org Subject: [Pharo-project] RGB (0-255) image format? Is there a clever and fast way to turn an array of RGB triads (each slot taking on uint8 values from 0-255) into a Form, or better yet treat it directly as a Form? If I understand ColorForm correctly, it uses a map and the image "pixels" are indexes into same. In this case, I would allocate a block of memory, hand it to a library, and it would blast the RGB values all over it. Do we have a ready way to use the result w/o having to loop over the individual values? I am working on an interface to PLplot (http://plplot.sourceforge.net/) It is working, but so far only if I save files to disk, which I would like to not *have* to do. Sometimes (batches in particular), it makes sense to let the code that creates a graph save it, but I also like to do a lot of interactive plotting that should not have to hit the disk. Bill _______________________________________________ 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

Re: [Pharo-project] MethodName is now Finder

by StÃ©phane Ducasse

cool :) Stef On Sep 19, 2010, at 8:53 PM, Benjamin Van Ryseghem wrote: > I've fix some bug and discover how to script packages loading ^^ > > Now, just run > > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'ConfigurationOfFinder'; > load > > ConfigurationOfFinder loadDefault > > > > > Ben > _______________________________________________ > 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