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

[Pharo-project] Text>>fromString: and String>>asText

by Fernando olivero

Name: SLICE-Issue-2745-TextFromStringAddingBlackAttribute-FernandoOlivero.1 Author: FernandoOlivero Time: 3 August 2010, 3:32:02 pm UUID: 85d642dd-87c1-4cab-9aa2-629ab10a6bd8 Ancestors: Dependencies: Collections-Text-FernandoOlivero.37 Added the black color attribute to all text's, created sending #asText ( which in turn sends Text>>fromString: ). Which produces a transparent color when rendered sending: aCanvas paragraph: paragraph bounds: bounds color: self fillStyle I've added the black color attribute by default.

Aug. 3, 2010

[Pharo-project] Issue 2744: Renaming the path to the image is not caught in Pharo on OS X

by Mircea Lungu

Hi guys, If I rename any of the directories in the path of a running image I will break the image: I can't save it, I can't close it. I get a debugger at any step. It seems the image is not informed of the path change and it still tries to log the changes in the the changes file which has already moved. I verified this on OS X,. I opened an issue for this: http://code.google.com/p/pharo/issues/detail?id=2744 Mircea.

Aug. 3, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Sean P. DeNigris

Levente Uzonyi-2 wrote: > > >> =Documentation= > > Nobody likes to write documentation. > I've started to enjoy writing class comments and tests. Especially when I go back to system classes (that I figured out every last detail about) a week later and can pick up where I left off :) Sean -- View this message in context: http://forum.world.st/Poll-missing-libraries-to-support-business-tp2310842p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 3, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by laurent laffont

On Tue, Aug 3, 2010 at 2:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Aug 3, 2010, at 2:12 PM, Alexandre Bergel wrote: > > >> alex my question was more naive and probably it shows that I do not know > how the announce protocol should be implemented > >> but why do you have to record them? > > > > The purpose of an announcer is to dispatch events. Callbacks are > registered in an announcer, and an announcer receives and dispatch events to > the callbacks. > > In my enh, each unit test (subclass of TestCase) has an announcer. Maybe > this is not a good strategy. Having one global announcer for unit test may > be more convenient in some situations. > > > > Something nice, is that if there is no callback registered, events are > not emitted. This means that this should incur no overhead (even though I > did not measured). > > Thanks for the explanation so I think that then this is better to have one > per class this way we do not have the Dependent kind of problems where you > have plenty of objects registering to a single table and get everytbody > slow. > I wonder, if the announcer is in TestResult, we only need one, no ? Laurent > > Stef > > > > > Cheers, > > Alexandre > > > > > > > >> > >>> > >>> Cheers, > >>> Alexandre > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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 >

Aug. 3, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by StÃ©phane Ducasse

On Aug 3, 2010, at 2:12 PM, Alexandre Bergel wrote: >> alex my question was more naive and probably it shows that I do not know how the announce protocol should be implemented >> but why do you have to record them? > > The purpose of an announcer is to dispatch events. Callbacks are registered in an announcer, and an announcer receives and dispatch events to the callbacks. > In my enh, each unit test (subclass of TestCase) has an announcer. Maybe this is not a good strategy. Having one global announcer for unit test may be more convenient in some situations. > > Something nice, is that if there is no callback registered, events are not emitted. This means that this should incur no overhead (even though I did not measured). Thanks for the explanation so I think that then this is better to have one per class this way we do not have the Dependent kind of problems where you have plenty of objects registering to a single table and get everytbody slow. Stef > > Cheers, > Alexandre > > > >> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 3, 2010

Re: [Pharo-project] Refactor source method is grayed out?

by StÃ©phane Ducasse

