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

Re: [Pharo-project] Pharo 1.0 fixing tests

by laurent laffont

On Sat, Mar 27, 2010 at 6:17 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi all, > > What results do you get when running all tests in Pharo and PharoCore 1.0 > on Mac/Windows/Linux? > > Lukas has MCPackageTest>>#testUnload failing on Hudson (a Linux server, I > assume). When running the tests locally on the Mac, the test > BlockContextTest>>#testTrace fails. But only the first time. Apparently > ContextPart>>#trace: is broken [1]. > > When I run all tests in Pharo1.0 on a Mac VM 4.2.3beta1U the first time I > get no failures. When running the second time I get following failures: > > MCInitializationTest>>testWorkingCopy > MCSnapshotTest>>testInstanceReuse > ProcessspecificTest>>testDynamicVariable > ProcessspecificTest>>testLocalVariable > ReleaseTest>>testObsoleteClasses > > If I then run only the above, they all pass. > Same result on Linux with the VM I've built. Laurent Laffont > > So there is certainly something fishy with the tests or how they are run. > > I would like to have a reliable, green test suite for Pharo 1.0. Can you > report the results you get including the VM/platform? Any idea why the > results are not stable? > > Thanks, > Adrian > > [1] http://code.google.com/p/pharo/issues/detail?id=2210 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 27, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Michael Haupt

Hi Marcus, On Sat, Mar 27, 2010 at 6:51 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > I was planing to look at your work closely (again)... the ECOOP paper is > already printed on my Desk :-) ooh, interest! :-D If you have any (!) questions, you know how to reach me. :-) Best, Michael

March 27, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Marcus Denker

On Mar 27, 2010, at 6:37 PM, Michael Haupt wrote: > Hi, > > first post, sorry for breaking any rules. ;-) No rules broken.. >> >> Yes, that would be interesting to look at. > > I can offer a bunch of code and papers on such a system. Hans > Schippers, Dirk Janssens (University Antwerpen, Belgium), Robert > Hirschfeld and myself implemented a thing we called delMDSOC. It > started out as a machine model for aspect-oriented programming but > turned out to be much more interesting. It's been implemented using > COLA. *All* requests to objects are messages in this model, including > instance variable access. *Everything* is done using delegation. Also, > the system implements what Eliot wrote above about two receiver slots > for state and self. > > Stuff is available from here: > http://www.hpi.uni-potsdam.de/swa/projects/delmdsoc > I was planing to look at your work closely (again)... the ECOOP paper is already printed on my Desk :-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 27, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by laurent laffont

> > > Does it mean latest SVN source is already "Gnuified" ? With latest rev. > I > > have a little drop in benchmarks. However I'd rather put a stable release > > for Pharo 1.0 than latest trunk. What do you think ? > > The so-called "gnuification" is a transformation of the interp.c file. So > this is done after generating the sources with VMMaker. The cmake > configuration that comes with revision 2135 does not have this step enabled, > and the more recent version that I used, revision 2151, has it. The magic is > in the awk script in unix/cmake/gnuify.awk which produes gnu-interp.c. > OK thanks. I will take a look. Laurent Laffont > > Cheers, > Adrian > > > > > Laurent Laffont > > > > > >> > >> Adrian > >> > >> > >> _______________________________________________ > >> 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 >

March 27, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Michael Haupt

Hi, On Sat, Mar 27, 2010 at 6:37 PM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Stuff is available from here: > http://www.hpi.uni-potsdam.de/swa/projects/delmdsoc sorry, the page does not list all the relevant publications. * ECOOP'07 (description of model and semantics) http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/HauptSchippers_… * ACM SAC PSC'09 (description of implementation) http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/SchippersHauptH… There is one more paper at OOPSLA'08 that is rather theoretical, describing semantics mappings for several MDSOC languages and how the model preserves them ... for the sake of completeness: http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/SchippersJansse… Best, Michael

March 27, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Adrian Lienhard

