March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] TestCase>>#assert:equals: optimization

by Nicolas Cellier

Being able to automate is very good, however... <rant> I find a great deal of issues report are unhelpful, not to say totally useless. Take for example http://code.google.com/p/pharo/issues/detail?id=5482 it just tells, "hey look at the fix in this slice, and you'll understand" Then some bits of status (integrated, closed...). Generally the code is not even accessible from within the bug report (unless of few cases of change sets...) What do we learn from such reports? Do we find a rationale justifying the change? Do we only even guess the intention by just reading the report? What does this bring exactly to the process quality? If we just have to look at the code, then follow something light like squeak/trunk, just publish diffs and don't bother with pseudo-quality disguise. One huge progress would be the possibility to navigate across continuous integration server, issue tracker, source code repository, and so called ScriptLoader containing the list of fixes applied from one version to another... Tracking a regression down, seeing in which version it happened, what did change in this version, browsing the related issue in the tracker to understand the rationale of the change, and browsing the code diffs, all this directly from the web pages would help a lot... Of course, if reports are empty or cryptic, then maybe they can still feed bots, but don't expect help of humans too much ;) </rant> Nicolas Le 15 mars 2012 22:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > thanks stefan > Can you open a bug tracker and publish your code with a slice or a cs so > that our crawler can handle it automatically? > Yes we are getting professional thanks for camillo and ben :) > > Stef > > On Mar 15, 2012, at 8:58 PM, Stefan Marr wrote: > > > Hi: > > > > While stepping through bytecodes, I noticed a slightly annoying > inefficiency in the SUnit implementation. > > The description string in #assert:equals: is always computed, even if it > is not necessary. > > > > While that might not be a performance problem, I find it rather > distracting when I have to debug on the bytecode/VM level. > > > > Since there seem to be only 127 senders or so in the image, you will > probably not notice a big performance gain. > > The change to compute the string only when necessary is below. > > > > Best regards > > Stefan > > > > PS: This is a resend, because the original mail seemed to have been > lost, while the mailing list was down. > > > > > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:41'! > > assert: aBooleanOrBlock description: aStringOrBlock > > aBooleanOrBlock value ifFalse: [ > > | aString | > > aString := aStringOrBlock value. > > self logFailure: aString. > > TestResult failure signal: aString] > > ! ! > > > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! > > assert: aBooleanOrBlock description: aStringOrBlock resumable: > resumableBoolean > > | exception | > > aBooleanOrBlock value > > ifFalse: > > [|aString| > > aString := aStringOrBlock value. > > self logFailure: aString. > > exception := resumableBoolean > > ifTrue: [TestResult > resumableFailure] > > ifFalse: [TestResult > failure]. > > exception signal: aString] > > ! ! > > > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! > > assert: expected equals: actual > > ^ self > > assert: (expected = actual) > > description: [self comparingStringBetween: actual and: > expected] > > ! ! > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > >

March 15, 2012

Re: [Pharo-project] [Vm-dev] Finally, jenkins were able to build win32 VM.

by Eliot Miranda

Hi Tudor, On Thu, Mar 15, 2012 at 2:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > The problem is that I cannot get it for you because it's proprietary code, > and the issue raised when loading the code from a Monticello repository. > I sign non-disclosure agreements and destroy files once I'm done :) So if you can get it to crash loading from a package-cache and you're happy for me to sign an NDA I can still look at it. But only if you;re comfortable and only if you have a reproducible case. > I got some strange crashes in other contexts but without having time to > dig into these :(. I will try to keep my eyes opened and find some > reproducible case. > > Cheers, > Doru > cool. cheers! > > > On 15 Mar 2012, at 20:03, Igor Stasenko wrote: > > > > > On 15 March 2012 19:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> > >> > >> > >> On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> > >>> Strange. I tried to reproduce the problem, but following the same path > >>> worked fine the second time. > >> > >> > >> Such GC bugs are extremely sensitive to exactly the sequence of > mutations in the heap. So the time in between mouse clicks or keyboard > presses, or even the length of delays or the date and time can change the > form of the heap. The only way I know to reproduce this kind of bug > reliably is to write a doit that causes the system to crash without user > intervention. You can either supply the doit in a file to the VM at > startup or (more convenient for those debugging it) write a doit that > starts with a snapshot, e.g. > >> > >> Smalltalk saveAs. > >> Crasher new crash > >> > > > > Not again this flaky GC/become stuff. I was hoping that last one we > > busted in summer.. > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > > "No matter how many recipes we know, we still value a chef." > > > > > > > -- best, Eliot

