- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Manuia Memory Monitor

by Alexandre Bergel

> Works just fine not loading the entire Spy/Mondrian packages as well... > > Personally I'd really like to see something like this, combined with some of the textual data from Debug -> VM Statistics + Space left as a core tool. :) Yep. Gofer new squeaksource: 'MemoryMonitor'; package: 'ConfigurationOfMemoryMonitor'; load. ((Smalltalk at: #ConfigurationOfMemoryMonitor) project perform: #lastVersion) load. It just loads 6 small classes. Accessible under the "World/Tools/Memory Monitor" menu item. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 31, 2010

Re: [Pharo-project] Rome/Athens notes

by Tudor Girba

Hi Igor, Thanks for investing time into this. I do not have much knowledge in this area, nor any free time at the moment, but I would gladly try to test. Cheers, Doru On 30 May 2010, at 23:34, Igor Stasenko wrote: > On 31 May 2010 00:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: >> >> On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: >> >>> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> cool post >>>> >>> >>> Yeah, these things are quite interesting. Except that not much >>> people >>> actually interested in it :) >> >> I do not think so. >> Good posts are read more that you believe. Now in mailing-list the >> numbers of mails >> cut the knowledge after a point. >> > > But i posted here mainly to discuss these ideas. If we don't have a > discussion, then we > won't have a resolution, and its not matters how good post is or > not, because > a true value of any idea can be determined by considering all > alternatives and > discussing them. > But maybe i'm a bit too hurry , because you mentioned that first > things which > needs to be done is to make current stuff working. > The other thing is, that i am writing GL stuff from scratch (mostly), > so i tend to pay more attention > on design first, and then on implementation. > >>> Here's another thing, which can be done right (if we want). >>> >>> Rome/OpenVG Paths is actually nothing else than a special kind of >>> more >>> general thing - shape. >>> >>> So, at very basis, we should have only two components for painting: >>> shape and paint. >>> And in fact we need to support only a single operation: fill the >>> shape >>> with given paint. >>> (The path stroke could be seen as a special kind of fill) >>> >>> >>> So the question is: Really. Why we should constrain ourselves with >>> specific things >>> from a very starting, by cutting out a most basic (and abstact >>> ideas) behind? >>> >>> There are infinite number of ways, how one could define a shape. >>> While paths is only a small, yet effective representation of shapes. >>> In same way there are infinite number of ways how one could define >>> a paint. >>> >>> Then this looks like a strong basis for building-up a powerful & >>> flexible graphics engine :) >> >> I do not know. Do the other frameworks outside smalltalk use >> something else >> than paths? > > Yes. In 3D you have meshes, NURB surfaces , constructive-solid > geometry > and tons of other stuff. > > >> I think that we should start >> - making rome working. We are nearly there >> - test it >> - refactor it. >> - I would like to see the canvas for morphic30 too. >> - refactor the system to use that. >> stef >> > Yes. Yes. Yes :) > >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Being happy is a matter of choice."

May 31, 2010

Re: [Pharo-project] Rome/Athens notes

by Tudor Girba

