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

[Pharo-project] PharoCorePackageDependenciesTests make tests with packages not presents in pharo 1.2

by Cyrille Delaunay

Several tests from PharoCorePackageDependenciesTests raise errors because it specify packages not present in pharo 1.2: 'AST-Tests-Core' 'AST-Core' 'AST-Semantic' The error come from: referencesInPackageNamed: pkgNameAsString | pi | pi := PackageOrganizer default packageNamed: pkgNameAsString ifAbsent: [^ self]. .... The package is not found, therefore it returns 'self', later in the code we iterate on that 'self', it raise a DNU Message. Maybe rather that returning self, we should return a more explicit error so that we know directly where does the problem comes from? Anyway, I guess the main problem here is that the packages specified are not present in the image? I opened an issue:http://code.google.com/p/pharo/issues/detail?id=3033

Oct. 1, 2010

Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1

by Eliot Miranda

Hi Mariano, 2010/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo > 1.1 but based on PharoCore 1.1.1. The versions of the external packages is > the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has > integrated some fixes and the support for CogVM. This means that > Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For > CogVM we recommend to use the last binaries that can be found in > http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is > http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ > > This CogVM version fixes the problem with "Objects as methods", and thus, > all the #run:with:with are working. This means that tools like TestCoverage > and AutoTest are working correctly with CogVM. > WHile some simple things now work there's definitely at least one bug remaining (perform:withArguments: doesn't work for objects-as-methods) and Nicolas tried a more demanding test (the coverage test from XTreams) and found problems; see http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033230.…. I'll be releasing a new VM that will fix the perform issue, but it remains to be seen whether the bugs Nicolas as found are fixed by this. So while .33 is better Cog still doesn't support objects-as-method correctly. HTH Eliot > The link to the image is: > https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2010

Re: [Pharo-project] [Vm-dev] Re: is it possible to know the memory occupation (bytes) of an object?

by Mariano Martinez Peck

Ok...I have just commited. If you want to review: http://code.google.com/p/pharo/issues/detail?id=3032 cheers Mariano On Tue, Sep 28, 2010 at 1:45 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Sep 28, 2010 at 11:11 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> >> >> On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote: >> >> >> >> On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >>> 2010/9/27 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> > >>> > >>> > >>> > On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >> >>> >> >>> >> >>> >> >>> >> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> >>> >>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen < >>> henrik.s.johansen(a)veloxit.no> wrote: >>> >>>> >>> >>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote: >>> >>>> >>> >>>> > Some notes: >>> >>>> > >>> >>>> > - What should be answered for small ints? 1 sizeInMemory -->8. >>> That's wrong. Shouldn't this answer 0? >>> >>>> >>> >>>> Philosophical question really, imo both 4 (Again, in 32bit images at >>> least) and 0 would be "correct" answers in their own ways. 8 is definitely >>> wrong though :) >>> >>>> The method comment should probably highlight which definition is >>> used. >>> >>>> >>> >> >>> >> >>> >> So....what should we consider for SmallInteger ? 4 bytes or 0 bytes? >>> > >>> > 0 bytes, obviously. The only space occupied by a SmallInteger is the >>> space of the slot containing it. There is no SmallInteger object beyond the >>> slot. >>> > >>> >>> Or from another POV, it's 4, the size of the slot. But we don't count >>> the size of the slots, they are already counted in the containing >>> object, that's why it should answer 0. >>> >> >> >> Thanks for the answers. I finally let this: >> >> sizeInMemory >> "Answer the number of bytes consumed by this instance including object >> header." >> | isCompact headerBytes contentBytes | >> >> "SmallInteger occupy 0 bytes since the only space occupied by a >> SmallInteger is the space of the slot containing it. There is no >> SmallInteger object beyond the slot. From another POV, it could be 4, the >> size of the slot. But we don't count the size of the slots, they are already >> counted in the containing object, that's why it should answer 0." >> (self isMemberOf: SmallInteger) ifTrue: [^0]. >> >> contentBytes := self class instSize * Smalltalk wordSize. "inst vars" >> >> self class isVariable ifTrue:[ |bytesPerElement| >> bytesPerElement := self class isBytes ifTrue: [1] ifFalse: >> [4]. >> contentBytes := contentBytes + (self basicSize * >> bytesPerElement)]. >> >> isCompact := self class indexIfCompact > 0. >> headerBytes := >> contentBytes > 255 >> ifTrue: [ 3 * Smalltalk wordSize ] >> ifFalse: [isCompact ifTrue: [Smalltalk wordSize] >> ifFalse: [2 * Smalltalk wordSize]]. >> ^ headerBytes + contentBytes >> >> >> Now I wonder...maybe instead of doing this it is easier to have a >> primitive that just calls #internalByteSize: ? >> The problem of course is that it needs changes in the vm... >> >> cheers >> >> Mariano >> >> >> isMemberOf: is so quaint... >> >> Why not >> SmallInteger>>sizeInMemory >> "SmallInteger occupy 0 bytes since the only space occupied by a >> SmallInteger is the space of the slot containing it. >> There is no SmallInteger object beyond the slot. >> From another POV, it could be 4, the size of the slot. But we don't >> count the size of the slots, they are already counted in the containing >> object, that's why it should answer 0." >> ^0 >> >> and remove that part from the Object implementation. >> >> > Uffff thanks Henrik for enlight me and teach me. Shame on me. I think that > too much paper writting, ppt and admin tasks are killing me :( > But don't worry, now I will come to code again! Hope to recover... :) > > > >> Cheers, >> Henry >> >> >