March 15, 2012

Re: [Pharo-project] [Vm-dev] Finally, jenkins were able to build win32 VM.

by Tudor Girba

Hi, The problem is that I cannot get it for you because it's proprietary code, and the issue raised when loading the code from a Monticello repository. I got some strange crashes in other contexts but without having time to dig into these :(. I will try to keep my eyes opened and find some reproducible case. Cheers, Doru On 15 Mar 2012, at 20:03, Igor Stasenko wrote: > > On 15 March 2012 19:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> On Tue, Mar 13, 2012 at 7:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Strange. I tried to reproduce the problem, but following the same path >>> worked fine the second time. >> >> >> Such GC bugs are extremely sensitive to exactly the sequence of mutations in the heap. So the time in between mouse clicks or keyboard presses, or even the length of delays or the date and time can change the form of the heap. The only way I know to reproduce this kind of bug reliably is to write a doit that causes the system to crash without user intervention. You can either supply the doit in a file to the VM at startup or (more convenient for those debugging it) write a doit that starts with a snapshot, e.g. >> >> Smalltalk saveAs. >> Crasher new crash >> > > Not again this flaky GC/become stuff. I was hoping that last one we > busted in summer.. > > > -- > Best regards, > Igor Stasenko. -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

March 15, 2012

Re: [Pharo-project] TestCase>>#assert:equals: optimization

by StÃ©phane Ducasse

thanks stefan Can you open a bug tracker and publish your code with a slice or a cs so that our crawler can handle it automatically? Yes we are getting professional thanks for camillo and ben :) Stef On Mar 15, 2012, at 8:58 PM, Stefan Marr wrote: > Hi: > > While stepping through bytecodes, I noticed a slightly annoying inefficiency in the SUnit implementation. > The description string in #assert:equals: is always computed, even if it is not necessary. > > While that might not be a performance problem, I find it rather distracting when I have to debug on the bytecode/VM level. > > Since there seem to be only 127 senders or so in the image, you will probably not notice a big performance gain. > The change to compute the string only when necessary is below. > > Best regards > Stefan > > PS: This is a resend, because the original mail seemed to have been lost, while the mailing list was down. > > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:41'! > assert: aBooleanOrBlock description: aStringOrBlock > aBooleanOrBlock value ifFalse: [ > | aString | > aString := aStringOrBlock value. > self logFailure: aString. > TestResult failure signal: aString] > ! ! > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! > assert: aBooleanOrBlock description: aStringOrBlock resumable: resumableBoolean > | exception | > aBooleanOrBlock value > ifFalse: > [|aString| > aString := aStringOrBlock value. > self logFailure: aString. > exception := resumableBoolean > ifTrue: [TestResult resumableFailure] > ifFalse: [TestResult failure]. > exception signal: aString] > ! ! > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! > assert: expected equals: actual > ^ self > assert: (expected = actual) > description: [self comparingStringBetween: actual and: expected] > ! ! > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

March 15, 2012

Re: [Pharo-project] Extending SystemBrowser

by StÃ©phane Ducasse

On Mar 13, 2012, at 9:21 PM, Ezequiel Lamonica wrote: > Hi everybody, > > I have some problems to extend the SystemBrowser. > I want to add a panel at the left of package panel to list products. > Product is a new concept that I created to manage a group of packages. > > For example, Pharo is a product and Seaside is another that depends on Pharo. > > This is the path that I want to follow: > Products -> Packages -> Classes -> Protocols -> Methods > > I know in Pharo 1.4 the systemBrowser will be changed but I have a proof of concept early and I have to show something working integrated in Pharo 1.3 image. Use Glamour or Spec or OB but not systemBrowser. Run away from SystemBrowser > What could I do to start? > Any advice? > > >

March 15, 2012

Re: [Pharo-project] Finally, jenkins were able to build win32 VM.

by StÃ©phane Ducasse