Hi Igor, Thanks for investing time into this. I do not have much knowledge in this area, nor any free time at the moment, but I would gladly try to test. Cheers, Doru On 30 May 2010, at 23:34, Igor Stasenko wrote: > On 31 May 2010 00:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: >> >> On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: >> >>> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> cool post >>>> >>> >>> Yeah, these things are quite interesting. Except that not much >>> people >>> actually interested in it :) >> >> I do not think so. >> Good posts are read more that you believe. Now in mailing-list the >> numbers of mails >> cut the knowledge after a point. >> > > But i posted here mainly to discuss these ideas. If we don't have a > discussion, then we > won't have a resolution, and its not matters how good post is or > not, because > a true value of any idea can be determined by considering all > alternatives and > discussing them. > But maybe i'm a bit too hurry , because you mentioned that first > things which > needs to be done is to make current stuff working. > The other thing is, that i am writing GL stuff from scratch (mostly), > so i tend to pay more attention > on design first, and then on implementation. > >>> Here's another thing, which can be done right (if we want). >>> >>> Rome/OpenVG Paths is actually nothing else than a special kind of >>> more >>> general thing - shape. >>> >>> So, at very basis, we should have only two components for painting: >>> shape and paint. >>> And in fact we need to support only a single operation: fill the >>> shape >>> with given paint. >>> (The path stroke could be seen as a special kind of fill) >>> >>> >>> So the question is: Really. Why we should constrain ourselves with >>> specific things >>> from a very starting, by cutting out a most basic (and abstact >>> ideas) behind? >>> >>> There are infinite number of ways, how one could define a shape. >>> While paths is only a small, yet effective representation of shapes. >>> In same way there are infinite number of ways how one could define >>> a paint. >>> >>> Then this looks like a strong basis for building-up a powerful & >>> flexible graphics engine :) >> >> I do not know. Do the other frameworks outside smalltalk use >> something else >> than paths? > > Yes. In 3D you have meshes, NURB surfaces , constructive-solid > geometry > and tons of other stuff. > > >> I think that we should start >> - making rome working. We are nearly there >> - test it >> - refactor it. >> - I would like to see the canvas for morphic30 too. >> - refactor the system to use that. >> stef >> > Yes. Yes. Yes :) > >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Being happy is a matter of choice."

May 31, 2010

Re: [Pharo-project] Using WebClient

by GermÃ¡n Arduino

Talking of post method, I tried to capture it with Firebug to understand what data post with WebClient, but no way until now. Exist some trick to obtain the exact content of the data to post only debuggin the web page? Cheers. 2010/5/29 GermÃ¡n Arduino <garduino(a)gmail.com>: > I think that is a post method in this case, but can't make it work (yet). > > 2010/5/29 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> It's been a long time, but won't the button cause the browser to send a post or get (whichever action is specified in the form) to the server? Â It might be enough to decide the content of that and send it over the socket. Â I am probably thinking in CGI terms, which might not be what you need. >> >> >> ________________________________________ >> 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: Saturday, May 29, 2010 4:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Using WebClient >> >> if you get answers from squeak-dev let us know. >> >> >> Stef >> >> >> On May 29, 2010, at 10:02 PM, GermÃ¡n Arduino wrote: >> >>> Hi: >>> >>> I'm trying to automate some operations on a web page that requires >>> authentication. >>> >>> I managed to arrive to the form that I need to process, authenticated >>> without problems. >>> >>> But I can't figure out how to process the button (is a button of this type: >>> >>> <input class="lButton" style="" name="submit_search" >>> value="Create File" type="submit"> ) Â to execute the Create File action. >>> >>> The form have two dates (that I can calculate and fill in) but I can't >>> to imagine how to process the submit button programmatically. >>> >>> Any hint will be appreciated. >>> >>> Cheers. >>> >>> -- >>> ================================================= >>> GermÃ¡n S. Arduino Â <gsa @ arsol.net> Â Twitter: garduino >>> Arduino Software & Web Hosting Â http://www.arduinosoftware.com >>> PasswordsPro Â http://www.passwordspro.com >>> ================================================= >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > ================================================= > GermÃ¡n S. Arduino Â <gsa @ arsol.net> Â Twitter: garduino > Arduino Software & Web Hosting Â http://www.arduinosoftware.com > PasswordsPro Â http://www.passwordspro.com > ================================================= >

May 31, 2010

Re: [Pharo-project] Rome/Athens notes

by StÃ©phane Ducasse

