- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Morph extension

by Gary Chambers

Have a go with it (use a fresh image rather than anything you might want to lose...). Stick the .cs in your image directory, open a workspace and do the following... (FileStream readOnlyFileNamed: 'MorphicExtensionPerformance.1.cs') fileInSilentlyAnnouncing: nil. Morph allSubInstances do: [:m | #(fillStyle layoutPolicy layoutFrame layoutProperties borderStyle cornerStyle actionMap clipSubmorphs) do: [:prop | m extension ifNotNilDo: [:extension | extension otherProperties ifNotNilDo: [:otherProperties | extension instVarNamed: prop put: ( otherProperties at: prop ifAbsent: []). otherProperties removeKey: #prop ifAbsent: []]]]] Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:49 PM Subject: Re: [Pharo-project] Morph extension Gary I would love to see morphic goes faster so we are ready to try :) Stef > > > I've managed to refactor the worst offenders. > > Benchmarks for the "opening system browser" below show an improvement. > > Going from patched to unpatched shows that the unpatched takes > between 15% > and 20% longer to complete depending on fonts/theme. > > (Benchmark code) > > | saveMorphs time | > [saveMorphs := World submorphs. > World removeAllMorphs."heh, heh" > time := [1 to: 10 do: [:i | > MorphicToolBuilder new open: > (Browser new setClass: SystemDictionary selector: nil). > World doOneCycleNow]. > World submorphs do: [:m | m delete. World doOneCycleNow]. > ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. > SystemWindow noteTopWindowIn: World. > time > > (end of benchmark code) > > I can make a changeset available for the brave who want to try. > I have developed a workspace script that (finally) appears to load it > correctly, > waas a lot of hung-image before getting there... > > (loading tested on 10451-BETA) > > Regards, Gary > > ----- Original Message ----- > From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 7:01 PM > Subject: Re: [Pharo-project] Morph extension > > > > > StÃ©phane Ducasse skrev: >> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: >> >> >>> After some experimenting I can get over 10% perfromance improvement >>> with >>> window operations when fillStyle; borderStyle; hResizing; vResizing >>> are >>> made as instance variables of Morph, rather than going through >>> extension. >>> >> >> this is a lot. >> You really mean Morph or we could get them in subclasses too. >> >> > Inspect this in an image with some windows open, it will give you the > percentage of morphs with otherProperties containing any given > property: > > |propBag noMorphs| > propBag := Bag new: 50. > noMorphs := 0. > Morph allSubInstances do: [:each | each otherProperties ifNotNil: > [:props | propBag addAll: props keys. > noMorphs := noMorphs +1]] . > noMorphs := noMorphs asFloat. > propBag sortedCounts collect: [:each | each key: each key / noMorphs; > yourself] > > > otherProperties is heavily abused. with respectively 98 and 125 > senders > of valueOfProperty: / valueOfProperty:ifAbsent:... > In my case there were _57_ different distinct otherProperties in > use, an > average of three, a maximum of 15, and four of them present in over a > quarter of morphs defining any (80% for the most common one)... > If moving directly to Morph is a bit extreme, at least _some_ of these > qualify for promotion to direct access in MorphExtension imho, it > seems > to have some "free" instvars anyways after the removal of players. > > In the interest of seeing which would benefit the most from moving, I > did a small profile: > - Dragging a window and switching some between different ones with 2 > browsers, a monticello browser, a workspace and a Method search open. > I had the following access numbers: > 105586->#clipSubmorphs (about 4.5 per millisecond) > 66029->#layoutProperties > 62783->#layoutPolicy > 55556->#theme > 41312->#hasDropShadow > 41310->#hasRolloverBorder > 36817->#fillStyle > 19241->#cornerStyle > 13239->#highlightedForDrop > 13239->#highlightedForMouseDown > 11945->#roundedCorners > 11911->#borderStyle > 10644->#edgeToAdhereTo > 9020->#paneColor > 8885->#lastPaneColor > [rest below 5000 accesses] > > Cheers, > Henry > > _______________________________________________ > 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

Sept. 16, 2009

Re: [Pharo-project] Usability improvements for the class browser:buttons

by Gary Chambers

The separation of the window control buttons (red, amber, green) is currently dependent upon the font chosen for the window tiltle. As for the browser buttons it would be relatively little effort to make then look like the attached image. Regards, Gary ----- Original Message ----- From: "Stephan Eggermont" <stephan(a)stack.nl> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:35 PM Subject: [Pharo-project] Usability improvements for the class browser:buttons > Hello, > > When I open a class browser in a Pharo Image (10418 updated to 10451) > with the default Watery 2 theme, the window is visually dominated by the > button bar. Compared to the other parts of the window, it has too much > vertical height and there is not enough white space around the buttons. > > The problem with vertical height can be illustrated by looking at the > precision needed to select a class category versus that needed to click > the browse button. The button has about twice the vertical height. > That would be ok when clicking the button would be the more common > operation, but I don't find that to be the case. > > The kind of button used in Watery 2 only works well visually when it > has a rather large white space around it. The button bar of the > preference > browser already works much better than that of the class browser, > but even that has too little space above and below. > > The buttons in the button bar of the class browser feel very heavy > because > they don't have enough horizontal separation. With the default window > size, there is not enough space for the needed separation. When the > window is grown, instead of growing the separation first, and then the > button width, only the button width is grown. Some operating systems > have introduced a better solution for this problem, a dedicated button > bar. > Attached is an impression of how this could look. I hope you'd agree > that it would provide a cleaner look. I'd be interested in some clues on > what would be needed to add such a button bar. > > The red, orange, and green window buttons used to have a much better > horizontal separation. I am not sure in which update they were put so > close together, but they need at least as much horizontal separation as > the space from left window border to the first (red) button. > > Stephan Eggermont > > > -------------------------------------------------------------------------------- > > > > -------------------------------------------------------------------------------- > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Author name prompt window is too big

by StÃ©phane Ducasse

open a ticket and submit your code. Give two significative example would be good (and we do not want . or _ anyway) This was on my todo but skipped my mind. Stef On Sep 16, 2009, at 4:15 PM, Oscar Nierstrasz wrote: > > Today I was giving a Pharo demo, using a slightly larger than standard > font. > > When I tried to commit a change, the prompt for my user name was > bigger than the available screen space on my laptop. Luckily I could > still type, though I could not see what I was typing. > > Can we please modify Author>>messagePrompt to use a *short* message? > The existing one is ridiculously large. > > Author>>messagePrompt > ^ > 'Please type your name. It will be used to sign the changes you make > to the image. > Try to write an ASCII approximation of your name with only alphabetic > characters > and avoiding, if possible, spaces, accents, dashes and similar > characters. > Examples (The prefered form is the first one of each name): > > Miguel CobÃ¡ -> MiguelCoba > Miguel CobÃ¡ -> miguel.coba > Miguel CobÃ¡ -> miguel_coba > GÃ¶ran Krampe -> GoranKrampe > GÃ¶ran Krampe -> GoeranKrampe > GÃ¶ran Krampe -> goran.krampe > GÃ¶ran Krampe -> goran_krampe > Vincent van Gogh -> VincentVanGogh > StÃ©phane DUCASSE -> StephaneDucasse > StÃ©phane DUCASSE -> stephane.ducasse > Yoshiki Oshima -> YoshikiOshima > Yoshiki Oshima -> yoshiki.oshima > ' > > The first example would be good enough. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by StÃ©phane Ducasse

Gary I would love to see morphic goes faster so we are ready to try :) Stef > > > I've managed to refactor the worst offenders. > > Benchmarks for the "opening system browser" below show an improvement. > > Going from patched to unpatched shows that the unpatched takes > between 15% > and 20% longer to complete depending on fonts/theme. > > (Benchmark code) > > | saveMorphs time | > [saveMorphs := World submorphs. > World removeAllMorphs."heh, heh" > time := [1 to: 10 do: [:i | > MorphicToolBuilder new open: > (Browser new setClass: SystemDictionary selector: nil). > World doOneCycleNow]. > World submorphs do: [:m | m delete. World doOneCycleNow]. > ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. > SystemWindow noteTopWindowIn: World. > time > > (end of benchmark code) > > I can make a changeset available for the brave who want to try. > I have developed a workspace script that (finally) appears to load it > correctly, > waas a lot of hung-image before getting there... > > (loading tested on 10451-BETA) > > Regards, Gary > > ----- Original Message ----- > From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, September 08, 2009 7:01 PM > Subject: Re: [Pharo-project] Morph extension > > > > > StÃ©phane Ducasse skrev: >> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: >> >> >>> After some experimenting I can get over 10% perfromance improvement >>> with >>> window operations when fillStyle; borderStyle; hResizing; vResizing >>> are >>> made as instance variables of Morph, rather than going through >>> extension. >>> >> >> this is a lot. >> You really mean Morph or we could get them in subclasses too. >> >> > Inspect this in an image with some windows open, it will give you the > percentage of morphs with otherProperties containing any given > property: > > |propBag noMorphs| > propBag := Bag new: 50. > noMorphs := 0. > Morph allSubInstances do: [:each | each otherProperties ifNotNil: > [:props | propBag addAll: props keys. > noMorphs := noMorphs +1]] . > noMorphs := noMorphs asFloat. > propBag sortedCounts collect: [:each | each key: each key / noMorphs; > yourself] > > > otherProperties is heavily abused. with respectively 98 and 125 > senders > of valueOfProperty: / valueOfProperty:ifAbsent:... > In my case there were _57_ different distinct otherProperties in > use, an > average of three, a maximum of 15, and four of them present in over a > quarter of morphs defining any (80% for the most common one)... > If moving directly to Morph is a bit extreme, at least _some_ of these > qualify for promotion to direct access in MorphExtension imho, it > seems > to have some "free" instvars anyways after the removal of players. > > In the interest of seeing which would benefit the most from moving, I > did a small profile: > - Dragging a window and switching some between different ones with 2 > browsers, a monticello browser, a workspace and a Method search open. > I had the following access numbers: > 105586->#clipSubmorphs (about 4.5 per millisecond) > 66029->#layoutProperties > 62783->#layoutPolicy > 55556->#theme > 41312->#hasDropShadow > 41310->#hasRolloverBorder > 36817->#fillStyle > 19241->#cornerStyle > 13239->#highlightedForDrop > 13239->#highlightedForMouseDown > 11945->#roundedCorners > 11911->#borderStyle > 10644->#edgeToAdhereTo > 9020->#paneColor > 8885->#lastPaneColor > [rest below 5000 accesses] > > Cheers, > Henry > > _______________________________________________ > 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. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by StÃ©phane Ducasse

