July 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Cannot change ivars with inspector

by Oscar Nierstrasz

If you open an inspector on a morph and try to edit the bounds, you get will the following error: OTNamedVariableNode(Object)>>doesNotUnderstand: #selectedClass Is this correct behaviour? [In Squeak by Example, we had an example where we did this.] - on

July 2, 2009

[Pharo-project] Inspector values do not update dynamically anymore

by Oscar Nierstrasz

If I inspect a morph and focus on the bounds variable, then move the morph, the bounds do not update dynamically as they used to in Squeak. Is notification broken? - on

July 2, 2009

[Pharo-project] What will be the standard browser in Pharo?

by Oscar Nierstrasz

Hi Folks, I am trying to port Squeak by Example to Pharo by Example. I am a bit confused about what is suppose dto be the standard browser now. I thought it was the OB Package Browser, but Damien Cassou just gave me a new image where the browser is an OB System Browser (Categories, not packages). I cannot even see any more how to switch between the two. Can someone enlighten me? (Then I can explain it in the book.) - on

July 2, 2009

[Pharo-project] Behavior>>formatterClass makes no sense for togglePrettyPrint

by Oscar Nierstrasz

Behavior>>formatterClass ^Preferences useRBASTForPrettyPrint ifFalse: [ self compilerClass ] ifTrue: [ RBParser ] This makes no sense for view > prettyPrint which expects the class to implement #format:in:notifying:contentsSymbol: (only implemented by RBParser). - on

July 2, 2009

Re: [Pharo-project] Pharo coding party

by StÃ©phane Ducasse

We are the ninja turtle teenagers :) But some actions is good after too much talks at conference and far too much food :) On Jul 2, 2009, at 7:18 PM, Damien Cassou wrote: > Damien P, StÃ©phane D and me are doing a Pharo coding party to kill > some bugs. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 2, 2009

[Pharo-project] Pharo coding party

by Damien Cassou

Damien P, StÃ©phane D and me are doing a Pharo coding party to kill some bugs. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 2, 2009

Re: [Pharo-project] Fonts directory necessary in pharo-dev

by John M McIntosh

On 2-Jul-09, at 3:51 AM, Michael Rueger wrote: > The Sophie FileLocations package has a call to find the platform > specific font directory (or even directories?). I've not looked but I think it's *directories* since the user can have a font directory. We also kept a list of the found font meta-data in memory, so on restart we would merge our list and the results of the startup font directory parsing. If fonts deleted, fine we delete from our meta-data If no changes nothing much happens other than connecting back up the font to font file pointers If fonts added, we would create new font instances for the new font files. Otherwise setting up 462 font instances for those mac users who have just a few fonts on their machines was way too time consuming -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 2, 2009

Re: [Pharo-project] FasterSets

by Henrik Johansen