not good :( because I'm sure it crashed on you the first time. Stef On Mar 13, 2012, at 3:44 PM, Tudor Girba wrote: > Strange. I tried to reproduce the problem, but following the same path > worked fine the second time. > > Doru > > > On Tue, Mar 13, 2012 at 3:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Ah, I forgot to mention: the same scenario works with the VM from Eliot (2522) >> >> Cheers, >> Doru >> >> On Tue, Mar 13, 2012 at 3:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> I just tried it and it crashed :(. >>> >>> Here is what I did: >>> - I took the Moose image >>> - it started fine, and seem to be responsive >>> - I then loaded code in it using a configuration >>> - while loading, it crashed >>> >>> I attach here the crash.dmp file. I cannot provide the actual code >>> because it is proprietary. I will try to reproduce the problem in more >>> available settings. >>> >>> Cheers, >>> Doru >>> >>> >>> On Tue, Mar 13, 2012 at 8:54 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> Thanks Igor. >>>>> Guys can you try and report if you have problems? >>>> >>>> Yes, thanks Igor, >>>> >>>> How can I see if this release integrates Eliots latest >>>> fixes for Cog? >>>> >>>> Thx >>>> T. >>>> -- >>>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 15, 2012

Re: [Pharo-project] MultiCompositionScanner depending on Morphic stuff

by StÃ©phane Ducasse

> Hi Guillermo, > > great to see someone to improve modularity of the system. :) We are always thinking. Now Guille will start a PhD with us :) > Look at > results of latest Pharo-Kernel: > > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%201.4/… > > This Undeclared clearly show unwelcome kernel dependencies and must be removed. > > Cheers, > -- Pavel > > > > On Thu, Mar 15, 2012 at 5:37 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> >> On Thu, Mar 15, 2012 at 1:34 PM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >>> >>> >>> On Mar 15, 2012, at 5:32 PM, Igor Stasenko wrote: >>> >>>> Hey, composition scanners and display scanners should not belong to >>>> Kernel. >>>> they should be either in graphics package or in morphic itself. >>>> >>>> Why we moved this stuff to kernel? >> >> >> :3 >> >> Actually CompositionScanner belong to Graphics, I was puzzled about that >> too. >> >> I'll post a slice in the inbox :) >> >>> >>> >>> >>> Nobody moved... they where always there. It's a mess of epic proportion, >>> our whole code base. >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> >

March 15, 2012

Re: [Pharo-project] Gettext package, who?

by Hilaire Fernandes

Le 15/03/2012 17:45, StÃ©phane Ducasse a Ã©crit : > What is the size of this package? The .mcz file is 26.7 kB -- Dr. Geo -- http://www.drgeo.eu

March 15, 2012

Re: [Pharo-project] [Vm-dev] Re: SystemTracer

by Eliot Miranda