Mike Yes this is a good idea. read the blog of dale. We are starting to manage all our project Moose, Mondrian, Glamour with metacello I'm waiting that doru and dale release a version with fixed api to write a chapter for Pharo by example2 Stef On Sep 16, 2009, at 1:59 PM, Michael Robers wrote: > I am interested in learning how we could use metacello. Not for 1.0. > Before we commit to it for 1.1 I think we would need to conduct an > experiment in parallel to get a feel for it. We should also review the > other proposals. Then commit to one proposal for 1.1 1.2 etc and make > the process work. Or we could stall 1.1 until we have a process in > place but I think we will still have fixes coming in we will not want > a lag. What do you think? > > Cheers > Mike > > On 16 Sep 2009, at 10:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> Hi >> >> I value the idea that when we look for a software (for example SIXX) >> we can find a version that is working. In the past we used Universes >> and >> if was successful. >> We cannot not have squeakmap and universe at the same time. >> I discussed with damien briefly about that and he told me that we >> coud >> have >> a metacello alternative. >> Now I wonder if for pharo 1.0 it makes sense. >> May be having a nice Universe for pharo would be good and important. >> >> Dale what do you think? >> Do you see metacello working in the story (may be for 1.1)? >> 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. 16, 2009

Re: [Pharo-project] Morph extension