On Mar 27, 2010, at 18:21 , laurent laffont wrote: > On Sat, Mar 27, 2010 at 6:13 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> >> On Mar 27, 2010, at 17:16 , laurent laffont wrote: >> >>>> I would love that the official Linux VM has: >>>> >>>> - that thing about the gnufication >>>> I did that when compiling MacOS VM. >>>> Read this link (step 4 for example) >>>> >>>> >> http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc… >>>> >>>> does it make sense also in Linux VM ? which are the difference in the >>>> benchmarks compared to do it without this step ? >>>> >>> >>> Isn't it a MacOS issue only ? >> >> No, this is relevant for all GNU C compilers! Without this step, which >> replaces the switch statement of the interpreter with a jump table, you get >> a *much* slower VM. I suggest to use the latest SVN source. >> > > Does it mean latest SVN source is already "Gnuified" ? With latest rev. I > have a little drop in benchmarks. However I'd rather put a stable release > for Pharo 1.0 than latest trunk. What do you think ? The so-called "gnuification" is a transformation of the interp.c file. So this is done after generating the sources with VMMaker. The cmake configuration that comes with revision 2135 does not have this step enabled, and the more recent version that I used, revision 2151, has it. The magic is in the awk script in unix/cmake/gnuify.awk which produes gnu-interp.c. Cheers, Adrian > > Laurent Laffont > > >> >> Adrian >> >> >> _______________________________________________ >> 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

March 27, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Michael Haupt

Hi, first post, sorry for breaking any rules. ;-) On Sat, Mar 27, 2010 at 6:17 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Perhaps we can be cleverer. Â What could we do if we introduced delegation into the language? Â Then we can add wrappers around objects and put the interception into the wrappers. Â This way there is no additional check. Â If one wants to intercept references to an object one creates a DNU wrapper and becomes the two objects. >> >> An execution model of delegation is that there are two slots for the receiver in a context, a state slot through which inst vars are accessed, and a self slot to which messages are sent. Â Normal sends merely duplicate the receiver into both slots. Â Delegating sends take state as an additional argument. >> >> An alternative model is to dispense with direct inst var access (assuming the JIT will inline simple accessors in PICs, or simply by virtue of the use of machine code render accessors affordable) and provide accessors for delegators that indirect through the delegate. >> > > Yes, that would be interesting to look at. I can offer a bunch of code and papers on such a system. Hans Schippers, Dirk Janssens (University Antwerpen, Belgium), Robert Hirschfeld and myself implemented a thing we called delMDSOC. It started out as a machine model for aspect-oriented programming but turned out to be much more interesting. It's been implemented using COLA. *All* requests to objects are messages in this model, including instance variable access. *Everything* is done using delegation. Also, the system implements what Eliot wrote above about two receiver slots for state and self. Stuff is available from here: http://www.hpi.uni-potsdam.de/swa/projects/delmdsoc The implementation is optimised as far as COLA goes. There is much potential for improvement, and implementing some PIC-like caching schemes failed because of some COLA shortcomings I could not figure out how to fix. Best, Michael

March 27, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by laurent laffont

On Sat, Mar 27, 2010 at 6:13 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Mar 27, 2010, at 17:16 , laurent laffont wrote: > > >> I would love that the official Linux VM has: > >> > >> - that thing about the gnufication > >> I did that when compiling MacOS VM. > >> Read this link (step 4 for example) > >> > >> > http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc… > >> > >> does it make sense also in Linux VM ? which are the difference in the > >> benchmarks compared to do it without this step ? > >> > > > > Isn't it a MacOS issue only ? > > No, this is relevant for all GNU C compilers! Without this step, which > replaces the switch statement of the interpreter with a jump table, you get > a *much* slower VM. I suggest to use the latest SVN source. > Does it mean latest SVN source is already "Gnuified" ? With latest rev. I have a little drop in benchmarks. However I'd rather put a stable release for Pharo 1.0 than latest trunk. What do you think ? Laurent Laffont > > Adrian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 27, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by laurent laffont

