April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

by Eliot Miranda

On Tue, Apr 22, 2014 at 7:26 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Stefan Marr-3 wrote > > Still, I will state it anyway: I donât like the change. > > I expected it to be unpopular ;) > > > Stefan Marr-3 wrote > > So, just for the sake of argument, are there other ways? > > I don't know. I'm open... > > As far as making #= mean something different the first time, I think this > gets us further down the difficult-to-understand rabbit hole. Also, #= is > not always sent; it's one of several options, like #beFalse. I guess maybe > you could say "as soon as any expectation is set up, revert to a > traditional > #=. But philosophically, hijacking #= disrupts the uniformity of the system > and adds to the user's cognitive load. Hijacking it only some of the time > makes it even less predictable. > +1. And, what's the specific argument for keeping the behavior of #=? Am I > missing some value that makes it worth all of the above? I think it's > important to separate the logic from the inertia inevitably accompanying > this kind of change. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Des… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- best, Eliot

April 23, 2014

Re: [Pharo-dev] Phexample: API Change Proposal (was Phexample: Image Destroying Bug)

by Sean P. DeNigris

Stefan Marr-3 wrote > Still, I will state it anyway: I donât like the change. I expected it to be unpopular ;) Stefan Marr-3 wrote > So, just for the sake of argument, are there other ways? I don't know. I'm open... As far as making #= mean something different the first time, I think this gets us further down the difficult-to-understand rabbit hole. Also, #= is not always sent; it's one of several options, like #beFalse. I guess maybe you could say "as soon as any expectation is set up, revert to a traditional #=. But philosophically, hijacking #= disrupts the uniformity of the system and adds to the user's cognitive load. Hijacking it only some of the time makes it even less predictable. And, what's the specific argument for keeping the behavior of #=? Am I missing some value that makes it worth all of the above? I think it's important to separate the logic from the inertia inevitably accompanying this kind of change. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Des… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2014

Re: [Pharo-dev] Smalltalk Hub on Chrome

by Sean P. DeNigris

It looks like this: <http://forum.world.st/file/n4755918/Screenshot_2014-04-22_22.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Smalltalk-Hub-on-Chrome-tp4755788p4755918.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 23, 2014

Re: [Pharo-dev] [squeak-dev] Monticello Whitewash...

by Chris Muller

I would also be happy for that fix.. On Tue, Apr 22, 2014 at 6:18 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ugh... after opening a multi-window browser on the Spur classes in the > automatically-created VMMaker image I notice once again that Monticello > doesn't preserve class organization order on load. grr.... Anyone up to > fixing this? > -- > best, > Eliot > > >

April 23, 2014

Re: [Pharo-dev] [Vm-dev] Spur performance report...

by Eliot Miranda

Hi David, On Tue, Apr 22, 2014 at 4:21 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Tue, Apr 22, 2014 at 03:44:46PM -0700, Eliot Miranda wrote: > > Hi Nicolas, > > > > On Tue, Apr 22, 2014 at 3:21 PM, Nicolas Cellier < > > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > > > 2014-04-23 0:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > >> > > >> Hi All, > > >> > > >> I should write a blog post on this, but I can't wait... > > >> > > >> In recent days I've written a script to build a Cog VMMaker image from > > >> Squeak 4.5. See > http://www.squeakvm.org/svn/squeak/branches/Cog/image. > > >> This has allowed me to run the current Cog VM against Spur > side-to-side. > > >> > > >> To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro > using > > >> the current Cog VM takes about 2 and a half minutes: > > >> > > >> McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st > > >> real 2m30.671s > > >> user 2m15.683s > > >> sys 0m5.283s > > >> > > >> To build the equivalent image using Spur takes about 1 and a half > minutes: > > >> McStalker.image$ time spurcfvm CogVMMaker-spur.image > > >> BuildSqueak45Image.st > > >> real 1m34.943s > > >> user 1m23.666s > > >> sys 0m6.810s > > >> > > >> Comparing: > > >> > > >> 94.943 - 150.671 / 150.671 * 100 -36.99 > > >> 83.666 - 135.681 / 135.681 * 100 -38.34 > > >> 150.671 / 94.943 1.59 > > >> 135.681 / 83.666 1.62 > > >> > > >> that's about a -37% speedup, or 1.6x faster. > > >> -- > > >> best, > > >> Eliot > > >> > > >> > > > So this is loading .mcz from package cache, uncompressing, compiling, > > > installing the packages. > > > > > > > Exactly. > > > > > > > I presume this qualifies as a macro benchmark... > > > > > > > yes :-) > > > > That's quite impressive. I suspect that if you run this under a time > profiler > that you'll see a lot of time going into I/O even though it is using a > local > MC cache. That would mean that this macro benchmark is quite conservative, > and the actual computational speedup may be considerably better than 1.6x. > I think that the i/o time is included in the "sys" sub-total, which will include reading the image files and the mczs. The rest is, as they say, up to us. So the difference in performance between including and excluding I/O is -36.99 vs -38.34, or 1.59 vs 1.62. > Bravo! > > Dave > -- best, Eliot