I've attached my most up-to-date version. I'll add this to Squeak trunk pronto. On Thu, Mar 15, 2012 at 12:49 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > > > > On Thu, Mar 15, 2012 at 4:26 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Thu, Mar 15, 2012 at 1:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> Hi Guillermo, >>> >>> On Wed, Mar 14, 2012 at 12:48 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Hi Eliot, >>>> >>>> do you have a pointer of where can I see the differences between the >>>> old Squeak format and the cog image format, so I can make SystemTracer work >>>> on Cog vms? >>>> >>> >>> So the image format differences are >>> - floats are in platform order, not necessarily in big-endian order >>> - the layout of the specialObjectsArray is slightly different >>> (documented in recreateSpecialObjectsArray) >>> - there are more words in the header, see >>> StackInterpreter>writeImageFileIO:, i.e. >>> >>> in Cog: >>> self putLong: self imageFormatVersion toFile: f. >>> self putLong: headerSize toFile: f. >>> self putLong: imageBytes toFile: f. >>> self putLong: objectMemory startOfMemory toFile: f. >>> self putLong: objectMemory specialObjectsOop toFile: f. >>> self putLong: objectMemory newObjectHash toFile: f. >>> self putLong: self ioScreenSize toFile: f. >>> self putLong: self getImageHeaderFlags toFile: f. >>> self putLong: extraVMMemory toFile: f. >>> self putShort: desiredNumStackPages toFile: f. >>> self putShort: self unknownShortOrCodeSizeInKs toFile: f. >>> self putLong: desiredEdenBytes toFile: f. >>> self putShort: (maxExtSemTabSizeSet ifTrue: [self >>> ioGetMaxExtSemTableSize] ifFalse: [0]) toFile: f. >>> self putShort: 0 toFile: f. >>> 1 to: 4 do: [:i | self putLong: 0 toFile: f]. "fill remaining header >>> words with zeros" >>> >>> in Interpreter: >>> self putLong: (self imageFormatVersion) toFile: f. >>> self putLong: headerSize toFile: f. >>> self putLong: imageBytes toFile: f. >>> self putLong: (self startOfMemory) toFile: f. >>> self putLong: specialObjectsOop toFile: f. >>> self putLong: lastHash toFile: f. >>> self putLong: (self ioScreenSize) toFile: f. >>> self putLong: fullScreenFlag toFile: f. >>> self putLong: extraVMMemory toFile: f. >>> 1 to: 7 do: [:i | self putLong: 0 toFile: f]. "fill remaining header >>> words with zeros" >>> >>> Then >>> >>> getImageHeaderFlags >>> "Answer the flags that are contained in the 7th long of the image >>> header." >>> ^fullScreenFlag "0 or 1" >>> + (VMBIGENDIAN ifTrue: [0] ifFalse: [2]) "this is the >>> imageFloatsLittleEndian flag" >>> + (processHasThreadId ifTrue: [4] ifFalse: [0]) >>> + (flagInterpretedMethods ifTrue: [8] ifFalse: [0]) >>> + (preemptionYields ifTrue: [0] ifFalse: [16]) >>> + (noThreadingOfGUIThread ifTrue: [32] ifFalse: [0]) >>> + (imageHeaderFlags bitAnd: 63 bitInvert32) "these are any flags we do >>> not recognize" >>> >>> Now most of the information in the flags is accessible from >>> vmParameterAt: (or some convenience methods). e.g. vm parameter 49 is the >>> max external semaphore table size, and vm parameter 48 is the following >>> flags: >>> >>> getCogVMFlags >>> "Answer an array of flags indicating various properties of the Cog VM. >>> Bit 0: implies the image's Process class has threadId as its 3rd inst >>> var (zero relative) >>> Bit 1: if set, methods that are interpreted will have the flag bit set >>> in their header >>> Bit 2: if set, implies preempting a process does not put it to the back >>> of its run queue" >>> ^objectMemory integerObjectOf: (processHasThreadId ifTrue: [1] >>> ifFalse: [0]) >>> + (flagInterpretedMethods ifTrue: [2] ifFalse: [0]) >>> + (preemptionYields ifTrue: [0] ifFalse: [4]) >>> + (noThreadingOfGUIThread ifTrue: [8] ifFalse: [0]) >>> >> >> Hehe, in pharo the comment reaches up to 41 :). I'll look at squeak to >> update it. >> > > And squeak's reach up to 40 :/ in > http://ftp.squeak.org/4.1/SqueakV41.sources.gz > > >> >> >>> >>> Read the comment for vmParameterAt: to get things like num stack pages >>> and cog code size. >>> >>> Is this OK? I know it's a bit of a mess. If you or I (we?) write it up >>> where should we put the info? >>> >>>> >>>> Thanks, >>>> Guille >>>> >>>> On Thu, Jan 27, 2011 at 6:36 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>>> On Thu, 27 Jan 2011, Benjamin wrote: >>>>> >>>>> It works for PharoCore-1.1-11196-UNSTABLE.1 but it seems to be the >>>>>> only version where it works :S >>>>>> >>>>>> Does someone know why ? >>>>>> >>>>> >>>>> It doesn't support Cog's image format. Try an image with the original >>>>> Squeak format. You can convert your image with the latest SqueakVM. Only >>>>> the unix VM was released with this feature yet, so you can use that >>>>> http://squeakvm.org/unix/ or build a VM for your favorite platform. >>>>> >>>>> >>>>> Levente >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ben >>>>>> >>>>>> On Jan 27, 2011, at 3:36 PM, Benjamin wrote: >>>>>> >>>>>> Hello guys, >>>>>>> >>>>>>> for one of my projects, I'm trying to use SystemTracer to create >>>>>>> anew image, but it appears that it doesn't work on Pharo ... >>>>>>> I can create a new image, but I can't open it. I've tried with an >>>>>>> older VM (Squeak 3.8.18beta1U), but it's the same ... >>>>>>> >>>>>>> >>>>>>> Did someone already have this problem ? Does someone have a solution >>>>>>> ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks in advance, >>>>>>> >>>>>>> Ben >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >> > > -- best, Eliot

March 15, 2012

[Pharo-project] Pharo 1.4 Tests-Unix - Build # 286 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 15, 2012