- Pharo-dev - lists.pharo.org

[Pharo-project] KnownLands: a Class dependency explorer

by David Goehrig

Hey Pharoers, I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab. What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods. In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods. Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 16, 2009

[Pharo-project] Date formatting - Chronos, other?

by Schwab,Wilhelm K

Hello all, What is the best option for converting dates to text and vise versa? Is Chronos the right choice? Bill

July 16, 2009

[Pharo-project] Call for testers of a faster MC

by StÃ©phane Ducasse

Hi guys thanks to matthew I finally understood his optimization. The entry point is MCPackage>>snapshot I published a slice in the inbox. If you can try it, look at the changes and let me know. I did some experiences and could load moose which start to be complex but I may have done some mistakes. Stef PS: having real package will really make all that much faster. I will regularly to the TaskForces the code for a new package class.

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

>>> To me the most important thing is that >>> at all points in time I know exactly what changes when I compile a >>> method. Simple if you are in a class, you change that class, your change take precedence over trait methods. If you are in trait you change the traits => the classes using that trait got that changes except if they redefined the methods. Stef

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by StÃ©phane Ducasse

> I am not saying that you should not use them. I am just trying to > explain why I am not using them myself. Still you should pay attention because you are the guy doing seaside > >> I'm writing a trait to get magritte-aware xml output without having >> to >> always inherit >> from a top class or to copy and paste all the time the same code in >> my >> classes. > > I would use delegation for that. Both, Pier and Magritte use that > pattern too. I think that traits in the metaclass was an error because the kernel is not clean Now if you look at tests of the collection or nile (you can really reuse the same traits for two different implementation and this is really working). >>> As Paolo suggested the problem can be simply solved by introducing >>> an >>> Iterable superclass to Collection and Stream. >> >> I do not see how his solution will offer a faster implementation > > Evaluating > > ((aCollection > select: [ :e | ... ]) > collect: [ :e | ... ]) > > iterates twice over aCollection, sure I was talking compared with a one pass select:collect: > while > > ((aCollection readStream > select: [ :e | ... ]) > collect: [ :e | ... ]) > contents > > will iterate only once. Furthermore the second approach allows any > combination of any of the enumeration methods, not just a few > predefined ones. Also the implementation is less error prone, because > it just uses the standard methods on collection and stream. Yes that I know this was like that in CLOS streams. >> > What if you want to iterate forward and backward over a collection? > What if you have multiple things in your model object that you want to > iterate over? Then you need the iterator Pattern this is clear. > Would you add several iterable traits and prefix all selectors? > > aSystem do: ... > aSystem reverseDo: ... > aSystem itemsDo: ... > > Or rather use delegation? probably delegation. I think that there are place for more than one solution. > > aSystem iterator do: ... > aSystem reverseIterator do: ... > aSystem itemsIterator do: ... > > I find the second solution much nicer because it extracts the strategy > how to iterate over something to a separate object. In about any model > there are multiple collections involved and multiple ways of iterating > through these objects, embedding the iterators directly into the > container seems wrong to me. > >> I think that you should also have a look at what other people are >> doing. > > All I am saying is that collection iteration is one of the few things > that Smalltalk got wrong. I do not think so when I look at Java collection. I would say that the collections are a bit too static in their composition (missing uniqueOrdered) So if someone propose a good integration into pharo we will certainly integrate it. Now I'm curious to see if we can change the superclass of collection :) Stef

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Mariano Martinez Peck

On Thu, Jul 16, 2009 at 2:12 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > > > With the latest pharo-web, with NOD32 antivirus disabled, the speed up > was pretty significant. > yes. Nod32 WON'T let you use Squeak, Pharo, Quis or whatever. You can notice this when you use monticello. As the .changes is being changed a lot, nod32 is inspecting it all the time.....unusable. Solution: exclude the directory where the .changes is fron Nod32 configuration! > > Regards, > > -- > Esteban > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Esteban A. Maringolo