April 22, 2014

Re: [Pharo-dev] [Vm-dev] Spur performance report...

by David T. Lewis

On Tue, Apr 22, 2014 at 03:44:46PM -0700, Eliot Miranda wrote: > Hi Nicolas, > > On Tue, Apr 22, 2014 at 3:21 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > 2014-04-23 0:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > >> > >> Hi All, > >> > >> I should write a blog post on this, but I can't wait... > >> > >> In recent days I've written a script to build a Cog VMMaker image from > >> Squeak 4.5. See http://www.squeakvm.org/svn/squeak/branches/Cog/image. > >> This has allowed me to run the current Cog VM against Spur side-to-side. > >> > >> To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro using > >> the current Cog VM takes about 2 and a half minutes: > >> > >> McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st > >> real 2m30.671s > >> user 2m15.683s > >> sys 0m5.283s > >> > >> To build the equivalent image using Spur takes about 1 and a half minutes: > >> McStalker.image$ time spurcfvm CogVMMaker-spur.image > >> BuildSqueak45Image.st > >> real 1m34.943s > >> user 1m23.666s > >> sys 0m6.810s > >> > >> Comparing: > >> > >> 94.943 - 150.671 / 150.671 * 100 -36.99 > >> 83.666 - 135.681 / 135.681 * 100 -38.34 > >> 150.671 / 94.943 1.59 > >> 135.681 / 83.666 1.62 > >> > >> that's about a -37% speedup, or 1.6x faster. > >> -- > >> best, > >> Eliot > >> > >> > > So this is loading .mcz from package cache, uncompressing, compiling, > > installing the packages. > > > > Exactly. > > > > I presume this qualifies as a macro benchmark... > > > > yes :-) > That's quite impressive. I suspect that if you run this under a time profiler that you'll see a lot of time going into I/O even though it is using a local MC cache. That would mean that this macro benchmark is quite conservative, and the actual computational speedup may be considerably better than 1.6x. Bravo! Dave

April 22, 2014

Monticello Whitewash...

by Eliot Miranda

ugh... after opening a multi-window browser on the Spur classes in the automatically-created VMMaker image I notice once again that Monticello doesn't preserve class organization order on load. grr.... Anyone up to fixing this? -- best, Eliot

April 22, 2014

Re: [Pharo-dev] [Vm-dev] Spur performance report...

by Eliot Miranda