Oct. 1, 2010

Re: [Pharo-project] NativeBoost and Cog. A working protype.

by stephen＠pairhome.net

On Oct 1, 2010, at 2:39 AM, "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> wrote: > Sig, > > I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't. Regarding syntax, I'm all in favor of using special purpose languages where it makes sense (but my intuition says that should be done sparingly or else everything will degenerate into an incomprehensible mess). In this case it would be very nice to think about a language designed specifically for expressing mathematical expressions rather than C++ (which btw I don't agree is better for expressing formulas...it's just different and perhaps closer to conventional mathematical syntax). Regarding performance, I think it's entirely possible to get similar performance to C++ in Smalltalk (or just about any other language for that matter)...however, I'm not aware of anything that can do this today. You could deal with the boxing/unboxing overhead with a sufficient amount of inlining based on runtime type analysis. Once fully inlined, you can apply more traditional optimization techniques. I don't even think this would be particularly hard to do (and to a degree it's all been done before), but it is a lot of work. As I said, I'm not aware of anything readily available that achieves these things. So, to get the performance you seek in a slightly more pleasing syntax (beauty is in the eye of the beholder), C++ may be your best bet for now. - Stephen

Oct. 1, 2010

Re: [Pharo-project] CodeMorph >> text should return an instance of Text but return a String

by Fernando olivero

Yes, i've been busy so i couldn't finish this issue. Because CodeMorph comes from Gaucho, and until now there was no need for it in the Pharo-Core. so i will remove it, and possibly when the need arises will propose its re-inclusion. Fernando pd: the idea behind CodeMorph is to have a specialized NewTextMorph for dealing with Methods sources, Class definitions. But now i have second thoughts, because i have the impression that having diferent Editors ( subclasses of TextEditor or SmalltalkEditor) should do the trick. On Oct 1, 2010, at 12:02 PM, Cyrille Delaunay wrote: > I just saw that there is propositions to remove CodeMorph: > > http://code.google.com/p/pharo/issues/detail?id=2902&q=CodeMorph&colspec=ID… > > So maybe the best fix will be to remove all the tests related ? :) > > 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> > In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error. This error happen when calling: > > CodeMorph >> defaultStyledText > | text attribute | > text := self text. > text addAttribute: ( self newTextColorAttribute: Color black ). > ^ text. > > text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: > > beFullMethodName > aspect := #selector. > adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. > > The block return a String and I guess the right code should be > > beFullMethodName > aspect := #selector. > adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] > > ??. > > I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 > > <ATT00001..txt>

Oct. 1, 2010

Re: [Pharo-project] [update 1.2] #12161 - #12172

by Igor Stasenko

2010/10/1 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 1 Oct 2010, Igor Stasenko wrote: > >> On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Fri, 1 Oct 2010, Marcus Denker wrote: >> >>> Issue 3002: Â Â A new finalization code ready for integration in Pharo >>> Issue 3026: after 12172, sync with repository and reload >> >> If you didn't fix the migration code, then WeakFinalizationRegistry is >> still >> in the system. Details here: >> >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400… >> > You mean this not work: > Â Â Â Â Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. > > should be > Â Â Â Â Smalltalk forgetClass: WeakFinalizationRegistry logged: false. > > right? > > > Yes. > > Thanks for noticing. > Levente > >> >> Levente >> >>> >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 > _______________________________________________ > 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.

Oct. 1, 2010

Re: [Pharo-project] [update 1.2] #12161 - #12172

by Levente Uzonyi

On Fri, 1 Oct 2010, Igor Stasenko wrote: > On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 1 Oct 2010, Marcus Denker wrote: > >> Issue 3002: Â Â A new finalization code ready for integration in Pharo >> Issue 3026: after 12172, sync with repository and reload > > If you didn't fix the migration code, then WeakFinalizationRegistry is still > in the system. Details here: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400… > You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Levente > > Levente > >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> 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 > -- 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

Oct. 1, 2010

[Pharo-project] [update 1.2] #12174

by Marcus Denker

