February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Best Class Comment Award.... tada to XMLWriter!

by StÃ©phane Ducasse

thanks :) Stef On Feb 2, 2011, at 8:19 AM, Torsten Bergmann wrote: > Add this method as XMLWriter class>>help and open the > help browser: > > help > <wikiStyleHelp: 'Writing XML'> > ^self comment > > You can now read it in the help system - but it is only > a page. > > Next: change the class comment to use wiki syntax: > > "!Introduction > The class XMLWriter allows you to generate well-formed XML documents using an API similar to Seaside's canvas and tag brush API. > > !How to use > Markup can be created ..." > > you will get a nice class comment AND a nice book in the > help system. > > So one can easily turn nice class comments into help system books. > > Have fun > T. > > -- > NEU: FreePhone - kostenlos mobil telefonieren und surfen! > Jetzt informieren: http://www.gmx.net/de/go/freephone >

Feb. 2, 2011

[Pharo-project] Best Class Comment Award.... tada to XMLWriter!

by Torsten Bergmann

Add this method as XMLWriter class>>help and open the help browser: help <wikiStyleHelp: 'Writing XML'> ^self comment You can now read it in the help system - but it is only a page. Next: change the class comment to use wiki syntax: "!Introduction The class XMLWriter allows you to generate well-formed XML documents using an API similar to Seaside's canvas and tag brush API. !How to use Markup can be created ..." you will get a nice class comment AND a nice book in the help system. So one can easily turn nice class comments into help system books. Have fun T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

Feb. 2, 2011

Re: [Pharo-project] how to use dejavu bitmap fonts

by StÃ©phane Ducasse

Bingo! > It should declare fonts probably in one of the classVar of the TextConstant SharedPool. > > Why fonts can't just use a classvar in AbstractFont class , why > depending on something outside of package? I like when quizzes are easy enough.. (ok the answer was already in previous mails) I guess the answer is because people like to have a huge dictionary to put stuff in there... so we will clean that again and move the dictionary extra stuff into adequate places. Stef (aka random refactorer)

Feb. 2, 2011

Re: [Pharo-project] linux build stability

by Andres Valloud

In case it helps, I've seen GCC produce different code for function A when I change function B. This can happen even if function B is not in the (reasonably close) execution path of function A. However, the differences I've seen are along the lines of e.g.: using %r10 instead of %r9, or %r13+3 instead of %r12+4 (where the pointers basically point to the same desired data). Since both outputs are legal, the differences can be attributed to the internal state of the compiler which perhaps is not totally deterministic. Nevertheless, as long as the output is valid, one should not be able to complain about this variability. Nevertheless, these changes do expose other bugs. So, if you see these kind of differences correlated with "the VM crashes" or "the VM appears to work", then I'd suspect ABI violations with regards to the registers involved. On 2/1/11 22:17 , Eliot Miranda wrote: > 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

Feb. 2, 2011

[Pharo-project] linux build stability

by Eliot Miranda

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

Feb. 2, 2011

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by Levente Uzonyi

On Tue, 1 Feb 2011, Igor Stasenko wrote: > On 1 February 2011 15:44, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Tue, 1 Feb 2011, Igor Stasenko wrote: >> >>> On 1 February 2011 01:47, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> The fact is that, while many patches find their way from Squeak to >>>> Pharo, very few take the other way. >>>> >>> >>> Frankly, i had the opposite impression. >>> For instance, Sets with nil already have more than year in Squeak, >>> but still didn't found their way into Pharo. >> >> This not related to what Nicolas wrote. He wrote that a lot more patches go >> from Squeak to Pharo, than from Pharo to Squeak. The latter is close to >> zero, while the first is between 300 and 800 (based on the Pharo issue >> tracker. 400-900 including the non-closed issues). So I wonder why did you >> have the opposite impression. >> >> > I doubt that Squeak wants to integrate Etoys cleanup :). > Squeak community are much more conservative towards major > refactorings/changing APIs etc etc. > And given that most major changes in Pharo are for either throwing out > some old stuff or do complete rewrite, > this gives an answer why you don't see changes flowing widely from > Pharo to Squeak. This doesn't anwser at all why you had the impression that more Pharo changes are going to Squeak, than the other way. On the contrary it demonstrates why you think Pharo changes don't get integrated into Squeak. > As for minor level changes, or kernel/compiler changes - we are in > sync .. because both camps paying attention in > keeping core in healthy state. But you should know it yourself, > because you are taking part in that. :) No, we are not in sync and it's hard to tell all the differences. Just try to load a package developed for Pharo into Squeak and you'll see how much fixes you have to do to make it work. Or just try to maintain a package for both platforms. Levente > >> Levente >> >> snip >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 2, 2011

Re: [Pharo-project] how to use dejavu bitmap fonts

by Igor Stasenko

On 31 January 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The package should be updated to 1.2. > > It should declare fonts probably in one of the classVar of the TextConstant SharedPool. Why fonts can't just use a classvar in AbstractFont class , why depending on something outside of package? > Probably > Â Â Â Â TextSharedInformation have a look. > > In 1.2 we cleaned the last global poolvar = textConstant which was used as a pool but also as a repository to plug anything inside > instead of specific classVariable in adequate classes. It was a good plate of spaghettis code. > > I know that benjamin wants to take some times to do another pass and move the left over to the class they belongs to but it will > take some time. > > Stef > > On Jan 31, 2011, at 9:52 PM, Tudor Girba wrote: > >> Hi, >> >> I am trying to use the DejaVuBitmapFonts, but I do not know how to install them. I tried the following: >> >> Gofer it >> Â Â Â squeaksource: 'DejaVu'; >> Â Â Â package: 'DejaVuBitmapFonts'; >> Â Â Â load. >> >> DejaVuHolder installFull. >> >> However, this creates a problem in using TextConstants. Can anyone help? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "One cannot do more than one can do." >> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 2, 2011

[Pharo-project] Best Class Comment Award.... tada to XMLWriter!

by StÃ©phane Ducasse

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

Feb. 1, 2011

Re: [Pharo-project] Issue 3482 in pharo: InterimSoundMorph references to SketchMorph

by pharo＠googlecode.com

Comment #14 on issue 3482 by stephane...(a)gmail.com: InterimSoundMorph references to SketchMorph http://code.google.com/p/pharo/issues/detail?id=3482 Thanks for the analysis I will have a look. Right now my son gave me his nice flu and I start burning of heat in my bed :) with little headache reminding me that well this head is hurting... :)

Feb. 1, 2011

Re: [Pharo-project] Issue 3482 in pharo: InterimSoundMorph references to SketchMorph

by pharo＠googlecode.com

Comment #13 on issue 3482 by ryd...(a)gmail.com: InterimSoundMorph references to SketchMorph http://code.google.com/p/pharo/issues/detail?id=3482 In other words, I agree it's not ideal for Sound services to rely on System-Applications. The package seems more like it's put together more on the principle of "Ah! These are registry subclasses!!" rather than "I provide a pluggable way to do X Oh, and btw, I happen to be using the registry mechanism to achieve that" :) The second approach would, I think, lead you to put it in the same package as the other classes needed to do X. I do not think it's a good change in functionality/responsibility to have a sound on/off setting per service though, that should remain a global setting. Moving Beeper and SoundService to System-Sound would satisfy both.

Feb. 1, 2011