2009/7/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > I think it has no sense to test with several images. Look adrian comment > > "This basically measures how many bytecodes and messages the VM can > execute per second." > > So, I guess it is a benchmark for VM + hardware. I don't think the image > canÂ influence much here. Am I correct? Oookay, sorry. However, I understand the 2.8.3 one-click and 2.8.4 one click have different VM's. With the latest pharo-web, with NOD32 antivirus disabled, the speed up was pretty significant. Regards, -- Esteban

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by StÃ©phane Ducasse

We should pay attention that there is closure in pharo. On Jul 16, 2009, at 3:44 PM, Benoit St-Jean wrote: > If that helps... > > 0 tinyBenchmarks > > Windows XP, 2002, SP3 > Pentium 4, dual core, 3Ghz, 2 Gb RAM > > All tests were run 5 times and here are the averages : > > Some comparisons: > > Squeak 3.9 latest update: #7067 > 76297334 bytecodes/sec; 3397437 sends/sec > > Squeak 3.10.2 latest update: #7179 > 74839234 bytecodes/sec; 3443964 sends/sec > > Pharo 0.1 latest update: #10377 > 75877223 bytecodes/sec; 3134820 sends/sec > > > > > > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > Blog: lamneth.wordpress.com > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > From: Gary Chambers <gazzaguru2(a)btinternet.com> > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Thursday, July 16, 2009 6:51:59 AM > Subject: Re: [Pharo-project] Making some progress, and a few > observations > > In the Windows camp, Watery2 theme... > > Vista 64bit (32bit VM, of course), 4GB DDR2-800, Q9550 (2.8GHz), > Pharo0.1Core-10371. > > 0 tinyBenchmarks '569205113 bytecodes/sec; 16188534 sends/sec' > > Time millisecondsToRun: [ > Browser fullOnClass: Object selector: #at:. > World displayWorld] 373 > > Older laptop, XP, 1GB, Pentium M (1.73 GHz)... > > 0 tinyBenchmarks '294761082 bytecodes/sec; 8530869 sends/sec' > > Time millisecondsToRun: [ > Browser fullOnClass: Object selector: #at:. > World displayWorld] 677 > > Still feels quite responsive even on that! > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> > Sent: Thursday, July 16, 2009 2:07 AM > Subject: Re: [Pharo-project] Making some progress, and a few > observations > > > On my crusty old Linux box: > > 155339805 bytecodes/sec; 3931964 sends/sec > > However, I always like to test on less than my customers will have, > so by > some arguments, this machine is just about right. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alain > Plantec > [alain.plantec(a)free.fr] > Sent: Wednesday, July 15, 2009 6:19 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Making some progress, and a few > observations > > Adrian Lienhard a Ã©crit : > > Bill, > > > > Could you post the results of the following benchmark? > > > > 0 tinyBenchmarks > > > > > On my MacBook Pro with 2.4GHz and the Mac 4.1.1beta2U VM I get: > > > > '543236074 bytecodes/sec; 12101592 sends/sec' > > > On Intel Core2 Duo T7700 at 2.4 GHz, Linux Ubuntu 9.04, 64 bit > pharo-core : #10379 '585812356 bytecodes/sec; 14531440 sends/sec' > pharo : #10373 '574312955 bytecodes/sec; 14261923 sends/sec' > > not so bad with linux :) > > Cheers > Alain > > > Cheers, > > Adrian > > > > On Jul 15, 2009, at 22:34 , Schwab,Wilhelm K wrote: > > > > > >> Stef, > >> > >> No browser should be that slow. I suspect the Linux vm is not a > >> speed demon, the xp machines I use are heavily burdened by anit- > >> virus software and other performance drains, etc. My linux box at > >> home might be further hindered by the fact that I bought a wide > >> screen monitor for it, and use LOTS of screen real estate. Still, > >> when I compare Pharo with other software (including Dolphin) under > >> similarly abusive conditions, Pharo is not quick. > >> > >> This particular image is small; it is based on the most recent web > >> image, and is 22 MB. It has some of my Seaside code in it, but has > >> not yet executed same. I have a couple of Seaside cleanup > >> expressions that help when images bloat up, but looking at the > >> current size makes me think I'm missing an opportunity. All that > >> aside, on my linux box, I find that after the saving cursor > >> disappears, it can take a few seconds for the image to again become > >> responsive. On xp in my office, there is at least a second of down > >> time after the cursor reverts to normal. > >> > >> In doing some SIF imports, I noted that it was hard to tell when > the > >> image was still busy. I have no idea how long it should take to do > >> the work it was doing, but it took long enough that some gentle > >> prodding becomes irresistable: "is it done yet?" I remember lots > of > >> debate about Cursor class>>showWhile: on Dolphin; it might be one > of > >> those things that is tricky to get right. > >> > >> A little bit nicer news: I have it running on my office machine > >> (xp), with FreeType in use, and it's ok with the standard tools and > >> the w2k theme. > >> > >> Bill > >> > >> > >> > >> -----Original Message----- > >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> [mailto:pharo-project-bounces@lists.gforge.inria.fr > >> ] On Behalf Of StÃ©phane Ducasse > >> Sent: Wednesday, July 15, 2009 2:31 PM > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] Making some progress, and a few > >> observations > >> > >> > >>> Stef, > >>> > >>> In terms of response times, even with a lot of things turned > off, I > >>> was still surprised at how long it takes to change from even one > >>> method to another. > >>> > >> which browser are you using. > >> Because the old browser should not be that slow. > >> > >> > >> > >>> Anything past 0.2 sec (or whatever that threshold is) starts to > add > >>> up; Pharo sometimes takes up to a second, which is _really_ > shows up. > >>> > >>> Saving an image is not necessarily quick either, I _think_ > >>> particuarly > >>> on Linux?? > >>> > >> What is the size of your image: here jannik generated an image of > >> 800 mb. > >> > >> > >>> Also, I get the sense the wait cursors are displayed, on Linux, > for a > >>> smaller fraction of the down time than on Windows. > >>> > >>> Bill > >>> > >>> > >>> -----Original Message----- > >>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr > >>> ] On Behalf Of StÃ©phane Ducasse > >>> Sent: Wednesday, July 15, 2009 12:58 PM > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Subject: Re: [Pharo-project] Making some progress, and a few > >>> observations > >>> > >>> > >>> On Jul 15, 2009, at 6:04 PM, Schwab,Wilhelm K wrote: > >>> > >>> > >>>> Hello all, > >>>> > >>>> I managed to create an install script; as I suspected would be > case, > >>>> it was very anticlimactic. I tried creating a password-protected > >>>> directory under my personal web site, but that did not go > well. The > >>>> authentication is weird, so it was probably asking a lot. A > >>>> directory repository worked. > >>>> > >>> Good to know > >>> > >>>> Does Monticello/PackageInfo see a change in method category (aka > >>>> package) as a change to the package? > >>>> > >>> normally it should. > >>> > >>> > >>>> It appears not, and it worries me a little in that it seems to > make > >>>> it easy to lose work by forgetting to save it. Do any of you > script > >>>> saving your packages? > >>>> > >>> you can check in ScriptLoader to see how we compute the packages > that > >>> changed (not only dirty but also new packages) > >>> > >>> > >>>> The results are untested at present, but I used SIF to transfer a > >>>> fair amount of code into Pharo. To cope with the naming of the > ODBC > >>>> classes, I ended up doing things like Smalltalk at:#DBConnection > >>>> put:ODBCConnection, and that worked out nicely, at least AFAICT > at > >>>> this stage. SIF finally ended up complaining about running out > of > >>>> items when processing the last file. I reserve the right to > later > >>>> report that it was a miserable failure, but it looks like I > most of > >>>> the code imported. > >>>> > >>>> Using the standard tools, the w2k theme, disabling faded > backgrounds > >>>> and enabling fast drag, performance on an older Linux system is > ok > >>>> (more or less). There are still things that take too long, > >>>> > >>> like what? > >>> > >>> > >>>> and Pharo's responses are no better (sometimes worse) than even > >>>> software running over a remote desktop connection. We need a > speed > >>>> boost, but judicious settings help a little. > >>>> > >>>> Is there a way to disable the anti-aliased fonts? In fairness, I > >>>> should try turning that off to see if any speed boost is worth > the > >>>> price. > >>>> > >>>> 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 > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Make your browsing faster, safer, and easier with the new Internet > ExplorerÂ® 8. Optimized for Yahoo! Get it Now for Free! > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] Making some progress, and a few observations

