- Pharo-dev - lists.pharo.org

[Pharo-project] linux build stability
by Eliot Miranda Feb. 2, 2011

Feb. 2, 2011

Hi All, you may already know that there have been strange stability problems with the Cog VM on linux. Problems with the heartbeat appear to derive from specific compilations, one compilation of the same source producing an executable that will crash, another producing one that won't. recent testing at Teleplace showed that an effect due to what was presumed to be a compiler bug (specifically the optimization level used to compile the heartbeat, high causing a crash) was not repeatable. So today in building new production VMs for Teleplace I decided to do three parallel linux builds and see if all produced the same results. While there are macros used in the source that are date dependent (use of __DATE__) AFAIA there are none apart from version.c/version.o that depend on time, and no timestamps or current directory paths in linux objects, and so, provided different compilations of the same source are done on the same day, the results should be bit-identical. In my experiment this turns out not to be the case, which is more than a little alarming. What I'm seeing is different results duplicating unixbuild/bld to unixbuild/bldb and unixbuild/bldc, doing identical configures and makes in each of the three directories and then comparing resulting objects. I see this in a bare metal laptop with local sources running CERN SLC5 and on a Parallels VM running CentOS 5.3 (both derived from RHEL). I'm using gcc 4.1.2. Here's a script that shows example differences: bld$ for f in *.o vm/*.o; do echo $f;cmp $f ../bldb/$f; cmp $f ../bldc/$f; done disabledPlugins.o disabledPlugins.o ../bldb/disabledPlugins.o differ: byte 200, line 4 disabledPlugins.o ../bldc/disabledPlugins.o differ: byte 200, line 4 version.o version.o ../bldb/version.o differ: byte 166, line 3 version.o ../bldc/version.o differ: byte 166, line 3 vm/aio.o vm/cogit.o vm/debug.o vm/gcc3x-cointerp.o vm/osExports.o vm/sqExternalSemaphores.o vm/sqHeapMap.o vm/sqLinuxHeartbeat.o vm/sqLinuxWatchdog.o vm/sqLinuxWatchdog.o ../bldb/vm/sqLinuxWatchdog.o differ: byte 33, line 1 vm/sqLinuxWatchdog.o ../bldc/vm/sqLinuxWatchdog.o differ: byte 33, line 1 vm/sqNamedPrims.o vm/sqNamedPrims.o ../bldb/vm/sqNamedPrims.o differ: byte 6346, line 30 vm/sqNamedPrims.o ../bldc/vm/sqNamedPrims.o differ: byte 6346, line 30 vm/sqTicker.o vm/sqUnixCharConv.o vm/sqUnixExternalPrims.o vm/sqUnixMain.o vm/sqUnixMain.o ../bldb/vm/sqUnixMain.o differ: byte 31415, line 170 vm/sqUnixMain.o ../bldc/vm/sqUnixMain.o differ: byte 31414, line 170 vm/sqUnixMemory.o vm/sqUnixThreads.o vm/sqUnixVMProfile.o vm/sqVirtualMachine.o Using objdump --disassemble I can see for example that sqLinuxWatchdog.o and sqUnixMain.o differ only in the symbol table, not the executable code. So perhaps this is not meaningful, and merely noise. But with simple files like disabledPlugins.c that different objects are produced at all in different runs is rather worrying: bld$ cat disabledPlugins.c /* this should be in a header file, but it isn't. ho hum. */ typedef struct { char *pluginName; char *primitiveName; void *primitiveAddress; } sqExport; sqExport vm_display_Quartz_exports[] = { 0, 0, 0 }; sqExport vm_display_custom_exports[] = { 0, 0, 0 }; sqExport vm_display_fbdev_exports[] = { 0, 0, 0 }; sqExport vm_sound_MacOSX_exports[] = { 0, 0, 0 }; sqExport vm_sound_NAS_exports[] = { 0, 0, 0 }; sqExport vm_sound_OSS_exports[] = { 0, 0, 0 }; sqExport vm_sound_Sun_exports[] = { 0, 0, 0 }; sqExport vm_sound_custom_exports[] = { 0, 0, 0 }; I wonder - do you see the same effect? - does this happen with gcc versions other than 4.1.2? - does it happen on non-RHEL-derived distros? - is this a meaningful signal or just harmless noise? - what am I doing wrong? Clearly I need to look more carefully but I thought I'd ask y'all in order to understand and hopefully solve the build instabilities as swiftly as possible. If you do want to try and reproduce this simply duplicate the build directory (unixbuild/bld in the Cog VM source) twice and do three separate configures and makes, one in each of the build directories, each from the same source code. Then run some variation fo the script above to compare the object files so produced. best Eliot

2 1

[Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
by Nicolas Cellier Feb. 2, 2011

Feb. 2, 2011

The fact is that, while many patches find their way from Squeak to Pharo, very few take the other way. Why is that ? - squeak people are sobing pharoers - squeak people are too few to achieve this task - there is nothing interesting happening in Pharo No no, please don't answer, I innoculate this bullshit intentionnally to vaccine this thread against further crap. What IMO is the main explanation is this: - it's very easy to cherry pick squeak changes thanks to trunk: diff messages, while there is nothing equivalent in Pharo. Just browsing Squeak/Pharo diffs, it's easy to recognize text copy/pasted via web with tabs changed in spaces. Also the pharo issue tracker is full of these. This gives some clues. This is a very good thing that patches can be shared. But why not the other way around ? This is surprising because: - 1) Pharo is very active these days. - 2) Pharo was apparently setting a higher quality hurdle by forcing each modification to be traced ( http://code.google.com/p/pharo/issues ) So we could have expected more fixes coming from Pharo. Maybe it's because the process only have appearances of quality, but doesn't really pay off. Maybe I had some bad luck with http://code.google.com/p/pharo/issues/detail?id=3468 Or is there many examples of issues closed without a clue ? Imagine you can recognize the symptoms of this bug in Pharo 1.1 and want to backport the patch... I'm interested to hear how to proceed. The simple squeak trunk diff messages are not a panacea. A database of changes in all flavours of Squeak might help better. But it's very practicle and I wish I could see an equivalent in Pharo. On the other end, I was finally forced to filter out the automated [Pharo-Issues] posts. The signal/noise ratio is far too low to sustain attention, though I for one care about patches. I wish my criticism could bring introspection, better and - why not - squeak friendly :) practices. Nicolas

6 9

[Pharo-project] Best Class Comment Award.... tada to XMLWriter!
by StÃ©phane Ducasse Feb. 1, 2011

Feb. 1, 2011

Hi I just want to deliver the Best Class Comment Award of the month to XMLWriter! Tx for this great job! I want more. Simple and no stupid I'm an instance variable of this type. Cool and great key examples! Stef (I want more system that think that I'm an idiot and carefully explain to me what I should do yes babysit me).

1 0

[Pharo-project] Sound package fixes
by StÃ©phane Ducasse Feb. 1, 2011

Feb. 1, 2011

Hi we merged all the squeak fixes to Sound and published them in PharoNonCorePackages It will be loaded in 1.3 dev but you can load them if you want to try. Stef

3 3

[Pharo-project] Automatic One-Click VM
by Torsten Bergmann Feb. 1, 2011

Feb. 1, 2011

see also http://code.google.com/p/pharo/issues/detail?id=3484 -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
by Marcus Denker Feb. 1, 2011

Feb. 1, 2011

On Feb 1, 2011, at 7:04 AM, StÃ©phane Ducasse wrote: > Nicolas > > We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the > diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is > years that we passed it. > >> Maybe it's because the process only have appearances of quality, but >> doesn't really pay off. > > Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life. > Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server > is subject to missing some parts. But this is life. Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* and they should be done more often, but as soon as you require them, nothing will happen. The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict rule is adopted. Strict rules kills human processes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
by Marcus Denker Feb. 1, 2011

Feb. 1, 2011

> > Maybe I had some bad luck with > http://code.google.com/p/pharo/issues/detail?id=3468 > Or is there many examples of issues closed without a clue ? In a case like that, the changeset was just merged in the release. The test is failing, as you can see: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 4

Re: [Pharo-project] Automatic One-Click VM
by Marcus Denker Feb. 1, 2011

Feb. 1, 2011

On Feb 1, 2011, at 1:44 PM, Geert Claes wrote: > > Can we replace the Croquet VM exe file that is bundled in the one-click > images generated using Hudson with a with a Pharo branded one? Yes, the one-click needs a couple of iterations... 1) we need to update the VMs to the latest 2) we need to sync the one-click with the old ones. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Feb. 1, 2011

Hi guys loadSoundEnabled self loadSetting: #soundEnabled withBlock: [SoundService soundEnabled: nil]. since mariano is away and I do not know what was done in Sound, I'm trying but this is not simple when you do not know what was the intention. The method is: resumePlaying: aSound quickStart: quickStart "Start playing the given sound without resetting it; it will resume playing from where it last stopped. If quickStart is true, then try to start playing the given sound immediately." | doQuickStart | SoundSettings soundsEnabled ifFalse: [^ self]. doQuickStart := quickStart. SoundSettings soundQuickStart ifFalse: [doQuickStart := false]. PlayerProcess == nil ifTrue: [ self canStartPlayer ifFalse: [^ self]. ^self startUpWithSound: aSound]. PlayerSemaphore critical: [ (ActiveSounds includes: aSound) ifTrue: [doQuickStart := false] ifFalse: [ doQuickStart ifFalse: [ActiveSounds add: aSound]]]. "quick-start the given sound, unless the sound player has just started" doQuickStart ifTrue: [self startPlayingImmediately: aSound]. it refers to SoundSettings and there is no such a thing. There is no implementors of soundsEnabled So I tried to understand the changes made in Slice-3566 Now the question is do we want SoundService to play the role of a setting provider? Originally I thought to put it in BaseSoundSystem. But the code of henrik seems to use SoundService. Now BaseSoundSystem register itself as the default sound service. So I'm confused! Help is welcome. Stef

3 4

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
by Marcus Denker Feb. 1, 2011

Feb. 1, 2011

On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote: > 2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> Maybe I had some bad luck with >>> http://code.google.com/p/pharo/issues/detail?id=3468 >>> Or is there many examples of issues closed without a clue ? >> >> In a case like that, the changeset was just merged in the release. >> >> The test is failing, as you can see: >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >> >> > > This is probably because you must > (Object recompile: #perform:withArguments:) > The 1.3 core image was recompiled completely around 13020... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2