> > Laurent, > > Since you have taken the time to get the vm build process going, please > consider going one step further to get the Alien plugin built too. > PLEASE... > Now I can build it, but my VM crashes while running Alien tests :(. Nevertheless I want it (to play with Lumiere), so I will keep trying... Laurent Laffont > > I would do it myself, but as that great 20th Century Philospher, Dirty > Harry, put it "a man's got to know his limitations." > > There has been progress: I have now actually used Code::Blocks to build a > .so to work around a linking problem. OTOH, that same library *might* have > been at the center of yesterday's image meltdown :( I am determined to > free my number crunching work from Windows. Given some of the custom > hardware things I want to be able to continue doing, Macs are not really an > answer or I would have made that jump years ago. > > Bill > > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Mariano > Martinez Peck > *Sent:* Saturday, March 27, 2010 7:58 AM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 > tests green > > Hi Laurent. Excellent news! It's cool to see people playing with the VM. > Depending in gurus of heroes is never good. Because they left and you are > dead. > > A little question...do you think we should replace the official Linux VM > from the Pharo website ? > > I would love that the official Linux VM has: > > - that thing about the gnufication > I did that when compiling MacOS VM. > Read this link (step 4 for example) > > http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc… > > does it make sense also in Linux VM ? which are the difference in the > benchmarks compared to do it without this step ? > > - all tests green > - FT2Plugin and the Bryce magic for nicer fonts > - Include this VM in the Pharo 1.0 one click. > > Did you check the benchmarks with the VM from Pharo website and yours ? can > you evaluate the results of "1 tinyBenchmarks" as it is explained if point 5 > of Adrian post: > > http://www.adrian-lienhard.ch/blog?article=building-a-pharo-squeak-vm-from-… > > It would be cool also to update the readme.txt of the Pharo Linux Vm if > necessary > > And finally would be great to add a link to download the sources also. > > Thanks a lot. > > Mariano > > > 2010/3/26 laurent laffont <laurent.laffont(a)gmail.com> > >> Hi, >> >> Finally I've managed to build squeak vm rev. 2135 (current stable) with >> FT2Plugin which makes all tests green on Pharo 1.0 rc3 image........ on my >> machine :) >> >> If some Linux users can test it on their distro, thanks. >> >> The clean binary archive: >> http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-bin.tar.gz >> >> The generated source archive: >> http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz >> >> PharoCore-1.0 + configured VMMaker 1.2 image (for new vm builders, to >> have a known working base): >> http://lolgzs.free.fr/pharo/squeak-vm/PharoCore-1.0-VMMaker-1.2.tar.gz >> >> >> To build from source archive: >> ======================= >> wget >> http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz >> tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz >> cd Squeak-3.11.3.2135-pharo-src/ >> mkdir build && cd build >> ../unix/cmake/configure >> make >> sudo make install >> >> >> Internal plugins: >> ====================== >> UUIDPlugin >> >> External plugins: >> ====================== >> ADPCMCodecPlugin >> AioPlugin >> AsynchFilePlugin >> B2DPlugin >> B3DAcceleratorPlugin >> BMPReadWriterPlugin >> BitBltPlugin >> CroquetPlugin >> DSAPrims >> DropPlugin >> FFTPlugin >> FT2Plugin >> FileCopyPlugin >> FilePlugin >> FloatArrayPlugin >> FloatMathPlugin >> GeniePlugin >> HostWindowPlugin >> JPEGReadWriter2Plugin >> JPEGReaderPlugin >> JoystickTabletPlugin >> Klatt >> LargeIntegers >> LocalePlugin >> MIDIPlugin >> Matrix2x3Plugin >> MiscPrimitivePlugin >> Mpeg3Plugin >> QuicktimePlugin >> RePlugin >> SecurityPlugin >> SerialPlugin >> SocketPlugin >> SoundCodecPrims >> SoundGenerationPlugin >> SoundPlugin >> Squeak3D >> SqueakFFIPrims >> StarSqueakPlugin >> SurfacePlugin >> UnixOSProcessPlugin >> XDisplayControlPlugin >> ZipPlugin >> >> >> Fun story: if you don't have SecurityPlugin, LocaleTest>>testFontFullName >> deletes your image :) >> testFontFullName >> "self debug: #testFontFullName" >> | env dir | >> env := (Locale isoLanguage: 'ja') languageEnvironment. >> dir := FileDirectory on: SecurityManager default untrustedUserDirectory. >> [dir recursiveDelete] <-------------- Cool !! >> on: Error >> do: [:e | e]. >> env fontFullName. >> self assert: dir exists >> >> >> Cheers, >> >> Laurent Laffont >> >> _______________________________________________ >> 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 >

March 27, 2010

Re: [Pharo-project] How to easily intercept messages sent to ALL objects ?

by Marcus Denker

On Mar 26, 2010, at 6:12 PM, Eliot Miranda wrote: > > Perhaps we can be cleverer. What could we do if we introduced delegation into the language? Then we can add wrappers around objects and put the interception into the wrappers. This way there is no additional check. If one wants to intercept references to an object one creates a DNU wrapper and becomes the two objects. > > An execution model of delegation is that there are two slots for the receiver in a context, a state slot through which inst vars are accessed, and a self slot to which messages are sent. Normal sends merely duplicate the receiver into both slots. Delegating sends take state as an additional argument. > > An alternative model is to dispense with direct inst var access (assuming the JIT will inline simple accessors in PICs, or simply by virtue of the use of machine code render accessors affordable) and provide accessors for delegators that indirect through the delegate. > Yes, that would be interesting to look at. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 27, 2010