12174 ----- Issue 2713: Changelist deserves some fixes Issue 3030: Remove Explain... code (again) Issue 3023: change the initial windows position strategy Issue 3028: PluggableListMorphByItem >> getCurrentSelectionIndex access directly a non-initailized instance variable -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 1, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Mariano Martinez Peck

On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 1 Oct 2010, Mariano Martinez Peck wrote: > > Thanks to everybody. I did what you say and now >> >> MessageTally time: [ECContextTest new testUntypedVarsOnly] -> 3023 >> >> I've just commited OCompletion. >> >> And I didn't know TimeProfiler :) >> > > If you download > http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get > better results: > > [ ECContextTest new testUntypedVarsOnly ] timeToRun "===> 815" > > Excellent. Thanks Levente > > Levente > > > >> cheers >> >> Mariano >> >> On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>> >>> On 28.09.2010 01:43, Levente Uzonyi wrote: >>> >>>> >>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>>>> >>>>> On 28.09.2010 00:41, Levente Uzonyi wrote: >>>>> >>>>>> >>>>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>>>>>> >>>>>>> On 28.09.2010 00:07, Levente Uzonyi wrote: >>>>>>> >>>>>>>> >>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>>>>> >>>>>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> IF you take a 1.1 core and just load OCompletion: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] >>>>>>>>>>>> 20907 >>>>>>>>>>>> >>>>>>>>>>>> If you load OCompletion and the rest of the dev image: >>>>>>>>>>>> >>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] >>>>>>>>>>>> 100137 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> However, IN pharo dev 1.0 it is >>>>>>>>>>>> >>>>>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> sooo.... ???? >>>>>>>>>>>> >>>>>>>>>>>> something has changed? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As I said, SortedCollection is not suitable for this kind of >>>>>>>>>>> usage. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But in Pharo 1.0 OCompletion was doing the same....so? did >>>>>>>>>> SortedCollection >>>>>>>>>> chang between 1.0 and 1.1? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> No, something else changed. The same test is still 5x faster in 1.0 >>>>>>>>> dev with the new code. >>>>>>>>> >>>>>>>>> TimeProfiler to the rescue: >>>>>>>> Preferences class >> ecompletionCaseSensitive >>>>>>>> 1.0: (1725ms) >>>>>>>> 1.1 (19724ms) >>>>>>>> >>>>>>>> Preference>>settingValue which is there for backwards-compatability >>>>>>>> in >>>>>>>> 1.1 does both symbol creation and respondsTo:, so yeah, it's much >>>>>>>> slower >>>>>>>> than the old dictionary lookup. >>>>>>>> >>>>>>>> >>>>>>> Nice find. If you check my code, you'll find that I optimized that >>>>>>> away. :) >>>>>>> >>>>>>> >>>>>>> Levente >>>>>>> >>>>>>> Yes ,you moved it out of the actual sort loop :) >>>>>> Rewrite the methods in ECPreferences to use the new syntax: >>>>>> <preference: category: description: type:>, and you shouldn't even >>>>>> have >>>>>> to do that to get ok performance. >>>>>> >>>>>> IMHO, it's rather disturbing to see things like EC, where its >>>>>> preferences are actually separated tucked away in an ECPreferences >>>>>> class, >>>>>> only to be delegated from there over to Preferences... >>>>>> >>>>>> >>>>> The preferences should be updated, but sending a message once is still >>>>> better than 2k-30k times. >>>>> >>>>> >>>>> Levente >>>>> >>>>> Sure, on the order of a couple of milliseconds difference. >>>> I keep forgetting the fact we generally have different definitions of >>>> what >>>> constitutes "ok performance" ;) >>>> >>>> >>> 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick >>> image has 3220 globals. The sortBlock asks for the preference twice per >>> evaluation. SortedCollection uses a binary search during #add:. If we are >>> optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 >>> times >>> which is ~75k. >>> >>> In the same image the "old" code asked for the preference 2282899 times >>> during the tests, while the new code did it only 398 times. If the >>> preference is changed to return the value of a variable, then the >>> difference >>> is only 80 ms, otherwise it's 36.6 seconds. >>> >>> >>> Levente >>> >>> >>> >>> 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 >

Oct. 1, 2010

Re: [Pharo-project] CodeMorph >> text should return an instance of Text but return a String

by Cyrille Delaunay

I just saw that there is propositions to remove CodeMorph: http://code.google.com/p/pharo/issues/detail?id=2902&q=CodeMorph&colspec=ID… So maybe the best fix will be to remove all the tests related ? :) 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> > In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error. This error happen when calling: > > CodeMorph >> defaultStyledText > | text attribute | > text := self text. > text addAttribute: ( self newTextColorAttribute: Color black ). > ^ text. > > text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: > > beFullMethodName > aspect := #selector. > adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. > > The block return a String and I guess the right code should be > > beFullMethodName > aspect := #selector. > adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] > > ??. > > > I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 > >

Oct. 1, 2010