Hi Nicolas, On Tue, Apr 22, 2014 at 3:21 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-04-23 0:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi All, >> >> I should write a blog post on this, but I can't wait... >> >> In recent days I've written a script to build a Cog VMMaker image from >> Squeak 4.5. See http://www.squeakvm.org/svn/squeak/branches/Cog/image. >> This has allowed me to run the current Cog VM against Spur side-to-side. >> >> To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro using >> the current Cog VM takes about 2 and a half minutes: >> >> McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st >> real 2m30.671s >> user 2m15.683s >> sys 0m5.283s >> >> To build the equivalent image using Spur takes about 1 and a half minutes: >> McStalker.image$ time spurcfvm CogVMMaker-spur.image >> BuildSqueak45Image.st >> real 1m34.943s >> user 1m23.666s >> sys 0m6.810s >> >> Comparing: >> >> 94.943 - 150.671 / 150.671 * 100 -36.99 >> 83.666 - 135.681 / 135.681 * 100 -38.34 >> 150.671 / 94.943 1.59 >> 135.681 / 83.666 1.62 >> >> that's about a -37% speedup, or 1.6x faster. >> -- >> best, >> Eliot >> >> > So this is loading .mcz from package cache, uncompressing, compiling, > installing the packages. > Exactly. > I presume this qualifies as a macro benchmark... > yes :-) > I didn't follow the full flow of changes, how difficult is it right now to > bootstrap a spur.image? > Right now the transformation of the images is straight-forward, e.g.: SpurBootstrap bootstrapImage: 'Squeak-4.5-All-in-One.app/Contents/Resources/Squeak4.5-13680' But fixing the Monticello packages is a little more involved. One has to collect the relevant packages in a directory (Kernel, Collections & System) and then do e.g. (SpurBootstrapMonticelloPackagePatcher new from: 'image/package-cache' to: 'image/spur-package-cache') patch and then load the packages into the Spur image. When I get my ass in gear this step should be unnecessary since http://source.squeak.org/spur is ready and waiting. So the Spur trunk for Squeak V5.0 will parallel Squeak 4.6 and hopefully supplant it soon enough. The main hold up right now is the combination of the facts that the current compaction algorithm doesn't work well, and image start-up always adds 50% of image size as free space, so the image balloons on each save. I'm finally getting back to working on the compaction algorithm after a very satisfying three weeks working with ClÃ©ment BÃ©ra on Sista. So I hope to have movement on releasing Spur for the 4.6/5.0 development cycle soon. -- best, Eliot

April 22, 2014

Spur performance report...

by Eliot Miranda

Hi All, I should write a blog post on this, but I can't wait... In recent days I've written a script to build a Cog VMMaker image from Squeak 4.5. See http://www.squeakvm.org/svn/squeak/branches/Cog/image. This has allowed me to run the current Cog VM against Spur side-to-side. To build a Cog VMMaker image on my 2.2GHz Intel Core i7 MacBook Pro using the current Cog VM takes about 2 and a half minutes: McStalker.image$ time oscfvm CogVMMaker.image BuildSqueak45Image.st real 2m30.671s user 2m15.683s sys 0m5.283s To build the equivalent image using Spur takes about 1 and a half minutes: McStalker.image$ time spurcfvm CogVMMaker-spur.image BuildSqueak45Image.st real 1m34.943s user 1m23.666s sys 0m6.810s Comparing: 94.943 - 150.671 / 150.671 * 100 -36.99 83.666 - 135.681 / 135.681 * 100 -38.34 150.671 / 94.943 1.59 135.681 / 83.666 1.62 that's about a -37% speedup, or 1.6x faster. -- best, Eliot

April 22, 2014

Re: [Pharo-dev] Pharo success story for Issys Tracking broken?

by Torsten Bergmann

Yes - but the question remains where did this story come from. I would like to know more about it. Thx T. > Gesendet: Dienstag, 22. April 2014 um 16:20 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Pharo success story for Issys Tracking broken? > > > On 22 Apr 2014, at 13:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Torsten Bergmann wrote > >> Unfortunately none of the links work. Any infos on that? > > > > I did a little googling and checked the wayback machine; didn't come up with > > anything relevantâ¦ > > > > I have removed the article for nowâ¦ > > Marcus > > >

April 22, 2014