cool I really want to see how we can get a nice momentum on that front :) Stef On May 31, 2010, at 4:45 PM, Juan Vuletich wrote: > Hi Stef, Igor, > > (copied Igor too) > > StÃ©phane Ducasse wrote: >> On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: >> >> >>> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> cool post >>>> >>>> >>> Yeah, these things are quite interesting. Except that not much people >>> actually interested in it :) >>> >> >> I do not think so. >> Good posts are read more that you believe. Now in mailing-list the numbers of mails >> cut the knowledge after a point. >> >> >>> Here's another thing, which can be done right (if we want). >>> >>> Rome/OpenVG Paths is actually nothing else than a special kind of more >>> general thing - shape. >>> >>> So, at very basis, we should have only two components for painting: >>> shape and paint. >>> And in fact we need to support only a single operation: fill the shape >>> with given paint. >>> (The path stroke could be seen as a special kind of fill) >>> >>> >>> So the question is: Really. Why we should constrain ourselves with >>> specific things >>> from a very starting, by cutting out a most basic (and abstact ideas) behind? >>> >>> There are infinite number of ways, how one could define a shape. >>> While paths is only a small, yet effective representation of shapes. >>> In same way there are infinite number of ways how one could define a paint. >>> >>> Then this looks like a strong basis for building-up a powerful & >>> flexible graphics engine :) >>> >> >> I do not know. Do the other frameworks outside smalltalk use something else >> than paths? >> I think that we should start - making rome working. We are nearly there >> - test it >> - refactor it. >> - I would like to see the canvas for morphic30 too. >> - refactor the system to use that. >> stef >> > > The current Morphic 3 canvas is based on SVG / OpenVG. The main element is the path. But the fundamental building block is a trajectory of a pen that defines shapes, and fills. So it is easy to extend to ways to define shapes other than paths. > > BTW, the Morphic 3 canvas is separated from the Morphs and their geometry. This means that Morphic 3 morphs could be used with Athens / Rome / Cairo, or even with Balloon. It also means that the Morphic 3 canvas could be used with Morphic 2, Tweak or any other framework that can call an OpenVG like api. > > I'm working on an update to the Morphic 3 web page right now. Will be ready today or tomorrow, and it will include some actual samples of rendering. > > Cheers, > Juan Vuletich

May 31, 2010

Re: [Pharo-project] Rome/Athens notes

by Igor Stasenko

On 31 May 2010 17:45, Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Stef, Igor, > > (copied Igor too) > > StÃ©phane Ducasse wrote: >> >> On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: >> >> >>> >>> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> cool post >>>> >>>> >>> >>> Yeah, these things are quite interesting. Except that not much people >>> actually interested in it :) >>> >> >> I do not think so. >> Good posts are read more that you believe. Now in mailing-list the numbers >> of mails >> cut the knowledge after a point. >> >> >>> >>> Here's another thing, which can be done right (if we want). >>> >>> Rome/OpenVG Paths is actually nothing else than a special kind of more >>> general thing - shape. >>> >>> So, at very basis, we should have only two components for painting: >>> shape and paint. >>> And in fact we need to support only a single operation: fill the shape >>> with given paint. >>> (The path stroke could be seen as a special kind of fill) >>> >>> >>> So the question is: Really. Why we should constrain ourselves with >>> specific things >>> from a very starting, by cutting out a most basic (and abstact ideas) >>> behind? >>> >>> There are infinite number of ways, how one could define a shape. >>> While paths is only a small, yet effective representation of shapes. >>> In same way there are infinite number of ways how one could define a >>> paint. >>> >>> Then this looks like a strong basis for building-up a powerful & >>> flexible graphics engine :) >>> >> >> I do not know. Do the other frameworks outside smalltalk use something >> else >> than paths? >> I think that we should start Â Â - making rome working. We are nearly there >> Â Â Â Â - test it >> Â Â Â Â - refactor it. >> Â Â Â Â - I would like to see the canvas for morphic30 too. >> Â Â Â Â - refactor the system to use that. >> stef >> > > The current Morphic 3 canvas is based on SVG / OpenVG. The main element is > the path. But the fundamental building block is a trajectory of a pen that > defines shapes, and fills. So it is easy to extend to ways to define shapes > other than paths. > How about shapes which defined by other means than trajectory of pen? Suppose things like parametric shapes. Circle/ellipse for instance could be defined by 1 coordinate and radius(es). > BTW, the Morphic 3 canvas is separated from the Morphs and their geometry. > This means that Morphic 3 morphs could be used with Athens / Rome / Cairo, > or even with Balloon. It also means that the Morphic 3 canvas could be used > with Morphic 2, Tweak or any other framework that can call an OpenVG like > api. > > I'm working on an update to the Morphic 3 web page right now. Will be ready > today or tomorrow, and it will include some actual samples of rendering. > Oh. This is indeed good news. I read about Morphic3 before, but you never mentined the details about it infrastructure. Now, its really nice to know that it is based on similar concepts. > Cheers, > Juan Vuletich > -- Best regards, Igor Stasenko AKA sig.