doru please stop this insane appetizer for OCompletion, I have to work on latex documents and integrate code no fun programming right now ;D Stef On Aug 3, 2010, at 1:38 PM, Tudor Girba wrote: > Hi, > > OCompletion forked the code from ECompletion and it now builds on it. I think the reason for this fork was that at the time when Romain started there was nobody really maintaining ECompletion. > > But, it would be great to have just one completion mechanism. I highly suggest to take a look at the new OCompletion: now it is fast and in most situations it provides significantly better suggestions than ECompletion. What's more the ECompletion-based suggestions are also available in a reasonable manner. > > Cheers, > Doru > > > On 3 Aug 2010, at 13:23, Lukas Renggli wrote: > >> I am using the images from hudson.lukas-renggli.ch. I don't know how >> oCompletion depends/overrides on eCompletion, so indeed it might make >> a difference. >> >> Lukas >> >> On Tuesday, August 3, 2010, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>> Lucas, which image are you using - and I will load it up and try again (I am using the seaside 3.0rc image - although I did unload oCompletion from it and then load eCompletion - maybe that makes a difference?). I appreciate your patience on this by the way - often I'm not sure which things are supposed to work (or work differently from how I expect). >>> >>> Tim >>> >>> On 3 Aug 2010, at 11:24, Lukas Renggli wrote: >>> >>> >>> I played a bit with the selection an the enabling of the menus this >>> morning, however I found it quite confusing if the closest matching >>> expression is automatically picked. >>> >>> I could not reproduce the issue you report with the spaces. In my >>> image when I select a full expression whitespaces at start and end do >>> not matter. >>> >>> Lukas >>> >>> On Tuesday, August 3, 2010, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>> >>> Lukas - I logged it as issue 2742 (now that I know its a bit picky, I'll select extra spaces as a workaround). >>> >>> Some day I will learn how some of this works so that I can try and help out (from my time spent in Dolphin where RB is tightly integrated, it was cool messing around with parse nodes to drive better UI tools). >>> >>> Tim >>> >>> >>> >>> I don't see that difference with the space, but it is true that you >>> need to select a valid expression to get the menu items enabled. In >>> that regard, the conditions could probably be relaxed a bit. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 >>> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > > "From an abstract enough point of view, any two things are similar." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 3, 2010

Re: [Pharo-project] eCompletion tweak for smart characters

by StÃ©phane Ducasse

tx! On Aug 3, 2010, at 1:35 PM, Tim Mackinnon wrote: > I never noticed that.... (slaps his forehead - it is a wiki after all). I'll make those changes. > > Tim > > On 3 Aug 2010, at 12:18, Serge Stinckwich wrote: > >> If you register as a developper on the Google code website, you could >> modify the wiki by yourself ;-) >> >> 2010/8/3 Tim Mackinnon <tamackinnon(a)gmail.com>: >>> >>> always create an issue else we forget.... too much stuff to do. >>> Then conversation is always good. Because we build a shared mindset and we >>> all learn together >>> >>> OK - done (2743) - I followed the instructions >>> on http://code.google.com/p/pharo/wiki/HowToContribute - which are great (by >>> the way there are a few typos in that text, and here are simple corrections >>> - i think its fairly easy to spot the sections they replace): >>> You can find the license that you should sign >>> here: http://code.google.com/p/pharo/wiki/LicenseAgreement. >>> We value your fixes and we always try to look at them and give feedback to >>> you, this works best if you create a bug entry in the bug tracker. Without >>> it we may have problem giving you feedback or letting you know that there is >>> another fix. >>> The most important point is that you check your fix in a fresh (probably >>> latest) image. There are two alternatives to packaging your code: You can >>> send a changeset or a set of packages. For complex changes that involves >>> several packages use a slice as there is a much better merging support. >>> While we prefer packages, if it is easier for you send changesets, then we >>> accept those too. >>> Prepare a changeset with your changes. File it out. Important: Put your Full >>> name instead of your initials, as it will help up to contact you which is >>> often necessary. Only alphabetical characters, and Do Not use any spaces. >>> >>> >>> Tim >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> 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

Aug. 3, 2010

[Pharo-project] [update 1.2] #12075

by StÃ©phane Ducasse

12075 ----- - Issue 2296: Point>>closeTo. Thanks Alexandre Bergel and Henrik Johanssen. - SUnit Announcement post fix. - Issue 2617: Fix restart in blocks in debugger. Thanks Henrik Johanssen. - Issue 2364: FileList menu more... is bogus. Thanks Carlo Teixeira - Issue 1767: Method Finder gives UndefinedObject error on search. Thanks Alexandre Bergel. Thanks Marcus, patchinko and Gary. Stef

Aug. 3, 2010

Re: [Pharo-project] update to OCompletion

by Alexandre Bergel

> This greatly improves usability. Actually, you must have changed something else too because when I hit the third time the down arrow, it is significantly faster than before. It was sometimes the case that the image would hang for even tens of seconds, but now everything is pretty snappy. Yes, it has something to do with preferences. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 3, 2010

Re: [Pharo-project] Extending SUnit [was Re: Autotest, proof-of-concept [was: About TDD and Pharo]]

by Alexandre Bergel

> alex my question was more naive and probably it shows that I do not know how the announce protocol should be implemented > but why do you have to record them? The purpose of an announcer is to dispatch events. Callbacks are registered in an announcer, and an announcer receives and dispatch events to the callbacks. In my enh, each unit test (subclass of TestCase) has an announcer. Maybe this is not a good strategy. Having one global announcer for unit test may be more convenient in some situations. Something nice, is that if there is no callback registered, events are not emitted. This means that this should incur no overhead (even though I did not measured). Cheers, Alexandre > >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 3, 2010