I submit for your consideration the use case where you want to initialize a Set with elements from multiple sources. How do you do that today? Well, you could write set := (Set withAll: source1) addAll: source2; addAll: source3... etc, which will surely cause quite some grows. (and also crashes if source1 has more elements than implementation limits) A few other options: set := Set new: (sources inject: 0 into: [:sub :next | sub + next size]). sources do: [:each | set addAll: each ] or: tmpWithAllToAdd := sources inject: OrderedCollection new into: [:sub : next | sub addAll: next; yourself]. set := Set withAll: tmpAllToAdd which doesn't perform excessive grows, but still would crash if total size of sources is bigger than implementation limits. So how are these better than modifying addAll: so you can write set := Set new. sources do: [:each | set addAll: each] and not worry too much how much your set spends on growing/checking if it needs to grow? You could always min: with current implementation limit of Set size if you think it's likely that's a case you'll encounter... And my point was really, I'd rather have an error telling me "Hey, you're trying to do something EXTREME" (like, trying to add (in VW) more than 2^28 (2^56 on 64bit) elements to a set) than have my program stop for a large amount of time, then finishing "correctly"... Cheers, Henry On Jul 2, 2009, at 4:16 50PM, Andres Valloud wrote: > However, handling the growth failure wouldn't crash the program... > > Henrik Johansen wrote: >> It would. >> I'm not sure I consider the current behaviour of spending 12 minutes >> adding the same element so much better, though. >> >> Cheers, >> Henry >> >> On Jul 2, 2009, at 12:17 14PM, Andres Valloud wrote: >> >> >>> Also, what happens in these cases? >>> >>> | set | >>> set := Set new. >>> bag := Bag new. >>> bad add: 4 withOccurrences: 1000000000 "or equivalent code". >>> set addAll: bag >>> >>> I am guessing the set will fail to grow and addAll: will fail, even >>> though it should work. Maybe it won't happen with bags, or perhaps >>> the >>> example needs some massaging. Is the failure to grow handled >>> gracefully? Note that I have not looked at the code because I have >>> not >>> had much chance to do that yet. >>> >>> Andres Valloud wrote: >>> >>>> Hmmm, I don't know though, usually the usage pattern with hashed >>>> collections has been to presize explicitly and then add to them... >>>> what >>>> kind of use cases are you dealing with? >>>> >>>> Henrik Johansen wrote: >>>> >>>> >>>>> Having spent a fair deal of time (in VisualWorks) worrying about >>>>> my >>>>> intial Set sizes, writing functions to precompute sane sizes for >>>>> arbitrary inputs and adding changeCapacityTo: calls before addAll: >>>>> operations due to performance issues on a case-by-case basis >>>>> (Squeak/ >>>>> Pharo doesn't even HAVE a changeCapacityTo: ), I have to strongly >>>>> disagree. >>>>> >>>>> I'd rather spend my time thinking about my problem domain, and >>>>> know >>>>> the Set implementation handles the nitty-gritty details in a >>>>> sufficiently smart way. >>>>> >>>>> Whether that means growing once to accomedate the worst case, then >>>>> shrinking afterwards, or doing a grow check every X added items, >>>>> in >>>>> the unlikely event that what you're adding is a 3 million element >>>>> Array with 10 unique objects, I don't really care. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> On Jul 2, 2009, at 7:38 10AM, Andres Valloud wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> (Set new: desiredCapacity) addAll: "consecutive integers" >>>>>> >>>>>> may be a better compromise. >>>>>> >>>>>> Andres. >>>>>> >>>>>> >>>>>> StÃ©phane Ducasse wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Thanks this is really good. >>>>>>> We will probably integrate these changes really fast >>>>>>> >>>>>>> On Jul 1, 2009, at 1:03 PM, Henrik Johansen wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I took some time to check this yesterday, my comments on the >>>>>>>> code >>>>>>>> itself are basically the same as what Lucas posted in the issue >>>>>>>> tracker. >>>>>>>> Works as advertised, but should probably clean out the "gunk" >>>>>>>> which is >>>>>>>> unused after it's integrated. >>>>>>>> >>>>>>>> Some feedback on possible improvements: >>>>>>>> - What it does, is basically speed up the adds to the new array >>>>>>>> in a >>>>>>>> grow that might happen Why not take this all to the logical >>>>>>>> conclusion, and instead optimize an addAll: method to be used >>>>>>>> in >>>>>>>> grow, >>>>>>>> that assumes elements are not in set (and themselves are not >>>>>>>> duplicates)? F.ex. it could also add to tally just once, >>>>>>>> instead of >>>>>>>> one increase per element as the noCompareAdd: does. (an add >>>>>>>> method >>>>>>>> with no tally add, no = object check, and no growCheck). >>>>>>>> >>>>>>>> - The usual addAll: method can be sped up in a similar way, by >>>>>>>> performing one grow operation before adding elements if >>>>>>>> necessary >>>>>>>> (pessimistically assuming all elements are unique), then use an >>>>>>>> add >>>>>>>> method which does not check for grow need at all. (an add >>>>>>>> method >>>>>>>> with >>>>>>>> tally add and = object check, but no growCheck) >>>>>>>> If desirable, you could also shrink the capacity after adds are >>>>>>>> done, to match the real amount of new elements. >>>>>>>> >>>>>>>> Adding (1 to: 1200000) to a new Set with such an addAll: method >>>>>>>> took >>>>>>>> 1/2 to 1/3rd the time of the regular addAll: method, even with >>>>>>>> the >>>>>>>> lower grow cost of FasterSets. (Lower gains if Set is presized, >>>>>>>> and if >>>>>>>> hash-calculation is bigger part of cost) >>>>>>>> >>>>>>>> Note: If you want to stay ANSI-compatible, one tricky point in >>>>>>>> such an >>>>>>>> optimization is adding all objects in collection up to a nil >>>>>>>> element, >>>>>>>> then raising an error. (ie: must produce equivalent results to >>>>>>>> add: >>>>>>>> performed of each of collections elements in sequence ) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Henry >>>>>>>> >>>>>>>> >>>>>>>> On Jun 25, 2009, at 8:55 03PM, StÃ©phane Ducasse wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I would really like to assess FasterSets for Pharo1.1 >>>>>>>>> >>>>>>>>> Begin forwarded message: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> From: Ralph Boland <rpboland(a)gmail.com> >>>>>>>>>> Date: June 25, 2009 8:30:13 PM CEDT >>>>>>>>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>>>>>>>> Subject: Re: about fasterTests >>>>>>>>>> >>>>>>>>>> 2009/6/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> we are interest to get better libraries in pharo. >>>>>>>>>>> If you want to join and help making sure that your code in >>>>>>>>>>> integrated in >>>>>>>>>>> pharo1.1 >>>>>>>>>>> please say it and may be join the pharo mailing-list. >>>>>>>>>>> >>>>>>>>>>> Stef >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yes, I would like my code 'FasterSets' added to Pharo. >>>>>>>>>> I joined the pharo mailing list. >>>>>>>>>> Today I will mail you my MIT license release. >>>>>>>>>> Probably will take a couple of weeks (From Calgary, Canada) >>>>>>>>>> to get >>>>>>>>>> there. >>>>>>>>>> Once I am added as a contributer I will release my code to >>>>>>>>>> Pharo >>>>>>>>>> for >>>>>>>>>> verification. >>>>>>>>>> In the meantime if any Squeakers try out my code and report >>>>>>>>>> bugs I >>>>>>>>>> will fix them >>>>>>>>>> before releasing to Pharo. >>>>>>>>>> >>>>>>>>>> Some comments: >>>>>>>>>> >>>>>>>>>> 1) Since FasterSets modifies low level methods in class Set >>>>>>>>>> and >>>>>>>>>> its >>>>>>>>>> subclasses it >>>>>>>>>> may be incompatible with packages that create subclasses of >>>>>>>>>> Set >>>>>>>>>> and then >>>>>>>>>> override low level methods. If someone could send me a >>>>>>>>>> list of >>>>>>>>>> package add-ons >>>>>>>>>> to Pharo that do this then I can download them and make any >>>>>>>>>> modifications >>>>>>>>>> necessary for them to run with FasterSets and make these >>>>>>>>>> changes >>>>>>>>>> part of my >>>>>>>>>> release. Note that it is no more difficult to subclass from >>>>>>>>>> Set >>>>>>>>>> with FasterSets >>>>>>>>>> than without; it is just different and only different if you >>>>>>>>>> do >>>>>>>>>> low level things. >>>>>>>>>> >>>>>>>>>> 2) FasterSets uses a method 'noCompareOrGrowAdd:' which >>>>>>>>>> adds >>>>>>>>>> an element to a set without doing compares or growing the >>>>>>>>>> set. >>>>>>>>>> Needless to say it is a private method. >>>>>>>>>> I also have a public method 'nastyAddNew:' which, like >>>>>>>>>> 'noCompareOrGrowAdd:' adds an element to a set without >>>>>>>>>> checking >>>>>>>>>> if the >>>>>>>>>> element is already there but does do a grow if needed. >>>>>>>>>> This is useful (i.e. faster) in situations where you KNOW the >>>>>>>>>> object >>>>>>>>>> you are adding to a set is not there already. >>>>>>>>>> However if the object IS already there then you now have two >>>>>>>>>> of them in your set; i.e. you now have a subtle bug. >>>>>>>>>> I use 'nastyAddNew:' in my code but never made it a part of >>>>>>>>>> FasterSets >>>>>>>>>> because it is questionable whether or not such a method >>>>>>>>>> should be >>>>>>>>>> available generally. However, if I can decide I like the >>>>>>>>>> 'nastyAddNew:' >>>>>>>>>> method and am willing to use it despite its risks so can >>>>>>>>>> others >>>>>>>>>> so there >>>>>>>>>> is an argument for it being added. >>>>>>>>>> While my expectation is that you don't want >>>>>>>>>> 'nastyAddNew:' in >>>>>>>>>> Pharo >>>>>>>>>> I thought you should at least be aware of it. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ralph Boland >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >

July 2, 2009

Re: [Pharo-project] Pharo VM setup problem: where is pharo-vm-0.15.1b-linux source package available?

by StÃ©phane Ducasse

Thanks for the idea. this would be nice to have a pointer to a forge for the vm code. Stef > Hi Mariano, > > I welcome your decision. More reasons: > > - Most linux distributions do not have a standard configuration. > If you cannot go through the configuration/make/install cycle, a > package may simply not run on a certain target system. > If you cannot go through these cycles, your possibilities to fix > that are very limited. > > - Without sources, consumers cannot directly contribute to the defect > tracking, fixing or development process > > > Cheers, > > Andreas > > > > Mariano Martinez Peck schrieb: >> I also think adding sources to Pharo webpage is a good idea. I saw >> a lot of >> people, who say "I wont use an enviorment in production that I >> cannot have >> the code and build it by myself". And I think they are correct! >> >> >> On Wed, Jul 1, 2009 at 2:33 PM, Andreas Leidig <Andreas.Leidig(a)gmx.net >> >wrote: >> >>> Dear List, >>> >>> who has/where is pharo-vm-0.15.1b-linux source package? >>> >>> I have a setup problem which I think I can determine or even solve >>> with >>> the sources. >>> >>> >>> Cheers, >>> >>> Andreas >>> >>> >>> _______________________________________________ >>> 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

July 2, 2009

[Pharo-project] [ANN] 10345 and 10346 Arithmetic

by StÃ©phane Ducasse

Hi all Here are some integrations: Fix and test http://bugs.squeak.org/view.php?id=3374 aka http://code.google.com/p/pharo/issues/detail?id=876 Thanks nicolas for your contributions to make the system better. Stef PS: making chicken steps the system better and more agile

July 2, 2009