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

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

by Stefan Marr

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] Re: SystemTracer

by Guillermo Polito

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 >> >> >> >

March 15, 2012

[Pharo-project] [update 1.4] #14393

by Marcus Denker

14393 ----- Issue 5476: File Browser Invalid utf8 input detected when clicking on a binary file http://code.google.com/p/pharo/issues/detail?id=5476 Issue 5469: Refactoring in DropList + Fix wrap http://code.google.com/p/pharo/issues/detail?id=5469 -- Marcus Denker -- http://marcusdenker.de

March 15, 2012

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

by Guillermo Polito

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. > > 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 > > >

March 15, 2012

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

by Igor Stasenko

Just want to add, that in Pharo we refactored things a bit, so if you want to look for vm parameters, they are accessed via: Smalltalk vm parameterAt: xyz not Smalltalk vmParameterAt: look in VirtualMachine class for implementation. On 15 March 2012 17:58, 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]) > > 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 regards, Igor Stasenko.

March 15, 2012

Re: [Pharo-project] [Vm-dev] Re: Latest image from jenkins does not open with interpreter vm

by Guillermo Polito

HEhe, he already sent in a different thread the differences ;). On Thu, Mar 15, 2012 at 4:11 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 15 March 2012 20:05, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Ok, so I have no chose. I have to move SystemTracer to cog, or do it :D > > > > Yes. We need to make it working with Cog. > Hope, Eliot remembers what is essential changes between 6502 and 6505 > formats, which needs to be fixed in system tracer. > > > -- > Best regards, > Igor Stasenko. >

March 15, 2012

Re: [Pharo-project] Latest image from jenkins does not open with interpreter vm

by Igor Stasenko

On 15 March 2012 20:05, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, so I have no chose.Â I have to move SystemTracer to cog, or do it :D > Yes. We need to make it working with Cog. Hope, Eliot remembers what is essential changes between 6502 and 6505 formats, which needs to be fixed in system tracer. -- Best regards, Igor Stasenko.

March 15, 2012

Re: [Pharo-project] Latest image from jenkins does not open with interpreter vm

by Guillermo Polito

Ok, so I have no chose. I have to move SystemTracer to cog, or do it :D On Thu, Mar 15, 2012 at 4:02 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Mar 15, 2012, at 7:59 PM, Guillermo Polito wrote: > > > I'm having the following > > > > This interpreter (vers. 6502) cannot read image file (vers. 6505). > > > > This didn't happen with images from some weeks ago :( > > > The reason is that we now run the build with the VM compiled > on the build server... which is a Cog vm. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > >

March 15, 2012

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

by Igor Stasenko

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.

March 15, 2012

Re: [Pharo-project] Latest image from jenkins does not open with interpreter vm

by Marcus Denker

On Mar 15, 2012, at 7:59 PM, Guillermo Polito wrote: > I'm having the following > > This interpreter (vers. 6502) cannot read image file (vers. 6505). > > This didn't happen with images from some weeks ago :( The reason is that we now run the build with the VM compiled on the build server... which is a Cog vm. Marcus -- Marcus Denker -- http://marcusdenker.de

March 15, 2012