by Schwab,Wilhelm K

I remember (a long time ago) digging around for a computer to test one of the large commercial Smalltalks - VA IIRC. It did not go well, and in the process of checking on how the machine performed otherwise, I ran something out of the then-current M$ Office and quickly discovered that the particular machine was not up to my needs. The thing just crawled, and the interesting part was watching it draw, several times(!!), one of the common dialogs. It was quite a display of inefficiency, and was repeated with every user interaction on that dialot. The point being that faster machines were able to overpower the bad code, which is pretty much what has kept MS in business. Byte codes and message sends are important, but so is efficiency and feedback to the user. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Thursday, July 16, 2009 9:46 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making some progress, and a few observations I think it has no sense to test with several images. Look adrian comment "This basically measures how many bytecodes and messages the VM can execute per second." So, I guess it is a benchmark for VM + hardware. I don't think the image can influence much here. Am I correct? best, Mariano On Thu, Jul 16, 2009 at 1:38 PM, Esteban A. Maringolo <emaringolo(a)gmail.com<mailto:emaringolo@gmail.com>> wrote: Here are my numbers. Computer: Thinkpad T61,Intel Core 2 Duo T7300 @ 2GHz, 2GB RAM) OS: Windows XP SP3 Seaside 2.8.3 One Click Image: '157248157 bytecodes/sec; 4708854 sends/sec' Seaside 2.8.4 One Click Image: '158907510 bytecodes/sec; 4592283 sends/sec' pharo0.1-10373web09.07.2: '156479217 bytecodes/sec; 4413998 sends/sec' Regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] optimizing select:thenCollect:

by Lukas Renggli

>> The class and metaclass system of Smalltalk is already at the limit of >> complexity that I can handle. Traits make this existing model even >> more complicated. Even with support from a trait aware browser I find >> traits extermely hard to use. To me the most important thing is that >> at all points in time I know exactly what changes when I compile a >> method. This is absolutely not clear when using traits. > > I find your statements a bit rude. I am not saying that you should not use them. I am just trying to explain why I am not using them myself. > I'm writing a trait to get magritte-aware xml output without having to > always inherit > from a top class or to copy and paste all the time the same code in my > classes. I would use delegation for that. Both, Pier and Magritte use that pattern too. >> As Paolo suggested the problem can be simply solved by introducing an >> Iterable superclass to Collection and Stream. > > I do not see how his solution will offer a faster implementation Evaluating ((aCollection select: [ :e | ... ]) collect: [ :e | ... ]) iterates twice over aCollection, while ((aCollection readStream select: [ :e | ... ]) collect: [ :e | ... ]) contents will iterate only once. Furthermore the second approach allows any combination of any of the enumeration methods, not just a few predefined ones. Also the implementation is less error prone, because it just uses the standard methods on collection and stream. >> Now you might say that this only works if I am not inheriting from >> some other important class. True, an Iterable-trait would avoid that >> problem. However, adding such a trait to an existing hierarchy looks >> extremely scary to me. It potentially pollutes an existing protocol >> with existing code that is most likely unrelated (or maybe it already >> contains some iterator code for something else). > > like what collect: select: do: reject: inject:into: ? What if you want to iterate forward and backward over a collection? What if you have multiple things in your model object that you want to iterate over? Would you add several iterable traits and prefix all selectors? aSystem do: ... aSystem reverseDo: ... aSystem itemsDo: ... Or rather use delegation? aSystem iterator do: ... aSystem reverseIterator do: ... aSystem itemsIterator do: ... I find the second solution much nicer because it extracts the strategy how to iterate over something to a separate object. In about any model there are multiple collections involved and multiple ways of iterating through these objects, embedding the iterators directly into the container seems wrong to me. > I think that you should also have a look at what other people are doing. All I am saying is that collection iteration is one of the few things that Smalltalk got wrong. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 16, 2009