May 31, 2010

[Pharo-project] Manuia Memory Monitor

by Torsten Bergmann

BTW: There is also the old "MemoryUsage" from Squeak (see [1]/[2]). Dont know if it still works [1] http://map.squeak.org/package/5307d593-6aa4-496a-94fa-68a5ed82a3ba [2] http://web.nilpotent.org/software/smalltalk/MemoryUsage3.st.gz -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by Henrik Johansen

On May 31, 2010, at 4:38 14PM, Henrik Johansen wrote: > > On May 31, 2010, at 4:12 11PM, Mariano Martinez Peck wrote: > >> Alexandre: Is there a way (or will be in a future) a way to script and customize it ? >> >> Suppose I want to trace several things, not only the amount of memory used. I would love to be able to define my own curves and have several at the same time. >> > Look at the code, it's quite simple. :) > All you seem to have to do is subclass MMProbe, implement its interface (get current value, choosing a color, and potential custom rendering) and voila, you have a custom curve! > > Cheers, > Henry And of course, when looking a bit closer, it's even simpler :) (If you don't need custom display etc. that is) graph := MMGraph new. probe := MMProbe probleBlock: [:theProbe | theProbe addValue: someValueIWantACustomGraphFor]. graph addProbe: probe; openInWorld. not sure if probleBlock is a spelingError :) Cheers, Henry PS. Would it be possible to do: ManuiaMonitor>> initialize graph := MMGraph new. graph addProbe: MUsedMemoryProbe new; addProbe: MMGCProbe new. (and only window addMorph: graph in the open method) and remove self addProbe: MUsedMemoryProbe ... from MMGraph initialize? That way, a graph not used by the monitor is empty by default, and a new instance can be used for whatever graphing purpose one desires, like Mariano :)

May 31, 2010

Re: [Pharo-project] Fwd: [squeak-dev] traits

by Johan Fabry

Hi Norbert, Mariano, there is a quick way to see which classes are using traits. Inspect the following expression: Smalltalk allClasses select: [:cls| cls hasTraitComposition and: [cls traitComposition size > 0]] On 31 May 2010, at 10:15, Mariano Martinez Peck wrote: > Hi Norbert: I am not sure the current situation in Squeak but in Pharo I know it is used in some places. > > I think in some Collection testing and Nile framework...but I am not sure. > > Anyone can help? > > Cheers > > Mariano > > ---------- Forwarded message ---------- > From: Norbert Fortelny <norbert.fortelny(a)gmail.com> > Date: Wed, May 19, 2010 at 5:17 PM > Subject: [squeak-dev] traits > To: squeak-dev <squeak-dev(a)lists.squeakfoundation.org> > > > Could anyone point me to sample code using traits in squeak. > Poked around a bit but couldn't find anything. > thanks and sorry if that is inappropriate here. > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by Henrik Johansen

On May 31, 2010, at 4:12 11PM, Mariano Martinez Peck wrote: > Alexandre: Is there a way (or will be in a future) a way to script and customize it ? > > Suppose I want to trace several things, not only the amount of memory used. I would love to be able to define my own curves and have several at the same time. > Look at the code, it's quite simple. :) All you seem to have to do is subclass MMProbe, implement its interface (get current value, choosing a color, and potential custom rendering) and voila, you have a custom curve! Cheers, Henry

May 31, 2010