by Marcus Denker

On 16.09.2009, at 10:29, Gary Chambers wrote: > I get a different "top offenders" list of course. > I've managed to refactor the worst offenders. > > Benchmarks for the "opening system browser" below show an improvement. > > Going from patched to unpatched shows that the unpatched takes > between 15% > and 20% longer to complete depending on fonts/theme. > > (Benchmark code) > > | saveMorphs time | > [saveMorphs := World submorphs. > World removeAllMorphs."heh, heh" > time := [1 to: 10 do: [:i | > MorphicToolBuilder new open: > (Browser new setClass: SystemDictionary selector: nil). > World doOneCycleNow]. > World submorphs do: [:m | m delete. World doOneCycleNow]. > ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. > SystemWindow noteTopWindowIn: World. > time > > (end of benchmark code) > > I can make a changeset available for the brave who want to try. Yes, I would like to try! Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 16, 2009

Re: [Pharo-project] Visual nonsense

by Gary Chambers

Have settled for active window: with Watery2 the taskbar button label is shown with the selection colour. with W2K I have removed the fixed colour, appears darker than others for active window and effectively re-enables custom colour support for buttons (like the SystemBrowser inheritance button). Will release later this week. In the meantime... To see with W2K remove #buttonColorFor: from UIThemeW2K Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:26 PM Subject: Re: [Pharo-project] Visual nonsense > Gary, > > Whichever you think will work best - changing the background is probably > more win2k-like, now that you mention it, but anything that distinguishes > the active window would be welcome. > > Thanks! > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Wednesday, September 16, 2009 4:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Visual nonsense > > Do you mean the icon or the button background? > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, September 16, 2009 12:02 AM > Subject: [Pharo-project] Visual nonsense > > >> Gary, especially for the W2k theme, it would be really nice to have a >> distinct look for the selected view's icon in the task bar. >> >> Andy, is there a good place to change the background fill style? When I >> last looked, it seemed to me that it was hard-coded. You mentioned a >> configuration tool you wanted to build, but I would be happy to use a >> do-it chunk to make the change; I just could not find a relevant style. >> >> Sorry to bug you guys with such relative minutia. Thanks to all for the >> lots of stuff that works well enough that I notice these things. >> >> 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

Sept. 16, 2009

[Pharo-project] Usability improvements for the class browser: buttons

by Stephan Eggermont

Hello, When I open a class browser in a Pharo Image (10418 updated to 10451) with the default Watery 2 theme, the window is visually dominated by the button bar. Compared to the other parts of the window, it has too much vertical height and there is not enough white space around the buttons. The problem with vertical height can be illustrated by looking at the precision needed to select a class category versus that needed to click the browse button. The button has about twice the vertical height. That would be ok when clicking the button would be the more common operation, but I don't find that to be the case. The kind of button used in Watery 2 only works well visually when it has a rather large white space around it. The button bar of the preference browser already works much better than that of the class browser, but even that has too little space above and below. The buttons in the button bar of the class browser feel very heavy because they don't have enough horizontal separation. With the default window size, there is not enough space for the needed separation. When the window is grown, instead of growing the separation first, and then the button width, only the button width is grown. Some operating systems have introduced a better solution for this problem, a dedicated button bar. Attached is an impression of how this could look. I hope you'd agree that it would provide a cleaner look. I'd be interested in some clues on what would be needed to add such a button bar. The red, orange, and green window buttons used to have a much better horizontal separation. I am not sure in which update they were put so close together, but they need at least as much horizontal separation as the space from left window border to the first (red) button. Stephan Eggermont

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Gary Chambers

I get a different "top offenders" list of course. I've managed to refactor the worst offenders. Benchmarks for the "opening system browser" below show an improvement. Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme. (Benchmark code) | saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time (end of benchmark code) I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there... (loading tested on 10451-BETA) Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension StÃ©phane Ducasse skrev: > On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: > > >> After some experimenting I can get over 10% perfromance improvement >> with >> window operations when fillStyle; borderStyle; hResizing; vResizing >> are >> made as instance variables of Morph, rather than going through >> extension. >> > > this is a lot. > You really mean Morph or we could get them in subclasses too. > > Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property: |propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself] otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players. In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses] Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Visual nonsense

by Schwab,Wilhelm K

Gary, Whichever you think will work best - changing the background is probably more win2k-like, now that you mention it, but anything that distinguishes the active window would be welcome. Thanks! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Wednesday, September 16, 2009 4:45 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Visual nonsense Do you mean the icon or the button background? Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 12:02 AM Subject: [Pharo-project] Visual nonsense > Gary, especially for the W2k theme, it would be really nice to have a > distinct look for the selected view's icon in the task bar. > > Andy, is there a good place to change the background fill style? When I > last looked, it seemed to me that it was hard-coded. You mentioned a > configuration tool you wanted to build, but I would be happy to use a > do-it chunk to make the change; I just could not find a relevant style. > > Sorry to bug you guys with such relative minutia. Thanks to all for the > lots of stuff that works well enough that I notice these things. > > 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. 16, 2009